Re: PythonPath / sys.path

On 5/15/2023 3:26 AM, Barry wrote: On 15 May 2023, at 05:39, Thomas Passin wrote: On 5/14/2023 11:08 PM, Chris Angelico wrote: On Mon, 15 May 2023 at 12:07, Thomas Passin wrote: Well, no, why would you assume that? I started to use Linux - in VMs - because I had to make sure that my

Re: PythonPath / sys.path

On Mon, 15 May 2023 at 14:38, Thomas Passin wrote: > > On 5/14/2023 11:08 PM, Chris Angelico wrote: > > On Mon, 15 May 2023 at 12:07, Thomas Passin wrote: > >> Well, no, why would you assume that? I started to use Linux - in VMs - > >> because I had to make sure that my cross-platform

Re: PythonPath / sys.path

> On 15 May 2023, at 05:39, Thomas Passin wrote: > > On 5/14/2023 11:08 PM, Chris Angelico wrote: >>> On Mon, 15 May 2023 at 12:07, Thomas Passin wrote: >>> Well, no, why would you assume that? I started to use Linux - in VMs - >>> because I had to make sure that my cross-platform

Re: PythonPath / sys.path

On 5/14/2023 11:08 PM, Chris Angelico wrote: On Mon, 15 May 2023 at 12:07, Thomas Passin wrote: Well, no, why would you assume that? I started to use Linux - in VMs - because I had to make sure that my cross-platform java/jython Tomcat program would work right on Linux. Why, for example,

Re: PythonPath / sys.path

On Mon, 15 May 2023 at 12:07, Thomas Passin wrote: > Well, no, why would you assume that? I started to use Linux - in VMs - > because I had to make sure that my cross-platform java/jython Tomcat > program would work right on Linux. Why, for example, would I think to > install Idle from the

Re: PythonPath / sys.path

On 5/14/2023 7:28 PM, Chris Angelico wrote: On Mon, 15 May 2023 at 09:22, Thomas Passin wrote: You made a little slam against Windows, but you will find it harder to get things working on Linux. Ubuntu, like many other Linux distros, does not come with pip and Tk (needed for Idle) installed,

Re: PythonPath / sys.path

On Mon, 15 May 2023 at 09:22, Thomas Passin wrote: > You made a little slam against Windows, but you will find it harder to > get things working on Linux. Ubuntu, like many other Linux distros, > does not come with pip and Tk (needed for Idle) installed, and it's not > so obvious how to install

Re: PythonPath / sys.path

On 5/14/2023 3:00 PM, Grizzy Adams via Python-list wrote: Sunday, May 14, 2023 at 11:11, Mats Wichmann wrote: Re: PythonPath / sys.path (at least in part) [snip] I have since moved up (a little) so only ~4 years old, I then updated pip from 9.x to 19.1 reason its an old version is it's

Re: PythonPath / sys.path

id not help, The default value of the above registry key is only used if Python can't calculate the default sys.path based on searching for "os.py", the landmark module in the standard library. This can happen sometimes when Python is embedded or run from a symlink. The default value of ea

Re: PythonPath / sys.path

On 5/14/23 13:00, Grizzy Adams via Python-list wrote: Sunday, May 14, 2023 at 11:11, Mats Wichmann wrote: Re: PythonPath / sys.path (at least in part) On 5/14/23 10:43, Barry wrote: I take it you have business reasons to use an obsolete version python. Where did you get your version

Re: PythonPath / sys.path

Sunday, May 14, 2023 at 11:11, Mats Wichmann wrote: Re: PythonPath / sys.path (at least in part) >On 5/14/23 10:43, Barry wrote: >> I take it you have business reasons to use an obsolete version python. >> Where did you get your version of python from? >In fact, a *nine

Re: PythonPath / sys.path

to do with the sys.path, though. -- https://mail.python.org/mailman/listinfo/python-list

Re: PythonPath / sys.path

> On 14 May 2023, at 16:32, Grizzy Adams via Python-list > wrote: > > Hi All > > My first post (repeated) > > I am having a problem with PythonPath / sys.path > > I have a dir where I keep all my current work, but I can't seem to add it to > Pyth

