Using Python 2

[Steven D'Aprano]

On Mon, 11 Sep 2017 00:07:15 -0600, Ian Kelly wrote:

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

Ironically, many CS purists don't like type hinting and gradual typing 
because they aren't pure enough. Type hints are only a *hint*, the 
interpreter can and does ignore them, unlike type declarations in 
statically typed languages like Java and Haskell.

(And yes, I'm aware that Haskell does type inference. But when there's 
not enough information for the compiler to infer a type, you can declare 
one.)


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

Better linters, smarter editors with autocomplete, better code 
documentation, and most importantly, early detection of at least some 
bugs.


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

Indeed.

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

Indeed. C has separate header files for declarations and source code 
files, and that's widely acknowledged to be a mistake. In a programming 
ecosystem where many languages tend to slavishly follow C conventions, it 
is remarkable how few languages (I can't think of any) have copied the 
convention of separating the declaration (or hint) and the source code.


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

If nothing else, even if you have no linter and don't run mypy and are 
editing the code with Notepad, at least the annotation tells you what the 
author of the code expects the variable to be.


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

"Onerosity" or "onertude" would be the correct grammatical forms for the 
noun.


-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write 
virtualization layers without security holes.” —Theo de Raadt