Hi all,

While I appreciate the vote of confidence from everyone, I'm not interested in being the BDFL-delegate for this. I don't think it's a good idea, and I'm not willing to put further time into.

If he's interested, Donald Stufft would make a good choice for delegate.

Really do appreciate everyone's confidence.

Cheers,
Alex

On Mon, Nov 23, 2015 at 2:35 PM, Christian Heimes <christian@python.org> wrote:
On 2015-11-17 01:00, Guido van Rossum wrote:
> Hm, making Christian the BDFL-delegate would mean two out of three
> authors *and* the BDFL-delegate all working for Red Hat, which clearly
> has a stake (and IIUC has already committed to this approach ahead of
> PEP approval). SO then it would look like this is just rubber-stamping
> Red Hat's internal decision process (if it's a process -- sounds more
> like an accident :-).
>
> So, Alex, do you want to approve this PEP?

I haven't read this thread until now. Independently from your objection
I have raised the same concern with Nick today. I'd be willing to BDFL
the PEP but I'd rather have somebody outside of Red Hat. Alex is a great
choice.


In the same mail I sent Nick a quick review of the latest PEP version in
private.


1) The example implementation of the function doesn't check the
sys.flags.ignore_environment. Internally CPython has specialized getenv
function that ignores env vars with PYTHON prefix when the flag is set.
PYTHON* env vars aren't removed from os.environ. Modules have to check
the flag.


2) The PEP is rather Linux-centric. What's the recommended path to the
config file on other platforms like BDS (/usr/local/etc/ is preferred
for additional dependencies on FreeBSD), OSX and Windows?


3) What's the interaction between the location of the config file and
virtual envs? Would it make sense to search for the file in a venv's
etc/ first and then dispatch to global /etc/? That way venvs can
influence the setting, too.


4) It makes sense to make the cert-verification.cfg file future-proof
and reserve it for other cert-related configuration in the future. For
example it could be used to define new contexts, set protocols, ciphers
or hashes for cert pinning. It should be enough to say that CPython
reserves the right to add more sections and keys later.


5) I'm not particular fond of the section name [https]. For one It is
ambiguous because it doesn't distinguish between server certs and client
certs. It's also not correct. The default context is used for other
protocols like imap, smtp etc. over TLS.

Christian



--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084