PythonPath / sys.path

Hi All My first post (repeated) I am having a problem with PythonPath / sys.path I have a dir where I keep all my current work, but I can't seem to add it to PythonPath / sys.path When I try to import one of my modules I see >>>import My_Working_File Traceback (most recent call last

Re: Incomplete sys.path with embeddable python (Windows)!?

Ralf M. ha scritto: Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list: How are you invoking your script? Presumably you have some code in your embedding application that takes a script path and runs it. Instead of putting the code to update sys.path into every script, the embedding

Re: Incomplete sys.path with embeddable python (Windows)!?

On 4/22/23 16:04, Ralf M. wrote: Am 21.04.2023 um 18:07 schrieb Thomas Passin: On 4/20/2023 5:47 PM, Ralf M. wrote: Hello, when I run a script with a "normally" installed python, the directory the script resides in is automatically added as first element to sys.path, so th

Re: Incomplete sys.path with embeddable python (Windows)!?

On 23/04/23 10:04 am, Ralf M. wrote: I thought about that, but for that to work all local modules across all script locations must have unique names, otherwise import might get hold of a module from the wrong directory. You could put all the local modules belonging to a particular script into

Re: Incomplete sys.path with embeddable python (Windows)!?

On 4/22/2023 5:45 PM, Ralf M. wrote: Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list: How are you invoking your script? Presumably you have some code in your embedding application that takes a script path and runs it. Instead of putting the code to update sys.path into every script

Re: Incomplete sys.path with embeddable python (Windows)!?

Am 21.04.2023 um 18:07 schrieb Thomas Passin: On 4/20/2023 5:47 PM, Ralf M. wrote: Hello, when I run a script with a "normally" installed python, the directory the script resides in is automatically added as first element to sys.path, so that "import my_local_module" find

Re: Incomplete sys.path with embeddable python (Windows)!?

Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list: How are you invoking your script? Presumably you have some code in your embedding application that takes a script path and runs it. Instead of putting the code to update sys.path into every script, the embedding application could do

Re: Incomplete sys.path with embeddable python (Windows)!?

Am 21.04.2023 um 17:31 schrieb Mats Wichmann: On 4/20/23 15:47, Ralf M. wrote: Hello, when I run a script with a "normally" installed python, the directory the script resides in is automatically added as first element to sys.path, so that "import my_local_module" find

Re: Incomplete sys.path with embeddable python (Windows)!?

How are you invoking your script? Presumably you have some code in your embedding application that takes a script path and runs it. Instead of putting the code to update sys.path into every script, the embedding application could do it before running the script. -- Greg -- https

Re: Incomplete sys.path with embeddable python (Windows)!?

On 4/20/2023 5:47 PM, Ralf M. wrote: Hello, when I run a script with a "normally" installed python, the directory the script resides in is automatically added as first element to sys.path, so that "import my_local_module" finds my_local_module.py in the directory of t

Re: Incomplete sys.path with embeddable python (Windows)!?

On 4/20/23 15:47, Ralf M. wrote: Hello, when I run a script with a "normally" installed python, the directory the script resides in is automatically added as first element to sys.path, so that "import my_local_module" finds my_local_module.py in the directory of the scrip

Incomplete sys.path with embeddable python (Windows)!?

Hello, when I run a script with a "normally" installed python, the directory the script resides in is automatically added as first element to sys.path, so that "import my_local_module" finds my_local_module.py in the directory of the script. However, when I

[issue229904] 2.1a1: lib-tk not in sys.path: import fails

Change by admin : -- github: None -> 33794 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue476326] Unicode in sys.path not supported

Change by admin : -- github: None -> 35426 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue403933] sys.path not set correctly when embedded

Change by admin : -- github: None -> 33986 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue459007] Document sys.path on Windows

Change by admin : -- github: None -> 35125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue433854] Wrong sys.path in weird situation

Change by admin : -- github: None -> 34639 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue422686] sys.path initialization in embedded Pyth

Change by admin : -- github: None -> 34483 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue404130] site.py sets sys.path incorrectly.

Change by admin : -- github: None -> 34001 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue231064] sys.path not set correctly in embedded python interpreter.

