[issue35173] Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path according to the shared library

2019-10-04 Thread Ali Rizvi-Santiago
Ali Rizvi-Santiago added the comment: Sure. It was for Python2 anyways. -Ali On Wed, Sep 25, 2019 at 8:00 PM STINNER Victor wrote: > > STINNER Victor added the comment: > > Modules/getpath.c and PC/getpathp.c have been deeply reworked with the > implementation of the PEP 587 in Python

[issue35173] Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path according to the shared library

2019-09-25 Thread STINNER Victor
STINNER Victor added the comment: Modules/getpath.c and PC/getpathp.c have been deeply reworked with the implementation of the PEP 587 in Python 3.8. Parameters which are already set (ex: Py_SetProgramName() or using the new PyConfig API) are no longer overriden. I added some tests on the

[issue35173] Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path according to the shared library

2018-11-05 Thread Ali Rizvi-Santiago
Change by Ali Rizvi-Santiago : -- title: Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path -> Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path

[issue35173] Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path

2018-11-05 Thread Ali Rizvi-Santiago
New submission from Ali Rizvi-Santiago : This is specific to the Windows platform as it's the only platform that uses the registry and other path hacks to identify the default module path. This patch is mostly intended for embedded Python, but is also applicable to a stand-alone Python. A