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 <christ...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