Change by admin : -- github: None -> 33847 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue224003] sys.path[0] is not the script directory

Change by admin : -- github: None -> 33528 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue224003] sys.path[0] is not the script directory

Change by admin : -- github: None -> 33528 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32642] add support for path-like objects in sys.path

Eryk Sun added the comment: > I've got in mind a PyListObject subclass with calls to PyOS_FSPath > before insert, append, extend and __getitem__. The sys module doesn't prevent rebinding sys.path. Most code I think is careful to update sys.path. But surely some code replaces it with

[issue32642] add support for path-like objects in sys.path

Lots of Python code out there manipulates sys.path or reads sys.path for various reasons and does not expect Path objects as list members, since only strings and bytes are allowed: https://docs.python.org/3/library/sys.html#sys.path Conversion to strings sounds like a good way to get the best out o

[issue32642] add support for path-like objects in sys.path

Noam Cohen added the comment: that's why pre-insert conversion was suggested. path-like objects could still be added to sys.path, while converting to str upon insert, preserving sys.path's bytes and strings only policy. -- ___ Python tracker

[issue32642] add support for path-like objects in sys.path

Serhiy Storchaka added the comment: pkgutil just skips non-string elements in sys.path. for dir in search_path: if not isinstance(dir, str): continue -- ___ Python tracker <https://bugs.python.org/issue32

[issue32642] add support for path-like objects in sys.path

ate any non-string elements in sys.path. As I shown above some code only works correctly with strings anyway. -- ___ Python tracker <https://bugs.python.org/issue32642> ___ ___

[issue32642] add support for path-like objects in sys.path

Noam Cohen added the comment: So I've got in mind a PyListObject subclass with calls to PyOS_FSPath before insert, append, extend and __getitem__. But I feel like this is an overkill; also, extend function might be trickier to implement. Do any of you have better idea? --

[issue32642] add support for path-like objects in sys.path

Nick Coghlan added the comment: The import system is already complex, so I think the hesitation about allowing arbitrary Path-like objects is warranted. (For example: are importlib's caching semantics really valid for *arbitrary* path-like objects? An object can be path-like without being

[issue32642] add support for path-like objects in sys.path

Noam Cohen added the comment: You've got a point. But in my opinion path-like object usage should be intuitive and users should not worry about converting it into string in some of the places. What do you feel about sub-classing list for sys.path and converting path-like objects upon

[issue32642] add support for path-like objects in sys.path

Serhiy Storchaka added the comment: Are there any problems with converting a Path to string before adding it to sys.path? You do this one time, and any users of sys.path will not need to bother about conversion. It is better even for performance. Otherwise we will need to revise and update

[issue32642] add support for path-like objects in sys.path

Change by Noam Cohen : -- nosy: +ncohen nosy_count: 8.0 -> 9.0 pull_requests: +30196 pull_request: https://github.com/python/cpython/pull/32118 ___ Python tracker ___

[issue31582] Add _pth breadcrumb to sys.path documentation

Steve Dower added the comment: New changeset c62b944dfc98911a5050389fa6ac753e283fee1f by Russel Webber in branch 'main': bpo-31582: Created a new documentation section describing sys.path initialization (GH-31082) https://github.com/python/cpython/commit

[issue47026] BytesWarning in zipimport paths on sys.path

Brett Cannon added the comment: bpo-47025 is a bigger discussion about bytes paths that probably needs to be resolved first before worrying about zipimport. -- ___ Python tracker

[issue47026] BytesWarning in zipimport paths on sys.path

Change by Brett Cannon : -- dependencies: +bytes do not work on sys.path ___ Python tracker <https://bugs.python.org/issue47026> ___ ___ Python-bugs-list mailin

[issue47026] BytesWarning in zipimport paths on sys.path

Andrei Kulakov added the comment: This warning can be fixed by changing the following line: https://github.com/python/cpython/blob/9d1c4d69dbc800ac344565119337fcf490cdc800/Lib/importlib/_bootstrap_external.py#L1419 to: if not path and str(path) == '': and running `make

[issue47025] bytes do not work on sys.path

Brett Cannon added the comment: I think it depends on whether we want to say the standard/included/built-in import mechanisms don't support byte paths, or byte paths are entirely not supported even for 3rd-party code? I definitely think we should at least do the former, but I'm hesitant to

[issue47025] bytes do not work on sys.path

Change by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47025] bytes do not work on sys.path

