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