Hello All, I've pushed a change to rework a bit the pep wording and add further details on its working. It needed indeed some extra work. PR still in flight: https://github.com/python/peps/pull/1941 I've also changed it to target 3.11. I believe most of your concerns should be answered in the PEP now, but I will answer them here as well.
Let me know if there is any additional question or any section you think can benefit from additional work. > Thank you for your submission of PEP 648 Thank you for reviewing and considering it :). > We would like to eventually go farther, including deprecation of pth files entirely, but that is outside the scope of this PEP. Agree on deprecating only code execution as Nick pointed out. This PEP includes that in the Backward compatibility a mention to adding a warning already to code execution in pth files. > The introduction of the section titled “Benefits of __sitecustomize__” seems out of place. Agree, I've restructured it to make things (IMHO) clearer. Happy to apply further changes if you think it is still confusing. > Some of the terminology used in the PEP could be clarified. Changes applied. > Another ambiguity is what the PEP means by “executing” said “scripts”. Read + exec. It used to be import but there seemed to be a general preference on read+exec on the discourse thread. (Info now included in the PEP). > The “Backward compatibility” section has this incomplete sentence Fixed > There’s this odd grammar in the “Do nothing” section Thanks for pointing it out, updated with your suggestion. Please let me know if you see anything else like that, I'm not an English native speaker. > Definition of “site path” Clarified in the PEP. I'm purposely leaving site-path definition to the `site` module rather than saying something too concrete. Hopefully the updates make it clearer now. > Order of Execution I've added a section for this. The work plans to piggyback on the discovery of `pth` files. > How do pth file sys.path extensions affect the search for __sitecustomize__ directories? They should not, I've added a section to the PEP to explain it. > Impact on startup time I've added a more detailed benchmark that can be reproduced. > How does this feature interact with virtual environments? Outstanding question, I've added a section for it. > Why not explicitly deprecate these +1. I was trying to be not too ambitious here. > Do you have any concerns that this feature will be overused? I could see some more people starting to use it, but I think it is a niche case. I expect system administrators and packaging tools (like venv) to use it (and with a better experience). > Will the runtime have any access to the list of __sitecustomize__ modules being executed? I.e. will you collect their paths in a new sys module attribute? Nope, the PEP explains how to find them programmatically though and for users we expect to add a CLI option to site to list them. > We think io.open_code() should be used so that reading the files can be audited. Sure thing! > We think io.open_code() should be used so that reading the files can be audited. I've added a section focused on security. Not sure if you were looking for anything further in terms of security analysis. Regards, Mario On Fri, 2 Apr 2021 at 17:22, Nick Coghlan <ncogh...@gmail.com> wrote: > On Wed, 31 Mar 2021 at 11:01, Barry Warsaw <ba...@python.org> wrote: > > > > Kind of :) > > > > PEP 648 would definitely allow us to deprecate the executable part of > pth files. I let my own biases leak in to my response because I would like > to find a way to replace the sys.path feature of pth with something much > more auditable and discoverable. To me that means deprecating pth files > and finding something better, but maybe not. > > Adding pth file auditing to the output of "python -m site" should be > entirely feasible, it just hasn't been done yet. > > Even if it just listed the files found, it would make them easier to > audit than they are today. > > Declaring the feature impossible to audit when we haven't even really > tried to make it auditable seems premature (the existing site output > doesn't even indicate which paths in sys.path will be considered when > looking for pth files, let alone indicate which of those directories > actually contain any). > > Cheers, > Nick. >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/775VQR46ESG435OYHCRRE4B4MGMCEPPT/ Code of Conduct: http://python.org/psf/codeofconduct/
