[Python-Dev] Remove typing from the stdlib (original) (raw)

Paul Moore p.f.moore at gmail.com
Mon Nov 6 04:35:10 EST 2017

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

More information about the Python-Dev mailing list