René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Surprising behaviour with compileall -s STRIPDIR parameter","articleBody":"The '-s' stripdir parameter to compileall has very unusual semantics that could lead to unexpected and potentially confusing outcomes.\r\n\r\nFor example, when run like this: `python -m compileall -s/path/to/build/dst -p /lib /path/to/build/src/file.py`\r\n\r\nThe source file path written to the compiled file will be: `/lib/src/file.py`. In other words the source file path is partially stripped even though the strip prefix doesn't fully match the source file path. Since this was introduced in #16012 I'd like to get @frenzymadness to comment if this was intentional, because it seems that it could be a source of really confusing bugs for end users who accidentally misspell something in their invocation and get a partially stripped result.\r\n\r\nIt gets weirder than that however, when run like this: `python -m compileall -s/path/to/another/src -p /lib /path/to/build/src/file.py`\r\n\r\nThe source file path written to the compiled file will be: `/lib/build/file.py`. The matching directories are removed around the non-matching ones. Even if there was some reason for the first behaviour it seems this second one is absolutely not a good idea.\r\n\r\nI'm happy to fix this once it is confirmed this behaviour is unintentional.\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-108671\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/hetmankp","@type":"Person","name":"hetmankp"},"datePublished":"2023-06-20T06:47:41.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":8},"url":"https://github.com/105931/cpython/issues/105931"}