syntax difference

[Sharan Basappa]

Is there a difference between these prints. The first one looks a bit complex. So, why should it be used?

my_age = 35 # not a lie

print "my age %s." % my_age
print "my age ", my_age

Output:
%run "D:/Projects/Initiatives/machine learning/programs/five.py"
my age 35.
my age 35

[Alister]

in that example probably no difference - readability counts.
but if you want to display a slightly different message then you could
the following

print "may age is %s years",% my_age

which is arguably nicer than
print "my age is",
print my_age,
print "Years"

& less error prone


you can of course expand this format with multiple insertions & even
explicit formatting for specific data types.





--
It got to the point where I had to get a haircut or both feet firmly
planted in the air.

[Cameron Simpson]

In case nobody else notices, the reason the second one has 2 spaces before "35"
is that print puts a space between items. So you have a space from the "my age
" and also a space from the item separation. The first print statement is only
printing one item.

Regarding which style to use: the latter is better because it is more readable.
The former can be better when constructing a string with several values where
you want more control and better readablility _for the message as a whole_.

Consider:

# variables, just to make the examples work
# in a real programme perhaps these came from
# some more complex earlier stuff
name = "Sharon"
age = 35
print "The person named %r is %d years old." % (name, age)

versus:

name = "Sharon"
age = 35
print "The person named", repr(name), "is", age, "years old."

I'd be inclined to prefer the former one because I can see the shape of the
message.

Also, I notice you're using Python 2 (from the print syntax). In Python 3 we
have "format strings", which let you write:

name = "Sharon"
age = 35
print(f"The person named {name|r} is {age} years old.")

Win win!

Cheers,
Cameron Simpson <c...@cskk.id.au>

[Ben Bacarisse]

Cameron Simpson <c...@cskk.id.au> writes:
<snip>

> ... In Python 3 we have "format strings", which let you write:
>
> name = "Sharon"
> age = 35
> print(f"The person named {name|r} is {age} years old.")

You meant {name!r} I think there.

--
Ben.

[Sharan Basappa]

thanks, everyone.

I think I am now confused with format options in Python.
I tried an example as below and both print proper value:

age = 35

print "age is %s" % age
print "age is %d" % age

%run "D:/Projects/Initiatives/machine learning/programs/six.py"
age is 35
age is 35

I other languages I know the format specifier should be same as the variable type. For example, in the above case, it has to be %d and not %s

[Ben Finney]

Sharan Basappa <sharan....@gmail.com> writes:

> I think I am now confused with format options in Python.

You should refer to the documentation for string formatting
<URL:https://docs.python.org/3/library/stdtypes.html#str.format>
<URL:https://docs.python.org/3/library/string.html#formatstrings>

(or, if you want to continue with the older less-flexible style,
<URL:file:///usr/share/doc/python3/html/library/stdtypes.html#printf-style-string-formatting>)

> I tried an example as below and both print proper value:
>
> age = 35
>
> print "age is %s" % age

The ‘s’ format specifier says “Ask the object for its text
representation, and put that text here”.

Every object has a text representation, so ‘s’ works with any object.

> print "age is %d" % age

The ‘d’ format specifier says “Format the integer as a decimal text
representation, and put that text here”.

Only objects that are integers (or that implement the format-as-decimal
API) will work with ‘d’.

> I other languages I know the format specifier should be same as the
> variable type. For example, in the above case, it has to be %d and not
> %s

Because you are explicitly specifying which formatting to use, there's
no ambiguity. With an object that is an integer, either of the above
makes sense in different use cases.

--
\ “A right is not what someone gives you; it's what no one can |
`\ take from you.” —Ramsey Clark |
_o__) |
Ben Finney

[Chris Angelico]

On Sun, Jun 17, 2018 at 3:30 PM, Ben Finney <ben+p...@benfinney.id.au> wrote:
> Sharan Basappa <sharan....@gmail.com> writes:
>
>> I think I am now confused with format options in Python.
>

> You should refer to the documentation for string formatting
> <URL:https://docs.python.org/3/library/stdtypes.html#str.format>
> <URL:https://docs.python.org/3/library/string.html#formatstrings>
>
> (or, if you want to continue with the older less-flexible style,
> <URL:file:///usr/share/doc/python3/html/library/stdtypes.html#printf-style-string-formatting>)

For the record, there's nothing at all wrong with printf-style
formatting; its flexibility and brevity make it extremely useful in
many situations.

ChrisA

[Ben Finney]

Chris Angelico <ros...@gmail.com> writes:

> On Sun, Jun 17, 2018 at 3:30 PM, Ben Finney <ben+p...@benfinney.id.au> wrote:
> > (or, if you want to continue with the older less-flexible style,

(I gave an unhelpful URL for that documentation. Try this instead
<URL:https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting>.)

> For the record, there's nothing at all wrong with printf-style
> formatting; its flexibility and brevity make it extremely useful in
> many situations.

That isn't the impression I get from the above documentation. It starts
with a clearly worded warning:

Note

The formatting operations described here exhibit a variety of quirks
that lead to a number of common errors (such as failing to display
tuples and dictionaries correctly). Using the newer formatted string
literals or the str.format() interface helps avoid these errors.
These alternatives also provide more powerful, flexible and
extensible approaches to formatting text.

That states a clear opinion that ‘str.format’ is preferred.

--
\ “True greatness is measured by how much freedom you give to |
`\ others, not by how much you can coerce others to do what you |
_o__) want.” —Larry Wall |
Ben Finney

[Jim Lee]

On 06/16/2018 10:13 PM, Sharan Basappa wrote:
> I think I am now confused with format options in Python.
> I tried an example as below and both print proper value:
>
> age = 35
>
> print "age is %s" % age
> print "age is %d" % age
>
> %run "D:/Projects/Initiatives/machine learning/programs/six.py"
> age is 35
> age is 35
>
> I other languages I know the format specifier should be same as the variable type. For example, in the above case, it has to be %d and not %s

  Python is not like other languages.  For one thing, there are no
"variables" in Python (in the way you think of them).   There are only
objects and names.  Names can be thought of like void pointers in C, for
example.  They don't have a "type" themselves - they only refer to
objects, and the type of object they refer to can change at will.  Also,
there are no integers in Python.  Scalar values are actually objects. 
The number 35 is not an integer, it is an object that has an integer
type.  If you do a "dir(35)" in Python, you'll see that the object "35"
has more than 70 methods associated with it.   I'll stop there to avoid
information overload, but these are some of the key things a Python
newcomer needs to wrap their head around....

-Jim

[Chris Angelico]

On Sun, Jun 17, 2018 at 3:56 PM, Ben Finney <ben+p...@benfinney.id.au> wrote:
> Chris Angelico <ros...@gmail.com> writes:
>
>> On Sun, Jun 17, 2018 at 3:30 PM, Ben Finney <ben+p...@benfinney.id.au> wrote:
>> > (or, if you want to continue with the older less-flexible style,
>
> (I gave an unhelpful URL for that documentation. Try this instead
> <URL:https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting>.)
>
>> For the record, there's nothing at all wrong with printf-style
>> formatting; its flexibility and brevity make it extremely useful in
>> many situations.
>
> That isn't the impression I get from the above documentation. It starts
> with a clearly worded warning:
>
> Note
>
> The formatting operations described here exhibit a variety of quirks
> that lead to a number of common errors (such as failing to display
> tuples and dictionaries correctly). Using the newer formatted string
> literals or the str.format() interface helps avoid these errors.
> These alternatives also provide more powerful, flexible and
> extensible approaches to formatting text.
>
> That states a clear opinion that ‘str.format’ is preferred.

And yet we have had a firm statement that percent-formatting is not
going to be deprecated. Which is a clear statement that there's
nothing wrong with it. The only problem I'm aware of with tuples and
dicts is that a single parameter is misinterpreted, which is a minor
nit caused by the operator syntax; the format mini-language itself is
not affected by this. For instance, you can dodge the single-argument
problem thus:

>>> def sprintf(fmt, *args):
... return fmt % args
...
>>> sprintf("%s", (1, 2, 3))
'(1, 2, 3)'

Also: I would call that a "note", not a "warning". Please stop
spreading the FUD that there's somehow something "wrong" with using
what is a well-known convention for a format mini-language.

ChrisA

[Ben Finney]

Chris Angelico <ros...@gmail.com> writes:

> Also: I would call that a "note", not a "warning". Please stop
> spreading the FUD that there's somehow something "wrong" with using
> what is a well-known convention for a format mini-language.

If I say there's something “wrong” with it (is that different from
saying there's something wrong with it? I am not sure the function of
the quotes you use there), I'm not aware. I haven't stated the
printf-style formatting is especially prone to official deprecation.

