[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: New changeset c1ee6e5e9b87c9812c6745c1dd6c1788a984f9f9 by Victor Stinner in branch 'master': bpo-20443: Update What's New In Python 3.9 (GH-17986) https://github.com/python/cpython/commit/c1ee6e5e9b87c9812c6745c1dd6c1788a984f9f9 --

[issue20443] __code__. co_filename should always be an absolute path

Change by STINNER Victor : -- pull_requests: +17390 pull_request: https://github.com/python/cpython/pull/17986 ___ Python tracker ___

[issue20443] __code__. co_filename should always be an absolute path

Nick Coghlan added the comment: With the sys.argv[0] change reverted, I think this overall issue is fixed now - code objects will get absolute paths, while sys.argv[0] will continue to reflect how __main__ was identified. -- priority: -> normal resolution: -> fixed stage: patch

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: I reverted my change, so I remove "release blocker" priority. -- priority: release blocker -> ___ Python tracker ___

[issue20443] __code__. co_filename should always be an absolute path

Batuhan added the comment: I am not sure that if co_filename can break backwards compability or not (because until CodeType.replace; it was usual to break code object construction, people who are using code objects may take this too) but yes PR 17534 was necessary. My initial patch (PR

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: New changeset a1a99b4bb7cbe2dbc55a1d92c3c509b4466d3c3b by Victor Stinner in branch 'master': bpo-20443: No longer make sys.argv[0] absolute for script (GH-17534) https://github.com/python/cpython/commit/a1a99b4bb7cbe2dbc55a1d92c3c509b4466d3c3b --

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: > Anything new here? 3.9.0a2 is due next week. I had it in my TODO list but I lost the bpo number. Thanks for the reminder :-) I wrote PR 17534 that I plan to merge as soon as the CI tests pass. -- ___ Python

[issue20443] __code__. co_filename should always be an absolute path

Change by STINNER Victor : -- pull_requests: +17012 pull_request: https://github.com/python/cpython/pull/17534 ___ Python tracker ___

[issue20443] __code__. co_filename should always be an absolute path

Łukasz Langa added the comment: Anything new here? 3.9.0a2 is due next week. -- nosy: +lukasz.langa ___ Python tracker ___ ___

[issue20443] __code__. co_filename should always be an absolute path

Change by Yury Selivanov : -- nosy: -yselivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue20443] __code__. co_filename should always be an absolute path

Gregory P. Smith added the comment: (read that as: feel free to keep the behavior for co_filename and path[0] and lets see what happens :) -- ___ Python tracker ___

[issue20443] __code__. co_filename should always be an absolute path

Gregory P. Smith added the comment: I think sys.argv[0] is the important one as program logic often tends to use that as an input. I'm honestly unsure of if this will be as much of a problem for .co_filename or sys.path[0]. -- ___ Python tracker

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: > To help address the original report filing issue, we could add a notion of > .co_cwd to code objects for use in resolving co_filename. Allow it to be '' > if getcwd failed at source load time. Code could check if co_cwd exists and > join it with the

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: > Please revert. Ok ok, I will revert my change, but only on sys.argv[0]. > A getcwd() call doesn't even have to succeed. A single file python program > should still be able to run in that environment rather than fail to start. The current implementation

[issue20443] __code__. co_filename should always be an absolute path

Gregory P. Smith added the comment: Please revert. An absolute path changes semantics in many real world situations (altering symlink traversals, etc). People expect the current sys.argv[0] behavior which is "similar to C argv" and matches what was passed on the interpreter command line.

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: > This change isn't in Python 3.8 though, it's only in Python 3.9 (the PR merge > date is after the beta 1 branch date). Oh, you're right. Sorry, I thought that I made the change before 3.8 branch was created. In that case, we can do whatever we want :-)

[issue20443] __code__. co_filename should always be an absolute path

Nick Coghlan added the comment: This change isn't in Python 3.8 though, it's only in Python 3.9 (the PR merge date is after the beta 1 branch date). Unless it was backported in a Python 3.8 PR that didn't link back to this issue or the original Python 3.9 PR? --

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: Michel Desmoulin: "The relevance of the use case isn't the problem. Even if people had been using it wrong for all this time, the update is still going to break their code if they did use it this way. And if it was possible, of course many people did." You

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: I understand that the discussion is about my commit 3939c321c90283b49eddde762656e4b1940e7150 which changed multiple things: --- Python now gets the absolute path of the script filename specified on the command line (ex: ``python3 script.py``): the

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: Nick Coghlan: > I think that's a valid point regarding sys.argv[0] - it's the import system > and code introspection that wants(/needs) absolute paths, whereas sys.argv[0] > gets used in situations (e.g. usage messages) where we should retain whatever > the

[issue20443] __code__. co_filename should always be an absolute path

