[Python-Dev] PEP 514: Python registration in the Windows registry

Paul Moore p.f.moore at gmail.com
Mon Jul 18 13:01:19 EDT 2016


On 18 July 2016 at 17:33, Steve Dower <steve.dower at python.org> wrote:
>> Some comments below.
>
> Awesome, thanks! Posted a pull request at
> https://github.com/python/peps/pull/59 for ease of diff reading, and some
> commentary below (with aggressive snipping).

Thanks - I'll do a proper review of that, but just wanted to make a
few comments here.

> virtualenv would be a great example to use. My thinking was that the Tag
> should be appropriate here (perhaps with the Company to disambiguate when
> necessary), and that is now explicit.
>
> Anaconda currently has "Anaconda_4.1.1_64-bit" as their tag, which would not
> be convenient, so an explicit suggestion here would help ensure this is
> useful.

Yeah, that's not a useful value for this use case. What I'm thinking
of is that currently a number of projects (for example, virtualenv,
tox, and a personal Powershell wrapper I have round virtualenv) do
this registry introspection exercise, purely to provide a "more
convenient" way of specifying a Python version than giving the full
path to the interpreter. Unix users have versioned executables, so -p
python3.5 works fine, but Windows users don't have that.

So my idea is "something as easy to remember as python3.5".

But having said this, we're talking about a theoretical extension to
existing functionality, that probably has marginal utility at best, so
I don't want to get hung up on details here.

> Snipped most of the details because I agree it's unsatisfying right now, but
> I disagree with enough of the counterproposal that it was getting to be
> messy commenting on each bit.

I take your points here. What I was trying to avoid (because I've
encountered it myself) is having to actually *run* the Python
interpreter to extract this information. Unix code does this freely,
because running subprocesses is so cheap there, but starting up a load
of processes on Windows is a non-trivial cost. But again, this is in
the area of "potential use cases" rather than "we need it now", so I'm
OK with deferring the question if you're uncertain.

OK, that's enough off-the-cuff responses. I'll find some time to
review your PR (probably tomorrow) and comment there.

Paul


More information about the Python-Dev mailing list