Thomas Grainger added the comment: > I'd advocate for not supporting bytes paths and instead updating the > documentation to require strings. I've got PR GH-31934 started to do this -- message_count: 8.0 -> 9.0 pull_requests: +30026 pull_request:

[issue47025] bytes do not work on sys.path

Jason R. Coombs added the comment: I'd advocate for not supporting bytes paths and instead updating the documentation to require strings. -- nosy: +jaraco ___ Python tracker

[issue47026] BytesWarning in zipimport paths on sys.path

New submission from Thomas Grainger : importing from a bytes zipimport path on sys.path results in a BytesWarning: Comparison between bytes and string running the reproducer with `python -b` shows: python -b zipfile_demo.py :1345: BytesWarning: Comparison between bytes and string see also

[issue47025] bytes do not work on sys.path

Thomas Grainger added the comment: zipimporter.zipimporter handles non-bytes paths here: https://github.com/python/cpython/blob/2cf7f865f099db11cc6903b334d9c376610313e8/Lib/zipimport.py#L65-L67 I think FileFinder should do the same -- ___ Python

[issue47025] bytes do not work on sys.path

Eryk Sun added the comment: > this is a regression from 3.2 In Windows, bytes paths in sys.path do not work in 3.2+. I didn't test 3.0 and 3.1, but practically one can say that bytes paths were never supported in Python 3 on Windows. -- nosy: +eryk

[issue47025] bytes do not work on sys.path

Thomas Grainger added the comment: interestingly bytes filenames pointing to zip files on sys.path do support bytes (see zipfile_demo.py) -- Added file: https://bugs.python.org/file50679/zipfile_demo.py ___ Python tracker <https://bugs.python.

[issue47025] bytes do not work on sys.path

Thomas Grainger added the comment: https://docs.python.org/3/reference/import.html#path-entry-finders says "The encoding of bytes entries is determined by the individual path entry finders." see https://github.com/python/cpython/commit/82c1c781c7ee6496bd4c404b7ba972eed5dbcb12 --

[issue47025] bytes do not work on sys.path