Ammar Askar added the comment: I did a quick search to see what code would break from sys.argv[0] going relative intext:"sys.argv[0]" ext:py site:github.com https://www.google.com/search?q=intext:"sys.argv%5B0%5D"+ext:py+site:github.com and while most uses of it are to print usage

[issue20443] __code__. co_filename should always be an absolute path

Michel Desmoulin added the comment: The relevance of the use case isn't the problem. Even if people had been using it wrong for all this time, the update is still going to break their code if they did use it this way. And if it was possible, of course many people did. 3.7 already broke a few

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: What is the use case for having a relative sys.argv[0]? > Isn't that change breaking compat ? Right. It has been made on purpose. The rationale can be found in the first message of this issue. -- ___ Python

[issue20443] __code__. co_filename should always be an absolute path

Nick Coghlan added the comment: I think that's a valid point regarding sys.argv[0] - it's the import system and code introspection that wants(/needs) absolute paths, whereas sys.argv[0] gets used in situations (e.g. usage messages) where we should retain whatever the OS gave us, since that

[issue20443] __code__. co_filename should always be an absolute path

Michel Desmoulin added the comment: Isn't that change breaking compat ? I'm assuming many scripts in the wild sys.argv[0] and play with it assuming it's relative. I would expect such a change to be behind a flag or a __future__ import. -- nosy: +Michel Desmoulin

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: New changeset 3029035ef34c9bae0c8d965290cd9b273c8de1ea by Victor Stinner in branch 'master': bpo-20443: Fix calculate_program_full_path() warning (GH-14446) https://github.com/python/cpython/commit/3029035ef34c9bae0c8d965290cd9b273c8de1ea --

[issue20443] __code__. co_filename should always be an absolute path

Change by STINNER Victor : -- pull_requests: +14262 pull_request: https://github.com/python/cpython/pull/14446 ___ Python tracker ___

[issue20443] __code__. co_filename should always be an absolute path

Karthikeyan Singaravelan added the comment: This change seems to produce a new warning on my Mac. ./Modules/getpath.c:764:23: warning: incompatible pointer types passing 'char [1025]' to parameter of type 'const wchar_t *' (aka 'const int *') [-Wincompatible-pointer-types]

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: Example of case where a module path is still relative: --- import sys import os modname = 'relpath' filename = modname + '.py' sys.path.insert(0, os.curdir) with open(filename, "w") as fp: print("import sys", file=fp) print("mod =

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: New changeset 3939c321c90283b49eddde762656e4b1940e7150 by Victor Stinner in branch 'master': bpo-20443: _PyConfig_Read() gets the absolute path of run_filename (GH-14053) https://github.com/python/cpython/commit/3939c321c90283b49eddde762656e4b1940e7150

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: Effect of my PR 14053 using script.py: import sys print(f"{__file__=}") print(f"{sys.argv=}") print(f"{sys.path[0]=}") Before: $ ./python script.py __file__=script.py sys.argv=['script.py'] sys.path[0]=/home/vstinner/prog/python/master With the change: $

[issue20443] __code__. co_filename should always be an absolute path

Nick Coghlan added the comment: Perhaps `os._abspath_for_import`? If importlib finds it, then it can handle making early paths absolute itself, otherwise it will defer doing that until it has the full external import system bootstrapped. (importlib does try to make all paths absolute as it

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: The site module tries to compute the absolute path of __file__ and __cached__ attributes of all modules in sys.modules: def abs_paths(): """Set all module __file__ and __cached__ attributes to an absolute path""" for m in set(sys.modules.values()):

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: One of the side effect of my PR 14053 is that tracebacks are more verbose: the filename is now absolute rather than relative. Currently: $ python3 x.py Traceback (most recent call last): File "x.py", line 4, in func() File "x.py", line 2, in func

[issue20443] __code__. co_filename should always be an absolute path

STINNER Victor added the comment: PR 14053 is a different approach than PR 13527: compute the absolute path to the script filename in PyConfig_Read() just after parsing the command line. -- nosy: +vstinner ___ Python tracker

[issue20443] __code__. co_filename should always be an absolute path

Change by STINNER Victor : -- pull_requests: +13915 pull_request: https://github.com/python/cpython/pull/14053 ___ Python tracker ___

[issue20443] __code__. co_filename should always be an absolute path

Change by Batuhan : -- keywords: +patch pull_requests: +13441 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue20443] __code__. co_filename should always be an absolute path

New submission from Yury Selivanov: There are many issues on tracker related to the relative paths in co_filename. Most of them are about introspection functions in inspect module--which are usually broken after 'os.chdir'. Test case: create a file t.py: def foo(): pass

[issue20443] __code__. co_filename should always be an absolute path

Changes by Yury Selivanov yselivanov...@gmail.com: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20443 ___ ___ Python-bugs-list