[Python-Dev] Remove typing from the stdlib

[Paul Moore]

On 6 November 2017 at 03:41, Lukasz Langa <lukasz at langa.pl> wrote:
>
>> On 4 Nov, 2017, at 3:39 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> Lukasz Langa said:
>>> So, the difference is in perceived usability. It's psychological.
>>
>> Please, let's not start the "not in the stdlib isn't an issue" debate
>> again. If I concede it's a psychological issue, will you concede that
>> the fact that it's psychological doesn't mean that it's not a real,
>> difficult to solve, problem for some people? I'm also willing to
>> concede that it's a *minority* problem, if that helps. But can we stop
>> dismissing it as a non-existent problem?
>
> Paul, if you read the words I wrote in my e-mail verbatim, you will note that I am not saying it's not real or it's not important. Quite the opposite. Can you elaborate what made you think that my assertion that the issue is psychological made you think I'm being dismissive? To me it looks like you're aggressively agreeing with me, so I'd like to understand what caused your reaction.

Apologies. On rereading your email, I can see how you meant that.
However, it didn't come across that way to me on first reading. There
have been a few other threads on various lists I've been involved in
recently where it's been really hard to get anyone to see that there's
any practical issues for people if a module is on PyPI rather than
being in the stdlib. So I'm afraid I'd got pretty tired of arguing the
same points over and over again, and over-reacted to what I thought
you said.

To explain my actual point a little more clearly:

1. Without typing available, some programs using type annotations
won't run. That is, using type annotations (a
test-time/development-time feature) introduces a runtime dependency on
typing, and hence introduces an extra deployment concern (unlike other
development-type features like test frameworks).
2. For some people, if something isn't in the Python standard library
(technically, in a standard install), it's not available (without
significant effort, or possibly not at all). For those people, a
runtime dependency on a non-stdlib typing module means "no use of type
annotations allowed".
3. Virtual environments typically only include the stdlib, and "use
system site-packages" has affects more than just a single module, so
bundling still has issues for virtualenvs - and in the packaging
tutorials, we're actively encouraging people to use virtualenvs. We
(python-dev) can work around this issue for venv by auto-installing
typing, but that still leaves virtualenv (which is critically short of
resources, and needs to support older versions of Python, so a major
change like bundling typing is going to be a struggle to get
implemented).

None of these problems are really addressed by simply saying "pip
install typing". That's not for psychological reasons, there are
genuine barriers to having that work. However, it's not at all clear
how many people are affected by these issues. My personal feeling is
that the group of people participating in open source development is
biased towards environments where it's not a problem, but that's more
gut feeling than hard facts. The place where barriers are
perceived/psychological is when we try to discuss workarounds or
solutions - because there's a lot of guesswork about what people's
environments are like, there's a tendency to assume scenarios that
support our preferred solution, rather than those that don't.

Personally, I like to think that my arguments are "giving a voice to
people in constrained corporate environments like mine, who are
under-represented in open source environments". But it's very easy for
a view like that to turn into "banging on about a minor problem as if
it were a crisis", and I'm probably guilty of doing that. Worse still,
that results in me getting frustrated and then over-reacting further -
which is where we came in.

So again, apologies. I misunderstood what you were saying, but more as
a result of my personal biases than because you weren't sufficiently
clear.

Paul