Thomas Grainger added the comment: this is a regression from 3.2: ``` Python 3.2.6 (default, Jan 18 2016, 19:21:14) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import tempfile >>> tempfile.TemporaryDirectory() >>> v = _ >>> tmp_dir =

[issue47025] bytes do not work on sys.path

Eric V. Smith added the comment: In case it helps anyone: On Windows 3.11.0a5+ the full traceback is: $ ./python.bat demo.py Running Debug|x64 interpreter... Traceback (most recent call last): File "...\demo.py", line 23, in sys.exit(main()) ^^ File

[issue47025] bytes do not work on sys.path

Change by Thomas Grainger : -- keywords: +patch pull_requests: +29993 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31897 ___ Python tracker ___

[issue47025] bytes do not work on sys.path

Change by Thomas Grainger : -- components: +Library (Lib) versions: +Python 3.10, Python 3.11, Python 3.9 ___ Python tracker ___

[issue47025] bytes do not work on sys.path

New submission from Thomas Grainger : importing a module with bytes in `sys.path` fails with: File "", line 182, in _path_isabs TypeError: startswith first arg must be bytes or a tuple of bytes, not str (see reproducer in attached demo.py) however `sys.path` is documented as

[issue32642] add support for path-like objects in sys.path

Change by Chih-Hsuan Yen : -- nosy: -yan12125 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32642] add support for path-like objects in sys.path

Jason R. Coombs added the comment: I'm in support of adding Path support for sys.path, but I also agree with Eric, there are innumerable consumers of sys.path beyond importlib. and since pathlib.Path isn't a str, it would likely introduce incompatibility. On the other hand, users

[issue13475] Add '--mainpath'/'--nomainpath' command line options to override sys.path[0] initialisation

STINNER Victor added the comment: See also bpo-16202 "sys.path[0] security issues". -- ___ Python tracker <https://bugs.python.org/issue13475> ___ ___

[issue13475] Add '--mainpath'/'--nomainpath' command line options to override sys.path[0] initialisation

STINNER Victor added the comment: The problem of long option names is that they cannot be used in a Unix shebang: "#!/usr/bin/python3 --long-option". I propose to add the -P option to not add sys.path[0]: I wrote GH-31542. -- ___ Pyth

[issue13475] Add '--mainpath'/'--nomainpath' command line options to override sys.path[0] initialisation

Change by STINNER Victor : -- pull_requests: +29665 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31542 ___ Python tracker ___

[issue13475] Add '--mainpath'/'--nomainpath' command line options to override sys.path[0] initialisation

STINNER Victor added the comment: See also "Python flag/envvar not to put current directory to sys.path (but don’t ignore PYTHONPATH)" discussion: https://discuss.python.org/t/python-flag-envvar-not-to-put-current-directory-to-sys-path-but-dont-ignore-pythonpath/4235/2 -

[issue46653] sys.path entries normalization in site.py doesn't follow POSIX symlink behaviour

New submission from Josselin Poiret : Whenever sys.prefix contains a symlink followed by a '..', the corresponding part of sys.path entries will not refer to the parent directory of the directory pointed to by the symlink, but rather to the directory in which the symlink is. Thus

[issue31582] Add _pth breadcrumb to sys.path documentation

Change by Russel Webber : -- keywords: +patch pull_requests: +29265 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31082 ___ Python tracker

[issue31582] Add _pth breadcrumb to sys.path documentation

Russel Webber added the comment: I agree wholeheartedly, an explantation of sys.path initialisation would be very helpful. I've seen too many hacks in end user Python code due to misunderstandings around sys.path initialisation and the available ways to customise sys.path. I'll work

[issue31582] Add _pth breadcrumb to sys.path documentation

sys.path. Without adding the new section, there isn't really anywhere sensible to mention it. -- ___ Python tracker <https://bugs.python.org/issue31582> ___ ___ Pytho

[issue31582] Add _pth breadcrumb to sys.path documentation

Russel Webber added the comment: I am happy to take a look at improving the documentation. I see the new getpath.py has very extensive commenting. Should I simply mention ._pth files as in the original issue from 5 years ago, or are you looking for documentation of how sys.path

[issue31582] Add _pth breadcrumb to sys.path documentation

Steve Dower added the comment: Need to make this happen, and it probably needs to be me (though I'm happy to review a contribution). We now handle ._pth files on all platforms as part of the Modules/getpath.py changes (which I hinted to in my previous comment from 5 years ago ;) ).

[issue32642] add support for path-like objects in sys.path

Éric Araujo added the comment: I’m not an import expert but would have misgivings about having fancy types in sys.path too! It seems so fundamental, and used from C and Python, with a simple interface of a direct list (plus importers and finders etc), that I would understand it pure strings

[issue13475] Add '--mainpath'/'--nomainpath' command line options to override sys.path[0] initialisation

Change by Neil Isaac : -- nosy: +nisaac ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21249] removing pythonXY.zip from sys.path results in additional test failures

Irit Katriel added the comment: This seems abandoned. Shall we close? -- nosy: +iritkatriel ___ Python tracker ___ ___

[issue17602] mingw: default sys.path calculations for windows platforms

Change by Irit Katriel : -- resolution: duplicate -> wont fix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7757] sys.path is incorrect when prefix is ""

Christian Heimes added the comment: This is a very old bug report. Python has changed a lot in the past decade. Please reopen the bug if you still can reproduce the issue with Python 3.9 or newer. -- nosy: +christian.heimes resolution: -> out of date stage: -> resolved status:

[issue17602] mingw: default sys.path calculations for windows platforms

Change by Irit Katriel : -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> MinGW is unsupported - close all open issues and list them here. ___ Python tracker

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

neonene added the comment: After this contribution, when using module at the root dir (maybe bad manners), the followings are expected behaviors? (1) relative drive in sys.path -> bytecode is not put in __pycache__ folder. >>> import sys >>> sys.path.append('F:')

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

Senthil Kumaran added the comment: There is a report about this change might have caused behaviour change for '.' in sys.path between 3.10.0a7 and 3.10.0b1 https://mail.python.org/archives/list/python-...@python.org/thread/DE3MDGB2JGOJ3X4NWEGJS26BK6PJUPKW/ -- nosy: +orsenthil

[issue44070] Regression with relative paths in sys.path in python 3.8.10

Andy Fiddaman added the comment: I've just found this while investigating a regression with my project following update to 3.9.5. It took me some time to discover that the new test failures were due to __file__ now being fully qualified when it wasn't before. As far as I can tell so far it

[issue44070] Regression with relative paths in sys.path in python 3.8.10

out the GitHub action I was using switched their Python 3.8 from 3.8.9 to 3.8.10 so I started looking into why this failed. My takeaway from this is to stop using relative imports in sys.path (I don't recall us having a specific reason to do this other than it worked). I figured I'd file an is

[issue44070] Regression with relative paths in sys.path in python 3.8.10

on sys.path) and delete from sys.modules. The new abspath is only applied to the full path to the module, so the cache is still for the module, and not for the sys.path entry. What's the actual scenario that this broke? -- ___ Python tracker <ht

[issue44070] Regression with relative paths in sys.path in python 3.8.10

Gregory P. Smith added the comment: without inspecting the code: I wonder if this is related to the same change as https://bugs.python.org/issue44061 ? -- nosy: +gregory.p.smith ___ Python tracker

[issue44070] Regression with relative paths in sys.path in python 3.8.10

Change by Gregory P. Smith : -- keywords: +3.10regression, 3.8regression, 3.9regression priority: normal -> high ___ Python tracker ___

[issue44070] Regression with relative paths in sys.path in python 3.8.10

Change by Gregory P. Smith : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44070] Regression with relative paths in sys.path in python 3.8.10

Change by Gregory P. Smith : -- nosy: +steve.dower ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44070] Regression with relative paths in sys.path in python 3.8.10

New submission from James Saryerwinnie : There was a change in behavior in Python 3.8.10 when using relative paths in sys.path. It appears that the paths are now converted to absolute paths that are cached and can cause import errors in some cases. Repro: $ cat repro.sh #!/bin/bash python

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

Gregory P. Smith added the comment: This caused a regression described in https://bugs.python.org/issue44061 -- nosy: +gregory.p.smith ___ Python tracker ___

[issue24247] Docs: "unittest discover" modifies sys.path

Change by Rahul Kumaresan : -- nosy: +rahul-kumi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24247] Docs: "unittest discover" modifies sys.path

Irit Katriel added the comment: This is alluded to in the "caution" under https://docs.python.org/3/library/unittest.html#test-discovery But the workaround is not explained. -- keywords: +easy nosy: +iritkatriel title: "unittest discover" modifies sys.pat

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

Change by Steve Dower : -- assignee: -> steve.dower resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

Steve Dower added the comment: New changeset eed7686e9fe22a3eb5e1a1fc7d27c27fca070bd1 by Steve Dower in branch '3.8': bpo-43105: Importlib now resolves relative paths when creating module spec objects from file locations (GH-25121)

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

Change by Steve Dower : -- pull_requests: +24053 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/25318 ___ Python tracker ___

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

Eryk Sun added the comment: > The 3.8 backport is much more complicated, as we don't have access to > the PathSkipRoot function there. So we can't use the native function. I guess you missed the comment that I left on the PR a few days ago. The 3.8 backport can use the older PathSkipRootW()

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

Steve Dower added the comment: The 3.8 backport is much more complicated, as we don't have access to the PathSkipRoot function there. So we can't use the native function. There's probably another way to implement the fix for 3.8, but I'm leaving that for another day. Feel free to chime in

[issue43105] [Windows] Can't import extension modules resolved via relative paths in sys.path

Steve Dower added the comment: Just needs the 3.8 backport - will get to that later tonight. -- stage: patch review -> backport needed ___ Python tracker ___

  1   2   3   4   5   6   7   8   9   10   >