As for a clear *preference*, as presented in the Python documentation,
for ‘str.format’ rather than printf-style, I'll continue to spread that
implication which seems a pretty uncontroversial reading of the Python
documentation.

--
\ “Beware of bugs in the above code; I have only proved it |
`\ correct, not tried it.” —Donald Knuth, 1977-03-29 |
_o__) |
Ben Finney

[Steven D'Aprano]

On Sat, 16 Jun 2018 23:11:41 -0700, Jim Lee wrote:

>   Python is not like other languages.

Python is not like languages like C, Pascal, Algol, Fortran, D, Java
(unboxed native values only) and those like that.

However, Python *is* like other languages like Javascript, Ruby, Java
(objects only), PHP, and others.

> For one thing, there are no
> "variables" in Python (in the way you think of them).

Indeed -- there are no variables in Python, if you think of a variable as
meaning a virtual box at a fixed memory address, containing a value, and
associated with a type, like in C or Pascal.

> There are only
> objects and names.  Names can be thought of like void pointers in C, for
> example.  They don't have a "type" themselves - they only refer to
> objects, and the type of object they refer to can change at will.

Very true.

> Also, there are no integers in Python.  Scalar values are actually
> objects. The number 35 is not an integer, it is an object that has an
> integer type.

I would put it another way. Python certainly has integers, but there are
no integers in C, there are only fixed-width collections of one or more
bytes. They don't have any integer methods, or methods at all.


--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

[Sharan Basappa]

Thanks a lot.

[Sharan Basappa]

Jim,

thanks a lot. Somehow, not one book I referred to brought out very clearly that everything in Python is an object including basic data types. Probably, they did and not so explicitly.

[Bart]

On 17/06/2018 09:43, Steven D'Aprano wrote:
> On Sat, 16 Jun 2018 23:11:41 -0700, Jim Lee wrote:
>
>>   Python is not like other languages.
>
> Python is not like languages like C, Pascal, Algol, Fortran, D, Java
> (unboxed native values only) and those like that.
>
> However, Python *is* like other languages like Javascript, Ruby, Java
> (objects only), PHP, and others.
>
>> For one thing, there are no
>> "variables" in Python (in the way you think of them).
>
> Indeed -- there are no variables in Python, if you think of a variable as
> meaning a virtual box at a fixed memory address, containing a value, and
> associated with a type, like in C or Pascal.

So what's a Type Hint associated with in Python?

--
bart

[Steven D'Aprano]

On Sun, 17 Jun 2018 17:19:38 +0100, Bart wrote:

>> Indeed -- there are no variables in Python, if you think of a variable
>> as meaning a virtual box at a fixed memory address, containing a value,
>> and associated with a type, like in C or Pascal.
>
> So what's a Type Hint associated with in Python?

By the interpreter itself? Pretty much nothing at all. Aside from
recording the annotation in the function object, the interpreter
completely ignores it.


py> def func(x: float) -> list:
... pass
...
py> func.__annotations__
{'x': <class 'float'>, 'return': <class 'list'>}

(Aside: in more recent versions of Python, the annotations are treated as
strings, not objects, and you will get {'x': 'float', 'return': 'list'}
instead.)


Since it is a type *hint*, not a type *declaration*, the interpreter can
and does ignore it. It makes no change at all to the execution model of
the language.

But the human reader, linters, IDEs and editors can associate it with the
name it annotates, and use it as a hint as to what is intended to happen,
and flag any discrepancies.

[Rick Johnson]

Chris Angelico wrote:
[...]

> For the record, there's nothing at all wrong with printf-style
> formatting; its flexibility and brevity make it extremely useful in
> many situations.

Except that it's old, not elegant, error prone, feature poor, and not Pythonic!

But besides all _that_ (and possibly more) it's slightly amusing, i suppose.

Cling to the past much?

What's wrong Chris, is the syntax of the new format method too difficult for you? Or do you have a personal disliking for anything OOP?

Personally, i would suggest the OP should learn the new Python formatting methods and disregard the legacy printf style crap that has been copy/pasted from countless other languages.

[Rick Johnson]

Steven D'Aprano wrote:

> Bart Wrote:
> > So what's a Type Hint associated with in Python?

> Since it is a type *hint*, not a type *declaration*, the
> interpreter can and does ignore it.

But yet, the _programmer_ cannot ignore it. Does that make
any sense to you, or anyone else with half a brain?

> It makes no change at all to the execution model of the
> language.

Then why the *HELL* are type-hints an official part of the
Python language syntax? Had type hints been implemented as
comments (for instance: a special class of comment in the
same way that doc-strings are a special class of strings),
then a programmer could ignore them! Heck, i have even have
a feature in my editor that will hide all comments and doc-
strings! And the code to perform this task is fairly simple.

But it's gonna one hell of a _nightmare_ to remove type-
hints from source code when they are _interleaved_ with the
damn source code, and considered by the interpreter to be
syntax.

> But the human reader, linters, IDEs and editors can
> associate it with the name it annotates, and use it as a
> hint as to what is intended to happen, and flag any
> discrepancies.

And each of these could have done the same with a "type-hint
comment". But oh no, that would be too easy! And the whole
point here is to cause a big fat ruckus? Isn't it, Mr.
D'Aprano?

[Jim Lee]

IMHO, trying to shoehorn static type checking on top of a dynamically
typed language shows that the wrong language was chosen for the job.

-Jim

[Chris Angelico]

On Mon, Jun 18, 2018 at 3:52 AM, Rick Johnson
<rantingri...@gmail.com> wrote:
> Chris Angelico wrote:
> [...]
>> For the record, there's nothing at all wrong with printf-style
>> formatting; its flexibility and brevity make it extremely useful in
>> many situations.
>
> Except that it's old, not elegant, error prone, feature poor, and not Pythonic!

[citation needed]

> But besides all _that_ (and possibly more) it's slightly amusing, i suppose.
>
> Cling to the past much?
>
> What's wrong Chris, is the syntax of the new format method too difficult for you? Or do you have a personal disliking for anything OOP?

What does "OOP" mean, exactly? Operators aren't, methods are?

> Personally, i would suggest the OP should learn the new Python formatting methods and disregard the legacy printf style crap that has been copy/pasted from countless other languages.
>

And that's the exact same FUD. Thank you for proving that a known
troll supports the FUD, which is a strong indication that it should be
ignored.

ChrisA

[Marko Rauhamaa]

Jim Lee <jle...@gmail.com>:

> IMHO, trying to shoehorn static type checking on top of a dynamically
> typed language shows that the wrong language was chosen for the job.

I'm also saddened by the type hinting initiative. When you try to be
best for everybody, you end up being best for nobody. The niche Python
has successfully occupied is huge. Why risk it all by trying to take the
whole cake?


Marko

[Chris Angelico]

On Mon, Jun 18, 2018 at 4:10 AM, Rick Johnson
<rantingri...@gmail.com> wrote:
> Steven D'Aprano wrote:
>> Bart Wrote:
>> > So what's a Type Hint associated with in Python?
>> Since it is a type *hint*, not a type *declaration*, the
>> interpreter can and does ignore it.
>
> But yet, the _programmer_ cannot ignore it. Does that make
> any sense to you, or anyone else with half a brain?

You're absolutely right. We should eliminate the 'assert' keyword
(since the interpreter can and does ignore assertions in optimized
mode), comments, and blank lines. Anyone with half a brain will see at
once that they should obviously be removed. Anyone with an entire
brain, of course, will appreciate them.

>> It makes no change at all to the execution model of the
>> language.
>
> Then why the *HELL* are type-hints an official part of the
> Python language syntax? Had type hints been implemented as
> comments (for instance: a special class of comment in the
> same way that doc-strings are a special class of strings),
> then a programmer could ignore them!

Huh. Funny you should say that.

https://www.python.org/dev/peps/pep-0484/#type-comments

ChrisA

[Chris Angelico]

Did you complain when function annotations were introduced back in 2006?

https://www.python.org/dev/peps/pep-3107/

That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
actually that's longer ago than Node.js has even been around. Another
trendy language is Go... oh wait, that wasn't around in 2006 either.

Type annotations have been in Python for nearly twelve years; ten if
you count the actual release of Python 3.0. The thing that changed
more recently was that *non-type* annotations were deprecated, since
very few use-cases were found. When did the shoehorning happen,
exactly?

ChrisA

[Jim Lee]

On 06/17/2018 01:35 PM, Chris Angelico wrote:
> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa <ma...@pacujo.net> wrote:

> Did you complain when function annotations were introduced back in 2006?
>
> https://www.python.org/dev/peps/pep-3107/
>
> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
> actually that's longer ago than Node.js has even been around. Another
> trendy language is Go... oh wait, that wasn't around in 2006 either.
>
> Type annotations have been in Python for nearly twelve years; ten if
> you count the actual release of Python 3.0. The thing that changed
> more recently was that *non-type* annotations were deprecated, since
> very few use-cases were found. When did the shoehorning happen,
> exactly?
>
> ChrisA

What does time have to do with anything?  I wasn't using Python in
2006.  A bad idea is a bad idea, regardless of *when* it was conceived.

-Jim


-Jim

[Marko Rauhamaa]

Chris Angelico <ros...@gmail.com>:

> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa <ma...@pacujo.net> wrote:
>> I'm also saddened by the type hinting initiative. When you try to be
>> best for everybody, you end up being best for nobody. The niche Python
>> has successfully occupied is huge. Why risk it all by trying to take the
>> whole cake?
>
> Did you complain when function annotations were introduced back in 2006?

No. I have yet to see them in the wild. I hope never to see them.

Do you mean you must like them by now?

> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
> actually that's longer ago than Node.js has even been around. Another
> trendy language is Go... oh wait, that wasn't around in 2006 either.

What are you talking about?


Marko

[Chris Angelico]

On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee <jle...@gmail.com> wrote:
>
>
> On 06/17/2018 01:35 PM, Chris Angelico wrote:
>>

>> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa <ma...@pacujo.net> wrote:
>>>

>> Did you complain when function annotations were introduced back in 2006?
>>

>> https://www.python.org/dev/peps/pep-3107/

>>
>> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
>> actually that's longer ago than Node.js has even been around. Another
>> trendy language is Go... oh wait, that wasn't around in 2006 either.
>>

>> Type annotations have been in Python for nearly twelve years; ten if
>> you count the actual release of Python 3.0. The thing that changed
>> more recently was that *non-type* annotations were deprecated, since
>> very few use-cases were found. When did the shoehorning happen,
>> exactly?
>>
>> ChrisA
>
> What does time have to do with anything? I wasn't using Python in 2006. A
> bad idea is a bad idea, regardless of *when* it was conceived.
>

You talk about "risk it all by trying to take the whole cake" as if
annotations are a change. But if they were already around before you
first met the language, then they're just part of the language. You
might as well argue against the += operator or list comprehensions.

ChrisA

[Dan Stromberg]

I actually really like Python's type hinting, which I've recently started
using. I've now used it on 10 projects, and I imagine I'll be using it in
many more.

Don't like them? I guess you don't have to use them.

[Jim Lee]

On 06/17/2018 01:56 PM, Chris Angelico wrote:
> On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee <jle...@gmail.com> wrote:
>>
>> On 06/17/2018 01:35 PM, Chris Angelico wrote:
>>> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa <ma...@pacujo.net> wrote:

>>> Did you complain when function annotations were introduced back in 2006?
>>>
>>> https://www.python.org/dev/peps/pep-3107/
>>>
>>> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
>>> actually that's longer ago than Node.js has even been around. Another
>>> trendy language is Go... oh wait, that wasn't around in 2006 either.
>>>
>>> Type annotations have been in Python for nearly twelve years; ten if
>>> you count the actual release of Python 3.0. The thing that changed
>>> more recently was that *non-type* annotations were deprecated, since
>>> very few use-cases were found. When did the shoehorning happen,
>>> exactly?
>>>
>>> ChrisA
>> What does time have to do with anything? I wasn't using Python in 2006. A
>> bad idea is a bad idea, regardless of *when* it was conceived.
>>
> You talk about "risk it all by trying to take the whole cake" as if
> annotations are a change. But if they were already around before you
> first met the language, then they're just part of the language. You
> might as well argue against the += operator or list comprehensions.
>
> ChrisA

You seem to have lost the attribution to those comments in your reply. 
I wasn't the one who talked about

"risk it all by trying to take the whole cake".

-Jim

[Chris Angelico]

On Mon, Jun 18, 2018 at 7:10 AM, Jim Lee <jle...@gmail.com> wrote:
>
>
> On 06/17/2018 01:56 PM, Chris Angelico wrote:
>>
>> On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee <jle...@gmail.com> wrote:
>>>
>>>
>>> On 06/17/2018 01:35 PM, Chris Angelico wrote:
>>>>
>>>> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa <ma...@pacujo.net>
>>>> wrote:
>>>>>

>>>> Did you complain when function annotations were introduced back in 2006?
>>>>
>>>> https://www.python.org/dev/peps/pep-3107/
>>>>
>>>> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
>>>> actually that's longer ago than Node.js has even been around. Another
>>>> trendy language is Go... oh wait, that wasn't around in 2006 either.
>>>>
>>>> Type annotations have been in Python for nearly twelve years; ten if
>>>> you count the actual release of Python 3.0. The thing that changed
>>>> more recently was that *non-type* annotations were deprecated, since
>>>> very few use-cases were found. When did the shoehorning happen,
>>>> exactly?
>>>>
>>>> ChrisA
>>>
>>> What does time have to do with anything? I wasn't using Python in 2006.
>>> A
>>> bad idea is a bad idea, regardless of *when* it was conceived.
>>>
>> You talk about "risk it all by trying to take the whole cake" as if
>> annotations are a change. But if they were already around before you
>> first met the language, then they're just part of the language. You
>> might as well argue against the += operator or list comprehensions.
>>
>> ChrisA
>
> You seem to have lost the attribution to those comments in your reply. I
> wasn't the one who talked about
>

> "risk it all by trying to take the whole cake".
>

My apologies, stuff wrapped and I misread as I skimmed back. You were
the one who used the word "shoehorned". In the same way, that sounds
like you already knew the language, and then someone added extra
features that don't fit. It's not shoehorning if the feature was
already there before you met the language.

The point is the same, the citation incorrect. Mea culpa.

ChrisA

[Marko Rauhamaa]

Dan Stromberg <drsa...@gmail.com>:

I that were true, fine. I'm most afraid of it becoming an
all-encompassing fad that can't be avoided.

So far so good.


Marko

[Cameron Simpson]

On 17Jun2018 11:10, Rick Johnson <rantingri...@gmail.com> wrote:
>Steven D'Aprano wrote:

>> But the human reader, linters, IDEs and editors can
>> associate it with the name it annotates, and use it as a
>> hint as to what is intended to happen, and flag any
>> discrepancies.
>
>And each of these could have done the same with a "type-hint
>comment". But oh no, that would be too easy! And the whole
>point here is to cause a big fat ruckus? Isn't it, Mr.
>D'Aprano?

No, it is so that there can be an agreed syntax for this stuff rather than a
billion funky special comments, and also so that _compiled_ python can be
inspected for type hints because they survive that step. This makes for machine
inspectable hints very easily, and that is a boon for linters.

Another advantage of type hints being part of the syntax is that
invalid/mistyped type hints can be caught by the parser. If they're just
special comments then linters _might_ see them and complain, or equally they
might say "this comment isn't a valid type hint, so it is an ordinary comment",
silently ignoring it. Thus weakening the lint.

As for the runtime ignoring them: they can't accomodate all situations in a
dynamic language, and type checking would impose a performance penalty for no
semantic effect.

Cheers,
Cameron Simpson <c...@cskk.id.au>

[Rick Johnson]

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.

Personally, i would never put type-hints in my Python code.
I write a large portion of my overall code in Python
specifically because i do not wish to be distracted by type
declarations.

Of course, regardless of how much i try to avoid type-hints,
the problem will come, when one day in the future, i am
forced to maintain another Python programmer's code that is
littered with these declarations. And removing them won't be
easy.

But that's the real danger of this feature. The Python
community will not see the real effect of type-hints (at
least, as they are currently implemented) for a long time.
But as more and more type-hints are spread in the wild, more
and more people, and more and more organizations, are going
to look for "cleaner language" to solve their R&D and
general purpose high-level problems.

What's the point of eye-ball-parsing through miles of type-
hints which demand all the burdens of static typing whilst
giving none of the real benefits. The Python interpreter
ignores these hints. But as programmers -- as, human beings,
and not machines! -- ignoring the syntactical noise of type-
hints will be impossible.

So either the Python devs need to release a
"3ToTypeHintFree.py", or they need to re-implement this so-
called feature as a special class of comment. And here is an
example of how that might be done, using Steven's example
from above:



## Steven's Example ##
#(Current implementation of type-hints)

py> def func(x: float) -> list:

"""Ello, ime-uh lit-al doc-string, yes i am."""
... pass




## Prposed solution v1 ##
py> def func(x):
"""Ello, ime-uh lit-al doc-string, yes i am."""
# x:float -> list
... pass

[Rick Johnson]

On Sunday, June 17, 2018 at 3:58:26 PM UTC-5, Dan Stromberg wrote:
[...]

> I actually really like Python's type hinting, which I've recently started
> using. I've now used it on 10 projects, and I imagine I'll be using it in
> many more.
>
> Don't like them? I guess you don't have to use them.

Go ahead an be cocky if you want to.

But just remember this:

People like myself will outright refuse to maintain your
code. And do you know what that means Dan? It means your
code will _die_! And then we will get paid to rewrite your
code.

Code that will be far more maintainable than the syntactical
mess you wrote. And if we want static typing -- no problem!
-- we'll convince out clients to switch to a language that
has *REAL* static typing.

Okay?

Howdya like that?

(shills gonna do what shills gonna do, i guess @_@)

[Rick Johnson]

Red herring!

[Chris Angelico]

On Mon, Jun 18, 2018 at 9:30 AM, Rick Johnson
<rantingri...@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?

ChrisA

[Jim Lee]

On 06/17/2018 02:17 PM, Chris Angelico wrote:
> [snip]

> My apologies, stuff wrapped and I misread as I skimmed back. You were
> the one who used the word "shoehorned". In the same way, that sounds
> like you already knew the language, and then someone added extra
> features that don't fit. It's not shoehorning if the feature was
> already there before you met the language.
>

> The point is the same, the citation incorrect. Mea culpa.
>
> ChrisA

Of course it is "shoehorning".  Why do you care when I started using the
language?  Shoehorning implies an attempt to add a feature that didn't
exist in the original design - a feature that is a difficult, awkward,
or ill-fitting complement to the original design.  Whether it happened
yesterday or 12 years ago is immaterial.  When I personally met the
language is also immaterial.

Microsoft "shoehorned" a Linux subsystem into Windows.  I don't even use
Windows, yet by your logic, I can't call it "shoehorning".


-Jim

[Chris Angelico]

Or maybe that's an indication of a change in design goals. Python's
original goal was to be very similar to C, and thus had a lot of
behaviours copied from C; up until Python 2.2, the default 'int' type
would overflow if it exceeded a machine word. Were long integers
shoehorned into the design, or does it indicate that the design was
modified to welcome them?

Personally, I think the Linux subsystem is (a) no different from (but
converse to) Wine, and (b) a good stepping-stone towards a Windows
release using a Unix kernel.

ChrisA

[Rick Johnson]

Chris Angelico wrote:
[...]

> Awwww. Isn't it cute, how he thinks that comments are easier to remove
> than other elements equally well defined in the grammar?

And may we see your code that will remove all instances of type-hints error free?

Hmm?

I look forward to scraping the internet for source code i can try it on, and then posting the tracebacks here for all to see.

[Chris Angelico]

First, show me your perfect comment removal code. Don't forget to
correctly handle different source code encodings, backslashes escaping
newlines, and triple-quoted strings. Then if that is proven easy, I'll
show you how a small tweak will remove any other syntactic element you
like.

And yes, I know exactly what tool I would use for the job. If I ever
had to do something so stupid.

ChrisA

[Rick Johnson]

On Sunday, June 17, 2018 at 9:22:57 PM UTC-5, Chris Angelico wrote:
> First,

No.

You're not squirming your way out this one Chris.

_You_ leveled the assertion that removing interleaved type-
hints from the executable code would be easier than removing
my proposed "type-hint comments".

What was the quote???

Oh, i remember:

"Awwww. Isn't it cute, how he thinks that comments are
easier to remove than other elements equally well defined
in the grammar?"

Now. Put up, or shut up.

> [...]

[Chris Angelico]

What was the quote before that?

> "Type-hint comments" would allow:

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

Put up or shut up. Write something that strips all type hint comments.

ChrisA

[Jim Lee]

I say: "frobnitz was broken".

You say: "you can't call frobnitz broken because it was broken before
you found out it was broken".


I say: "foo is bad".

You say: "foo is no different than bar (except it's the opposite), and
might eventually be like baz (which doesn't exist)."


Hard to argue with that kind of...umm...logic.  :)

-Jim

[Chris Angelico]

That isn't what I said, and you know it. I said that you can't decry
changes that were before your time (they're simply the way things
are). My comments about the Linux subsystem are parenthetical.

ChrisA

[Jim Lee]

Really?  Wow.  I'd hate to live in your world!  Just because something
exists, it can't be challenged or questioned.  Got it!

-Jim

[Marko Rauhamaa]

Jim Lee <jle...@gmail.com>:

> Really?  Wow.  I'd hate to live in your world!  Just because something
> exists, it can't be challenged or questioned.  Got it!

No need to get overly agitated just because someone says something
preposterous.


Marko

[Bart]

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.

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.

--
bart

[Chris Angelico]

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

[Bart]

On 18/06/2018 11:45, Chris Angelico wrote:
> On Mon, Jun 18, 2018 at 8:33 PM, Bart <b...@freeuk.com> wrote:


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

No. If syntax is defined on top of tokens, then at the token level, you
don't need to know any syntax. The process that scans characters looking
for the next token, will usually discard comments. Job done.

It is very different for type-hints as you will need to properly parse
the source code.

As a simpler example, if the task was the eliminate the "+" symbol, that
would be one kind of token; it would just be skipped when encountered.
But if the requirement to eliminate only unary "+", and leave binary
"+", then that can't be done at tokeniser level; it will not know the
context.

(The matter of leading white space sometimes being important, is a minor
detail. It just becomes a token of its own.)

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

What will those look like? If copyright/licence comments have their own
specific syntax, then they just become another token which has to be
recognised.

The main complication I can see is that, if this is really a one-time
source-to-source translator so that you will be working with the result,
then usually you will want to keep the comments.

Then it is a question of more precisely defining the task that such a
translator is to perform.

--
bart

[Chris Angelico]

On Mon, Jun 18, 2018 at 9:16 PM, Bart <b...@freeuk.com> wrote:
> On 18/06/2018 11:45, Chris Angelico wrote:
>>
>> On Mon, Jun 18, 2018 at 8:33 PM, Bart <b...@freeuk.com> wrote:
>
>
>
>>> 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.
>
>
> No. If syntax is defined on top of tokens, then at the token level, you
> don't need to know any syntax. The process that scans characters looking for
> the next token, will usually discard comments. Job done.

And it also will usually discard formatting (consecutive whitespace,
etc). So unless you're okay with reconstructing
functionally-equivalent code, rather than actually preserving the
original code, you cannot merely tokenize. You have to use a special
form of tokenization that actually keeps all that.

> It is very different for type-hints as you will need to properly parse the
> source code.
>
> As a simpler example, if the task was the eliminate the "+" symbol, that
> would be one kind of token; it would just be skipped when encountered. But
> if the requirement to eliminate only unary "+", and leave binary "+", then
> that can't be done at tokeniser level; it will not know the context.

Right. You can fairly easily reconstruct code that uses a single
newline for any NEWLINE token, and a single space in any location
where whitespace makes sense. It's not so easy to correctly
reconstruct "x*y + a*b" with the original spacing.

> What will those look like? If copyright/licence comments have their own
> specific syntax, then they just become another token which has to be
> recognised.

If they have specific syntax, they're not comments, are they?

> The main complication I can see is that, if this is really a one-time
> source-to-source translator so that you will be working with the result,
> then usually you will want to keep the comments.
>
> Then it is a question of more precisely defining the task that such a
> translator is to perform.

Right, exactly. So you need to do an actual smart parse, which - as
mentioned - is functionally equivalent whether you're stripping
comments or some lexical token.

ChrisA

[Steven D'Aprano]

On Sun, 17 Jun 2018 11:10:55 -0700, Rick Johnson wrote:

> Steven D'Aprano wrote:

>> Bart Wrote:
>> > So what's a Type Hint associated with in Python?
>> Since it is a type *hint*, not a type *declaration*, the interpreter
>> can and does ignore it.
>
> But yet, the _programmer_ cannot ignore it.

The programmer can ignore it, just as they can ignore any other form of
documentation. Nobody is stopping you from writing:

result = function(the_string=42.5)

if you wish. Adding a type hint doesn't change that.



>> It makes no change at all to the execution model of the language.
>
> Then why the *HELL* are type-hints an official part of the Python
> language syntax?

Just to annoy you.



--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

[Steven D'Aprano]

On Mon, 18 Jun 2018 06:35:40 +1000, Chris Angelico wrote:

> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa <ma...@pacujo.net>
> wrote:
>> Jim Lee <jle...@gmail.com>:

>>> IMHO, trying to shoehorn static type checking on top of a dynamically
>>> typed language shows that the wrong language was chosen for the job.
>>

>> I'm also saddened by the type hinting initiative. When you try to be
>> best for everybody, you end up being best for nobody. The niche Python
>> has successfully occupied is huge. Why risk it all by trying to take
>> the whole cake?
>
> Did you complain when function annotations were introduced back in 2006?
>
> https://www.python.org/dev/peps/pep-3107/
>
> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
> actually that's longer ago than Node.js has even been around. Another
> trendy language is Go... oh wait, that wasn't around in 2006 either.

Yes, but in fairness, people have abandoned Python by the handful for Go
and Javascript. At the rate people are abandoning Python, in another 10
or 20 years Python will have dropped to the second most popular language:

http://pypl.github.io/PYPL.html

[Steven D'Aprano]

On Mon, 18 Jun 2018 06:56:56 +1000, Chris Angelico wrote:

> You talk about "risk it all by trying to take the whole cake" as if
> annotations are a change. But if they were already around before you
> first met the language, then they're just part of the language. You
> might as well argue against the += operator or list comprehensions.

I still think that Python has been going nowhere but downhill ever since
extended slicing was added in version 1.4.

[Chris Angelico]

Oh, I forgot about that. That's why Guido is busily stuffing it with
every feature he possibly can, in the hope that - once Python runs out
of popularity - it'll at least... actually, you know what, I got
nothing.

ChrisA

[Steven D'Aprano]

On Sun, 17 Jun 2018 16:46:05 -0700, Rick Johnson wrote:

> People like myself will outright refuse to maintain your code.

Whew Dan, you dodged a bullet there.

[Bart]

On 18/06/2018 12:33, Chris Angelico wrote:
> On Mon, Jun 18, 2018 at 9:16 PM, Bart <b...@freeuk.com> wrote:

>> What will those look like? If copyright/licence comments have their own
>> specific syntax, then they just become another token which has to be
>> recognised.
>
> If they have specific syntax, they're not comments, are they?

So how is it possible for ANY program to determine what kind of comments
they are?

I've used 'smart' comments myself, which contain special information,
but are also designed to be very easily detected by the simplest of
programs which scan the source code. For that purpose, they might start
with a special prefix so that it is not necessary to parse the special
information, but just to detect the prefix.

For example, comments that start with #T# (and in my case, that begin at
the start of a line). Funnily enough, this also provided type
information (although for different purposes than what is discussed here).

>> The main complication I can see is that, if this is really a one-time
>> source-to-source translator so that you will be working with the result,
>> then usually you will want to keep the comments.
>>
>> Then it is a question of more precisely defining the task that such a
>> translator is to perform.
>
> Right, exactly. So you need to do an actual smart parse, which - as
> mentioned - is functionally equivalent whether you're stripping
> comments or some lexical token.

The subject is type annotation. Presumably there is some way to
distinguish such a type annotation within a comment from a regular
comment? Such as the marker I suggested above.

Then the tokeniser just needs to detect that kind of comment rather than
need to understand the contents.

Although the tokeniser will need to work a little differently by
maintaining the positions of all tokens within the line, information
that is usually discarded.

--
bart

[Marko Rauhamaa]

Chris Angelico <ros...@gmail.com>:

> On Mon, Jun 18, 2018 at 9:50 PM, Steven D'Aprano
> <steve+comp....@pearwood.info> wrote:
>> On Mon, 18 Jun 2018 06:35:40 +1000, Chris Angelico wrote:
>>
>>> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa <ma...@pacujo.net>
>>> wrote:
>>>> I'm also saddened by the type hinting initiative. When you try to
>>>> be best for everybody, you end up being best for nobody. The niche
>>>> Python has successfully occupied is huge. Why risk it all by trying
>>>> to take the whole cake?
>>>
>>> Did you complain when function annotations were introduced back in
>>> 2006?

>>> [...]

>>
>> Yes, but in fairness, people have abandoned Python by the handful for
>> Go and Javascript. At the rate people are abandoning Python, in
>> another 10 or 20 years Python will have dropped to the second most
>> popular language:
>>
>> http://pypl.github.io/PYPL.html
>>
>
> Oh, I forgot about that. That's why Guido is busily stuffing it with
> every feature he possibly can, in the hope that - once Python runs out
> of popularity - it'll at least... actually, you know what, I got
> nothing.

So the point *was* popularity!? I suspected as much.


Marko

[Chris Angelico]

On Mon, Jun 18, 2018 at 10:07 PM, Bart <b...@freeuk.com> wrote:
> On 18/06/2018 12:33, Chris Angelico wrote:
>>
>> On Mon, Jun 18, 2018 at 9:16 PM, Bart <b...@freeuk.com> wrote:
>
>
>>> What will those look like? If copyright/licence comments have their own
>>> specific syntax, then they just become another token which has to be
>>> recognised.
>>
>>
>> If they have specific syntax, they're not comments, are they?
>
>
> So how is it possible for ANY program to determine what kind of comments
> they are?
>
> I've used 'smart' comments myself, which contain special information, but
> are also designed to be very easily detected by the simplest of programs
> which scan the source code. For that purpose, they might start with a
> special prefix so that it is not necessary to parse the special information,
> but just to detect the prefix.
>
> For example, comments that start with #T# (and in my case, that begin at the
> start of a line). Funnily enough, this also provided type information
> (although for different purposes than what is discussed here).

Oh, a specific format of comments? Sorry, I misunderstood.

Yes, it is certainly possible to start with a program that removes all
comments, and then refine it to one which only removes those which
(don't) match some pattern. That's definitely a possibility.

> The subject is type annotation. Presumably there is some way to distinguish
> such a type annotation within a comment from a regular comment? Such as the
> marker I suggested above.
>
> Then the tokeniser just needs to detect that kind of comment rather than
> need to understand the contents.
>
> Although the tokeniser will need to work a little differently by maintaining
> the positions of all tokens within the line, information that is usually
> discarded.

Pretty much, yes. It's going to end up basically in the same place, though:

1) Parse the code, keeping all the non-essential parts as well as the
essential parts.
2) Find the comments, or find the annotations
3) If comments, figure out if they're the ones you want to remove.
4) Reconstruct the file without the bits you want to remember.

Step 3 is removed if you're using syntactic annotations. Otherwise,
they're identical.

ChrisA

[Ed Kellett]

On 2018-06-18 13:18, Chris Angelico wrote:
> 1) Parse the code, keeping all the non-essential parts as well as the
> essential parts.
> 2) Find the comments, or find the annotations
> 3) If comments, figure out if they're the ones you want to remove.
> 4) Reconstruct the file without the bits you want to remember.
>
> Step 3 is removed if you're using syntactic annotations. Otherwise,
> they're identical.

It's likely that Python comments are much easier to remove than
arbitrary bits of Python syntax--you need to know the answer to "am I in
a string literal?", which is a lexical analysis problem you could hack
together a solution for over the course of about one coffee, as opposed
to "where exactly am I in the Python parse tree?", which is... harder.
The information you need to keep track of and later reconstruct is
substantially simpler, too.

I don't think "they're hard to mechanically remove" is a particularly
good argument against type hints, but considered on its own it probably
is true.

[Steven D'Aprano]

On Sun, 17 Jun 2018 12:07:14 -0700, 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.

The experience of computer languages like Lisp, Smalltalk/StrongTalk,
Erlang, Racket, Javascript variant Typescript, and PHP variant Hack (to
mention only a few) shows that type hinting on top of dynamic languages
can and does work very well.

As a human programmer, you surely perform your own ad hoc type checking
when you write and debug code. When reading a function like this:

# from the calender.py module in the standard library
def isleap(year):
"""Return True for leap years, False for non-leap years."""
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

naturally you reason that year is probably an integer, not a list of
strings, and if you see code call:

isleap("hello")

you almost certainly realise it will fail without needing to run the
code. Having an automated checker or linter do something similar is
neither rocket science, nor against the spirit of dynamic typing.

Linters have done some type-checking for many years. One popular
convention was Sphinx-based type annotations in docstrings:

http://www.pydev.org/manual_adv_type_hints.html


Across the programming language landscape, dynamic languages are adding
static features, and static languages are adding dynamic features:

http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

Since Steve Yegge gave that talk, the process has only accelerated,
driven by both practical experience with gradual typing and a lot of
academic research.

PySonar has been successfully used by Google for close on a decade:

https://yinwang0.wordpress.com/2010/09/12/pysonar/

and MyPy has also been very successful:

http://mypy-lang.org/

particular at DropBox, which is (I believe) funding a lot of Guido's time
on this, because they need it.

It is 2018. People who say that static typing cannot be integrated with
dynamic languages are nearly half a century behind the state of the art
in computer programming.

(As an industry, the programming community is *painfully* conservative.
Things which Lisp was doing in the 1950s are *still* not mainstream, and
most programmers do not even imagine they are possible.)

[Gregory Ewing]

Bart wrote:
> 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.

What was being talked about wasn't removing *all* comments,
but removing just the ones that contain type hints.

> But to remove type hints, a deeper understanding of the input is needed.
> I would need a parser rather than a tokeniser.

Fortunately, Python comes with a parser for Python built
in (the ast module). So you get quite a good head start.

--
Greg

[Steven D'Aprano]

On Mon, 18 Jun 2018 15:11:05 +0300, Marko Rauhamaa wrote:

[...]

> So the point *was* popularity!? I suspected as much.

Presumably you missed the invisible sarcasm tags.

As well as the point that despite all the "type annotation is killing
Python" FUD from certain corners of the Python community, Python is not
only alive and well, but actually growing in popularity according to (as
far as I can see) all the well-known measures of language popularity.

Personally I don't think that type annotations are specifically driving
that increase in popularity, but there is no evidence that they are
harming it.

[Steven D'Aprano]

Further to my earlier comments...

On Sun, 17 Jun 2018 12:07:14 -0700, 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.

Relevant:

http://lambda-the-ultimate.org/node/1519

and this quote is extremely pertinent:

Giving people a dynamically-typed language does not mean
that they write dynamically-typed programs.
-- John Aycock


Lots of people have observed that *nearly all* real Python code is much
less dynamic than the language allows. When you call "len(x)", the
compiler has to resolve the name "len" at runtime in case it has been
monkey-patched or shadowed, but in practice that hardly ever happens.

Moving the type-checking out of the core language into the IDE or linter
which can be used or not used according to the desire of the programmer
is an elegant (partial) solution to the problem that testing can never
demonstrate the absence of bugs, only their presence, without
compromising on the full range of dynamic programming available to those
who want it.

[Schachner, Joseph]

As soon as I sent the previous message I realized it's "doc string" not def string. Pardon me.
--- Joe S.

[Rick Johnson]

Chris Angelico wrote:
[...]

> What was the quote before that?
>
> > "Type-hint comments" would allow:

> > (3) and those who utterly *HATE* them, to write a simpl[e]

> > little function which will strip them from any and all
> > source code they might be forced to maintain.
>
> Put up or shut up. Write something that strips all type
> hint comments.

"Type-hint comments" don't exist yet. They are only
theoretical at this point. Now stop distracting, and let's
see your code!

[Rick Johnson]

Jim Lee wrote:

> Chris wrote:
> >
> > I said that you can't decry changes that were before
> > your time (they're simply the way things are).
>

> Really? Wow. I'd hate to live in your world! Just
> because something exists, it can't be challenged or
> questioned. Got it!

Chris is a good choir boy. He consistently ranks a perfect
10 out 10 on parochial surveys.

[Ian Kelly]

Uh, yes, they do. They're defined in PEP 484, and Mypy uses them for
type-checking Python 2 code, where the annotations don't exist.

https://mypy.readthedocs.io/en/stable/python2.html?highlight=comment#type-checking-python-2-code

[Rick Johnson]

On Monday, June 18, 2018 at 5:45:28 AM UTC-5, Chris Angelico wrote:

> So in both cases, you would probably end up with something
> like 2to3.

And there you have it!

Just Like Python3000, the python devs have caused a major
disruption by saddling us with the syntactic noise of type-
hints. Therefore, _they_ are responsible for producing a
tool which will remove these type-hints from scripts and do
it error _free_.

So petition your friends over at py-dev and get the ball
rolling, would ya pal?

And the great news is, after they release this tool, myself,
and all the other folks who have been blindsided by a
special purpose feature can no longer complain. Nope. And
you will _finally_ have the moral high ground when you brow
beat others for daring to protest.

That's right Chris!

We will quietly run the tool on all the type-hint scripts we
encounter and then we will be as content as you.

Why can't we _all_ be happy little clams just like you?

Hmm?

Is that really too much to ask?

[Rick Johnson]

Chris Angelico wrote:
> Bart wrote:
[...]
> > What will those look like? If copyright/license comments

> > have their own specific syntax, then they just become

> > another token which has to be recognized.

>
> If they have specific syntax, they're not comments, are they?

Yes, they are.

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

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

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

After all, it's the Python way.

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.

[Ben Bacarisse]

Bart <b...@freeuk.com> writes:

> On 18/06/2018 11:45, Chris Angelico wrote:
>> On Mon, Jun 18, 2018 at 8:33 PM, Bart <b...@freeuk.com> wrote:
>
>
>>> 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.
>
> No. If syntax is defined on top of tokens, then at the token level,
> you don't need to know any syntax. The process that scans characters
> looking for the next token, will usually discard comments. Job done.

You don't even need to scan for tokens other than strings. From what I
read in the documentation a simple scanner like this would do the trick:

%option noyywrap
%x sqstr dqstr sqtstr dqtstr
%%

\' ECHO; BEGIN(sqstr);
\" ECHO; BEGIN(dqstr);
\'\'\' ECHO; BEGIN(dqtstr);
\"\"\" ECHO; BEGIN(dqtstr);

<dqstr>\" |
<sqstr>\' |
<sqtstr>\'\'\' |
<dqtstr>\"\"\" ECHO; BEGIN(INITIAL);

<sqstr>\\\' |
<dqstr>\\\" |
<sqstr,dqstr,sqtstr,dqtstr,INITIAL>. ECHO;

#.*

%%
int main(void) { yylex(); }

and it's only this long because there are four kinds of string. Not
being a Python expert, there may be some corner case errors. And really
there are comments that should not be removed such as #! on line 1 and
encoding declarations, but they would just need another line or two.

--
Ben.

[Rick Johnson]

On Monday, June 18, 2018 at 6:43:36 AM UTC-5, Steven D'Aprano wrote:
> The programmer can ignore [type-hints], just as they can

> ignore any other form of documentation.

Type-hints, as implemented, break all the rules of
conventional documentation. In any programming language i
have ever seen, formal documentation elements such as
documentation strings and comments do not _interleave_
themselves with executable code, no, they are forced to
isolate themselves on entire lines, or, the tail ends of
lines. For instance, i have never seem a dynamic programming
language that did anything like the following:

def foo():
for k<k is a string>,v<v is a integer> in d<d is a dict>:
print<that is a built-in>(k, v)

Have you??? Maybe i'm crazy, but i would prefer to have my
_documentation_ and executable-code separated from one
another.

def foo():
# Iterate over the keys of d
# k: string
# v: integer
# d: dict (duh!)
for k,v in d:
print(k, v) # That was builtin!

> Nobody is stopping you from writing:
>
> result = function(the_string=42.5)

Steven, that's an example of "self-documenting names" not
"documentation". I'm sorry, but you are terribly confused if
you cannot understand the non-subtle difference between
these two concepts.

> [we do it] Just to annoy you.

You're also terribly confused if you believe i'm the only
person in this community who is opposed to the current
implementation of type-hints. Remember, i'm not advocating
that type-hints be removed completely (the train has left
the station). I'm only requesting that one of the following
be done to _alleviate_ the burden of their poorly executed
implementation:

(1) Re-implement type-hints as a comment.

(2) Provide a tool that will remove type-hints from scripts
error free.

Is that _really_ too much to ask?

[Rick Johnson]

On Monday, June 18, 2018 at 6:57:27 AM UTC-5, Steven D'Aprano wrote:
> I still think that Python has been going nowhere but downhill ever since
> extended slicing was added in version 1.4.

Apples to oranges!

[Rick Johnson]

Bart wrote:
[...]

> For example, comments that start with #T# (and in my case,
> that begin at the start of a line).

Such would be a _breeze_ to parse out. And i would argue
(given a sufficiently unique tag) that arbitrary white space
would not be any more error prone, either. Thus, your
"tagged comments" would be much more readable as they will
match the current block indentation and not be smashed
against the left most column.

"Readability counts!".

[Rick Johnson]

Steven D'Aprano wrote:
[...]

> particular at DropBox, which is (I believe) funding a lot of Guido's time
> on this, because they need it.

And now we get to the truth!

Guido's new puppet master is the sole reason why this fine community -- of once free-roaming *STALLIONS*-- is now corralled and saddled with type-hints!

And we thoughts _google_ was evil. o_O

[Ed Kellett]

are you someone's ironic 3rd-year art project

[Rick Johnson]

Steven D'Aprano said:
> Python is not only alive and well, but actually growing in
> popularity according to (as far as I can see) all the well-
> known measures of language popularity.

Steven *ALSO* said:
> "Ever since I learned about confirmation bias, I've been
> seeing it everywhere."

Hmm?

[Rick Johnson]

Steven D'Aprano wrote:
> Moving the type-checking out of the core language into the
> IDE or linter which can be used or not used according to
> the desire of the programmer

Except, what your poppycock commentary seems to glaze over is
the fact that whilst a programmer can certainly decided to
"use or not use" the type-hints feature in his or her own
code, he or she certainly cannot "see or _unsee_" type-hints
that are written by other programmers.

[Rick Johnson]

Ian wrote:

> Uh, yes, they do. They're defined in PEP 484, and Mypy uses them for
> type-checking Python 2 code, where the annotations don't exist.

So when will the interleaved type-hints be removed from the language specification?

[Jim Lee]

On 06/18/2018 07:03 AM, Steven D'Aprano wrote:
> As a human programmer, you surely perform your own ad hoc type checking
> when you write and debug code.

Of course.  And, I use linting tools and other forms of static type
checking.  What I don't like is adding the *syntax* for static type
checking to the (dynamically typed) language proper, particularly when
the implementations of said language do nothing but ignore it.

The syntax should be defined inside comments, by the tools that actually
need to use them.  Let the tools do what they were designed to do.  Let
the language do what it was designed to do.

If static type checking were a high priority, I would not choose a
language like Python for the task - but some people seem to want to beat
the language into submission as a do-everything-but-wash-my-car
solution; and in so doing, the language becomes so fragile and bloated
that people will walk away from it.

In reading through many of the PEPs, I'm reminded of the saying, "If all
you have is a hammer, everything looks like a nail".

-Jim

[Chris Angelico]

On Tue, Jun 19, 2018 at 3:34 AM, Jim Lee <jle...@gmail.com> wrote:
>
>
> On 06/18/2018 07:03 AM, Steven D'Aprano wrote:
>>
>> As a human programmer, you surely perform your own ad hoc type checking
>> when you write and debug code.
>
> Of course. And, I use linting tools and other forms of static type
> checking. What I don't like is adding the *syntax* for static type checking
> to the (dynamically typed) language proper, particularly when the
> implementations of said language do nothing but ignore it.

So you have annotations for type information. Tell me: why should
these annotations be introduced with a hash and ended with a newline?
What is it about type annotations that requires that they be delimited
in this way?

What about assertions? Are they comments too? Should we have, for instance:

if x > 0:
...
elif x < 0:
...
else:
#assert: x == 0
...

or is it better to use an 'assert' statement? After all, they can
legitimately be ignored by the interpreter.

ChrisA

[Ian Kelly]

On Mon, Jun 18, 2018 at 11:39 AM Jim Lee <jle...@gmail.com> wrote:
> On 06/18/2018 07:03 AM, Steven D'Aprano wrote:
> > As a human programmer, you surely perform your own ad hoc type checking
> > when you write and debug code.
> Of course. And, I use linting tools and other forms of static type
> checking. What I don't like is adding the *syntax* for static type
> checking to the (dynamically typed) language proper, particularly when
> the implementations of said language do nothing but ignore it.
>

> The syntax should be defined inside comments, by the tools that actually
> need to use them. Let the tools do what they were designed to do. Let
> the language do what it was designed to do.

If you want to use a type checking tool that uses type comments, then
by all means do so. The existence of annotation syntax in no way
prevents that.

When PEP 3107 was written, it was anticipated that annotations would
find more uses than just type hinting. Some of those proposed ideas
(e.g. database query mapping) depend on the annotation being readable
at run-time, for which a comment would be wholly inadequate. In
practice, I don't think that has really been borne out. Still, the
intention was to make the language more flexible, not just to cram in
type hinting, and I don't think that was necessarily a bad idea.

PEP 484 was created out of the observation that the community of
static type analysis tools that has grown out of PEP 3107 would
benefit from a common dialect of types. All it does is provide that.

Neither of these are forcing you to use a type checker that requires
annotations for type hints rather than comments, if that's what you
prefer. The annotation-based checker is probably a fair bit easier to
build from the maintainer's standpoint, though, since it can rely on
existing parsing tools and the typing module.

[Jim Lee]

On 06/18/2018 10:46 AM, Chris Angelico wrote:

> On Tue, Jun 19, 2018 at 3:34 AM, Jim Lee <jle...@gmail.com> wrote:
>>
>> On 06/18/2018 07:03 AM, Steven D'Aprano wrote:
>>> As a human programmer, you surely perform your own ad hoc type checking
>>> when you write and debug code.
>> Of course. And, I use linting tools and other forms of static type
>> checking. What I don't like is adding the *syntax* for static type checking
>> to the (dynamically typed) language proper, particularly when the
>> implementations of said language do nothing but ignore it.

> So you have annotations for type information. Tell me: why should
> these annotations be introduced with a hash and ended with a newline?
> What is it about type annotations that requires that they be delimited
> in this way?

Uhhh....because that's mostly the definition of a comment?  Duh!

> What about assertions? Are they comments too? Should we have, for instance:
>
> if x > 0:
> ...
> elif x < 0:
> ...
> else:
> #assert: x == 0
> ...
>
> or is it better to use an 'assert' statement? After all, they can
> legitimately be ignored by the interpreter.
>
> ChrisA

I'm noticing a pattern here.  Can we stick to the subject at hand?

-Jim

[Chris Angelico]

On Tue, Jun 19, 2018 at 4:09 AM, Jim Lee <jle...@gmail.com> wrote:
>
>
> On 06/18/2018 10:46 AM, Chris Angelico wrote:
>>
>> On Tue, Jun 19, 2018 at 3:34 AM, Jim Lee <jle...@gmail.com> wrote:
>>>
>>>
>>> On 06/18/2018 07:03 AM, Steven D'Aprano wrote:
>>>>
>>>> As a human programmer, you surely perform your own ad hoc type checking
>>>> when you write and debug code.
>>>
>>> Of course. And, I use linting tools and other forms of static type
>>> checking. What I don't like is adding the *syntax* for static type
>>> checking
>>> to the (dynamically typed) language proper, particularly when the
>>> implementations of said language do nothing but ignore it.
>>
>> So you have annotations for type information. Tell me: why should
>> these annotations be introduced with a hash and ended with a newline?
>> What is it about type annotations that requires that they be delimited
>> in this way?
>
> Uhhh....because that's mostly the definition of a comment? Duh!

Yes, that's the definition of a comment. What is it about type
annotations that requires them to be comments? Please explain.

>> What about assertions? Are they comments too? Should we have, for
>> instance:
>>
>> if x > 0:
>> ...
>> elif x < 0:
>> ...
>> else:
>> #assert: x == 0
>> ...
>>
>> or is it better to use an 'assert' statement? After all, they can
>> legitimately be ignored by the interpreter.
>>
>> ChrisA
>
>
> I'm noticing a pattern here. Can we stick to the subject at hand?

Yes, but probably not the same pattern you are. What, fundamentally,
is the difference between type hints and assertions, such that - in
your view - one gets syntax and the other is just comments?

ChrisA

[Jim Lee]

On 06/18/2018 11:01 AM, Ian Kelly wrote:

> On Mon, Jun 18, 2018 at 11:39 AM Jim Lee <jle...@gmail.com> wrote:
>> On 06/18/2018 07:03 AM, Steven D'Aprano wrote:
>>> As a human programmer, you surely perform your own ad hoc type checking
>>> when you write and debug code.
>> Of course. And, I use linting tools and other forms of static type
>> checking. What I don't like is adding the *syntax* for static type
>> checking to the (dynamically typed) language proper, particularly when
>> the implementations of said language do nothing but ignore it.
>>

>> The syntax should be defined inside comments, by the tools that actually
>> need to use them. Let the tools do what they were designed to do. Let
>> the language do what it was designed to do.
> If you want to use a type checking tool that uses type comments, then
> by all means do so. The existence of annotation syntax in no way
> prevents that.

No, but it adds an awful lot of functionally inert noise to live code.

> When PEP 3107 was written, it was anticipated that annotations would
> find more uses than just type hinting. Some of those proposed ideas
> (e.g. database query mapping) depend on the annotation being readable
> at run-time, for which a comment would be wholly inadequate. In
> practice, I don't think that has really been borne out. Still, the
> intention was to make the language more flexible, not just to cram in
> type hinting, and I don't think that was necessarily a bad idea.
>
> PEP 484 was created out of the observation that the community of
> static type analysis tools that has grown out of PEP 3107 would
> benefit from a common dialect of types. All it does is provide that.
>
> Neither of these are forcing you to use a type checker that requires
> annotations for type hints rather than comments, if that's what you
> prefer. The annotation-based checker is probably a fair bit easier to
> build from the maintainer's standpoint, though, since it can rely on
> existing parsing tools and the typing module.

Thanks for the explanation, but it only reinforces my view.  The more
entrenched this feature becomes, the more we will see annotation-based
tools and, at some point, we will all be forced to used annotations in
order to take advantage of the tools.

-Jim

[Jim Lee]

On 06/18/2018 11:18 AM, Chris Angelico wrote:
> What, fundamentally, is the difference between type hints and
> assertions, such that - in
> your view - one gets syntax and the other is just comments?

Type hints are just that - hints.  They have no syntactic meaning to the
parser, and do not affect the execution path in any way. Therefore, they
are effectively and actually comments.  The way they have been
implemented, though, causes noise to be interspersed with live code and,
as others have said, are difficult to remove or ignore.

-Jim

[Chris Angelico]

I don't know what you mean by "syntactic meaning". Do you mean that
they create no executable bytecode, that they have no run-time
influence? Because that's not entirely true; they are stored, and can
be viewed at run-time. In fact, in optimized mode, assertions produce
no bytecode whatsoever; so by that definition, they are more comment-y
than annotations are. Do you have some other definition?

ChrisA

[Jim Lee]

I'm tired of running around in circles with you, so I will respectfully
decline to comment further.

-Jim

[Rick Johnson]

On Monday, June 18, 2018 at 12:46:36 PM UTC-5, Chris Angelico wrote:

> What about assertions? Are they comments too? Should we
> have, for instance:
>
> if x > 0:
> ...
> elif x < 0:
> ...
> else:
> #assert: x == 0
> ...
>
> or is it better to use an 'assert' statement? After all,
> they can legitimately be ignored by the interpreter.

(oh my!)

Of course they can "easily be ignored",

for cryin' out loud,

assert statements all begin with the same "syntactical
tag"!

okay, wait for it...

--> assert <--
^^^^^^

Yep!

Which BTW is a _keyword_.

(if you didn't know that already) *wink*

But please Chris, feel free to bring us your next logical
dead end.

[Ian Kelly]

These things are unrelated. The comment specification was added to
supplement type hints, not replace them.

[Rick Johnson]

On Monday, June 18, 2018 at 1:02:18 PM UTC-5, Ian wrote:
[...]

> When PEP 3107 was written, it was anticipated that
> annotations would find more uses than just type hinting.
> Some of those proposed ideas (e.g. database query mapping)
> depend on the annotation being readable at run-time, for
> which a comment would be wholly inadequate.

That's a BS excuse! Any tool can pre-process a python script
simply by reading the source from disc before passing it
off to the Python interpreter. It's a simple matter of
_delegation_.

[Rick Johnson]

On Monday, June 18, 2018 at 1:50:09 PM UTC-5, Chris Angelico wrote:
[...]

> I don't know what you mean by "syntactic meaning". Do you mean that
> they create no executable bytecode, that they have no run-time
> influence? Because that's not entirely true; they are stored, and can
> be viewed at run-time.

So can doc-strings! Ever used the help(...) function?

[Chris Angelico]

Ahh, yes, it's easy to find the end of an assert statement, too, isn't
it? Or are you talking about properly parsing, which - as you
miiiiight recall - was my original point?

assert """
"""", ", ";print('Will I print?');\
"';print("Or will I?");\
';print("What about me?");'''\
print("And me? Where endeth");"""\
print('the assertion?');\''''

So easy to take shortcuts. So easy to get bitten. Isn't it nice how
Python provides proper parsing as a module, though? Except that, oh
how terrible, that makes it just as easy to find ALL syntactic
elements.

ChrisA

[Ian Kelly]

On Mon, Jun 18, 2018 at 10:19 AM Rick Johnson
<rantingri...@gmail.com> wrote:
> 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_.

If this is really your attitude, then I pity anybody who has the
misfortune to work with you. If a comment is wrong, the best course of
action is to fix it. Not to come to the conclusion that all comments
are useless or worse than useless and to therefore swear off reading
all comments forever more.

As most seasoned programmers would say, the most useful comments are
those that explain why, not what or how. What the code does or how it
does it can generally be understood just by reading the code. *Why*
the code does what it does often cannot. Here's an example of a bad
comment:

def num_threads():
# Use 10 threads.
return 20

We easily see the value is 20, but *should* it be 10 or 20? We don't
know. Now here's an example of a useful comment:

def num_threads():
# Use 10 threads because the system randomly
# locks up at 15 or more. (bug: 12345)
return 20

This one makes it clear that whoever increased the value from 10 to 20
wasn't paying attention. The change should likely be reverted.

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.

[Rhodri James]

On 18/06/18 19:21, Jim Lee wrote:
> Thanks for the explanation, but it only reinforces my view.  The more
> entrenched this feature becomes, the more we will see annotation-based
> tools and, at some point, we will all be forced to used annotations in
> order to take advantage of the tools.

So don't take advantage of the tools. They're just tools, and they may
be a help for programmers who can't be bothered to figure things out for
themselves, but they aren't required by any means.

--
Rhodri James *-* Kynesim Ltd

[Rhodri James]

On 18/06/18 19:34, Jim Lee wrote:
> Type hints are just that - hints.  They have no syntactic meaning to the
> parser,

This is plainly not true, otherwise the parser would be throwing syntax
errors at you all the time. Whether they have semantic meaning to the
parser is more debatable.

[Bart]

On 18/06/2018 15:03, Steven D'Aprano wrote:

> It is 2018. People who say that static typing cannot be integrated with
> dynamic languages are nearly half a century behind the state of the art
> in computer programming.

It can be, but it spoils the language. In the case of Python, it is
already so big and has so many features crammed in that adding type
hints probably makes little difference.

I spent a bit of time a decade ago with adding type hints to my own
dynamic language. It was done to improve performance, and yes some
benchmarks could be double the speed.

In the end I got rid of them to keep the language purer, smaller and
simpler. Other approaches which don't involve annotating source code
(eg. type inference) are better IMO.

One problem with them was that, if you said X was an int, you were
obliged to check it was int, otherwise bad things could happen if it
assumed X was int because you said so, and in reality it wasn't. That
checking doesn't help improve performance, which was one aim.

--
bart

[Chris Angelico]

On Tue, Jun 19, 2018 at 6:03 AM, Bart <b...@freeuk.com> wrote:
> In the end I got rid of them to keep the language purer, smaller and
> simpler. Other approaches which don't involve annotating source code (eg.
> type inference) are better IMO.

Inference is great when it works. How do you assist a type inference
engine, when it's unable to get all the information it needs? A type
system has to either be imperfect, or be an entire executable
programming language, or have additional information given to it.

ChrisA

[Rick Johnson]

Chris Angelico wrote:
[...]

> assert """
> """", ", ";print('Will I print?');\
> "';print("Or will I?");\
> ';print("What about me?");'''\
> print("And me? Where endeth");"""\
> print('the assertion?');\''''

Chris, that's not code...

That's a syntactical representation of some random flea circus.

[Chris Angelico]

Fortunately, my Python interpreter is able to execute flea circuses.

ChrisA

[Jim Lee]

On 06/18/2018 12:52 PM, Rhodri James wrote:
> On 18/06/18 19:34, Jim Lee wrote:
>> Type hints are just that - hints.  They have no syntactic meaning to
>> the parser,
>
> This is plainly not true, otherwise the parser would be throwing
> syntax errors at you all the time.  Whether they have semantic meaning
> to the parser is more debatable.
>

That's funny - arguing semantics over the difference between syntactic
and semantic.  If we're not careful, this conversation could become
recursive and blow up the Internet! :)

-Jim

[Rick Johnson]

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.

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.

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.

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

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.

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?