[Python-ideas] PEP 484 evolution

[Nick Coghlan]

On 20 March 2016 at 06:14, Rick Johnson <rantingrickjohnson at gmail.com> wrote:
> On Sat, Mar 19, 2016 at 11:46 AM, Steven D'Aprano <steve at pearwood.info>
> wrote:
>
>> Take a deep breath and calm down. The type-hints are
>> completely optional and nobody will be forced to use them.
>
> I don't think it's fair for you to tell me to: "calm down
> because this won't effect you". What evidence are you basing
> that theory on?

The fact we've been down this road before, especially with the
introduction of ABCs (much of the fearful rhetoric around PEP 484
bears a striking similarity to that around PEP 3119 nigh on a decade
ago).

If the Python community were going to go overboard with explicit type
hints, we'd already see a large proportion of projects running pylint
with very strict configuration settings, or using the existing
typechecking tools like Google's pytypedecl. However, that's precisely
what we *don't* see - instead we see folks using those capabilities
responsibly, adopting them when the complexity of their project or
organisational structure calls for it, and omitting them otherwise.
(And many of the folks that don't have the relevant problems remain
puzzled as to why these tools that help improve maintainability for
large projects and large teams exist in the first place)

The fear response of "other people are going to overuse these, which
means *I'm* going to have to read a lot of code containing them, which
means programming in Python is going to become less fun" is perfectly
understandable, but isn't really backed up by the community's
collective behavioural history. (Monkeypatching, multiple inheritance
and metaclasses are other capabilities that fall into a similar
category - really powerful, and when you need them, you're grateful
they're there, but best avoided when you don't have a genuine need for
them)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia