Using Python 2

[Ian Kelly]

On Sun, Sep 10, 2017 at 10:06 AM, Rick Johnson
<rantingrickjohnson at gmail.com> wrote:
> Ian wrote:
>> Rick Johnson wrote:
>> > Ned Batchelder wrote:
>> > > Leam Hall wrote:
>> > > >
>> > > > I've read comments about Python 3 moving from the Zen of
>> > > > Python. I'm a "plain and simple" person myself.
>> > > > Complexity to support what CompSci folks want, which was
>> > > > used to describe some of the Python 3 changes, doesn't
>> > > > help me get work done.
>> > >
>> > > I've heard a lot of FUD about the Python 3 transition,
>> > > but this one is new to me.  What is it that CompSci folks
>> > > want that developers don't want, that ruined Python 3?
>> >
>> > TWO WORDS: "Type" and "Hints"
>>
>> Fail.
>>
>> 1. Type hints were only added in 3.5, not Python 3.0, so
>> this does not support the claim that Python 3 changes were
>> made to support CS.
>
> But it is true that CS purist want type annotations

Citation needed.

> "Practicality beats purity".

That's an odd mantra to use when you're arguing against a practical
feature in favor of keeping the language "pure".

>> 2. Type hints are completely optional, so this does not
>> support the claim that Python 3 added complexity that is
>> counter-productive to "simple" users. If you want to keep
>> your program simple, you can: just don't use them.
>
> True, individual programmers can choose to omit type-hints
> from their own code, but they cannot choose to omit type-
> hints from the code they are forced to read. Once type
> annotations start propagating in the wild, the syntactical
> noise of statically typed languages will be ever-present in
> Python code, only problem is, we will get *NONE* of the
> advantages of _real_ statically typed languages, namely:
> executables, compiler optimizations, and enhanced execution
> speed. Heck, all we get in return for our painful eyeball
> parsings are (maybe) better linters. Which is not an ROI
> worthy of my sweat equity.

Type hints aren't just for compilers, in the same way that comments
are not for compilers, well-named variables are not for compilers, and
readable code in general is not for the benefit of compilers.

>> 3. Type hints are practical. You may not need or desire
>> them for pet projects, but large-scale projects with a
>> large team of developers require a large degree of testing.
>> Static typing supports this. This is a feature for
>> enterprise users, not theorists.
>
> I was never against Python having a type annotation feature,
> no, i am only against the inclusion of this syntacticly noisy
> feature in the .py[w] files. Mandating that type annotations
> be defined in _external_ stub files places the onerous on
> those who care about type annotations (a micro minority of
> CS purist), and removes it from those who don't (the
> remaining majority of Python programmers).

If you're trying to actually understand the code that you're reading,
then having the type hints swept off in another file to be "out of
sight, out of mind" does not excuse you from the responsibility of
knowing and understanding what the type expectations of the code are.
You can guess, or you can read the author's explicit intentions. I
know which one I prefer.

Stub files exist for cases where it's not practical to type-hint the
actual code, such as third-party libraries that you want type hints
for but that you're not the maintainer of. Keeping type hints together
with the actual code is always preferable. You don't have to care
about type annotations, but when they happen to be present, then
everybody should care, because they're useful.

By the way, "onerous" is an adjective, not a noun.