On Tue, Mar 1, 2016 at 5:46 PM, Steve Dower firstname.lastname@example.org wrote:
On 01Mar2016 0524, Paul Moore wrote:
On 1 March 2016 at 11:37, David Cournapeau email@example.com wrote:
I am not clear about 3., especially on what should be changed. I know that for 2.7, we need to change PC\getpathp.c for sys.path, but are there any other places where the registry is used by python itself ?
My understanding from the earlier discussion was that you should not patch Python at all. The sys.path building via PythonPath is not covered by the PEP and you should continue as at present. The new keys are all for informational purposes - your installer should write to them, and read them if looking for your installations. But the Python interpreter itself should not know or care about your new keys.
Steve can probably clarify better than I can, but that's how I recall it being intended to work. Paul
Yes, the intention was to not move sys.path building out of the PythonCore key. It's solely about discovery by external tools.
Right. For us, continuing populating sys.path from the registry "owned" by python.org official installers is more and more untenable, because every distribution writes there, and this is especially problematic when you have both 32 bits and 64 bits distributions in the same machine.
If you want to patch your own distribution to move the paths you are welcome to do that - there is only one string literal in getpathp.c that needs to be updated - but it's not a requirement and I deliberately avoided making a recommendation either way. (Though as discussed earlier in the thread, I'm very much in favour of deprecating and removing any use of the registry by the runtime itself in 3.6+, but still working out the implications of that.)
Great, I just wanted to make sure removing it ourselves do not put us in a corner or further away from where python itself is going.
Would it make sense to indicate in the PEP that doing so is allowed (neither recommended or frowned upon) ?