<div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>If he's interested, Donald Stufft would make a good choice for delegate.</div><div><br></div><div>Really do appreciate everyone's confidence.</div><div><br>Cheers,</div><div>Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 23, 2015 at 2:35 PM, Christian Heimes <span dir="ltr"><<a href="mailto:christian@python.org" target="_blank">christian@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-11-17 01:00, Guido van Rossum wrote:<br>
> Hm, making Christian the BDFL-delegate would mean two out of three<br>
> authors *and* the BDFL-delegate all working for Red Hat, which clearly<br>
> has a stake (and IIUC has already committed to this approach ahead of<br>
> PEP approval). SO then it would look like this is just rubber-stamping<br>
> Red Hat's internal decision process (if it's a process -- sounds more<br>
> like an accident :-).<br>
><br>
> So, Alex, do you want to approve this PEP?<br>
<br>
</span>I haven't read this thread until now. Independently from your objection<br>
I have raised the same concern with Nick today. I'd be willing to BDFL<br>
the PEP but I'd rather have somebody outside of Red Hat. Alex is a great<br>
choice.<br>
<br>
<br>
In the same mail I sent Nick a quick review of the latest PEP version in<br>
private.<br>
<br>
<br>
1) The example implementation of the function doesn't check the<br>
sys.flags.ignore_environment. Internally CPython has specialized getenv<br>
function that ignores env vars with PYTHON prefix when the flag is set.<br>
PYTHON* env vars aren't removed from os.environ. Modules have to check<br>
the flag.<br>
<br>
<br>
2) The PEP is rather Linux-centric. What's the recommended path to the<br>
config file on other platforms like BDS (/usr/local/etc/ is preferred<br>
for additional dependencies on FreeBSD), OSX and Windows?<br>
<br>
<br>
3) What's the interaction between the location of the config file and<br>
virtual envs? Would it make sense to search for the file in a venv's<br>
etc/ first and then dispatch to global /etc/? That way venvs can<br>
influence the setting, too.<br>
<br>
<br>
4) It makes sense to make the cert-verification.cfg file future-proof<br>
and reserve it for other cert-related configuration in the future. For<br>
example it could be used to define new contexts, set protocols, ciphers<br>
or hashes for cert pinning. It should be enough to say that CPython<br>
reserves the right to add more sections and keys later.<br>
<br>
<br>
5) I'm not particular fond of the section name [https]. For one It is<br>
ambiguous because it doesn't distinguish between server certs and client<br>
certs. It's also not correct. The default context is used for other<br>
protocols like imap, smtp etc. over TLS.<br>
<span class="HOEnZb"><font color="#888888"><br>
Christian<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>"The people's good is the highest law." -- Cicero<br><div>GPG Key fingerprint: 125F 5C67 DFE9 4084</div></div></div>
</div>