[issue13645] import machinery vulnerable to timestamp collisions

Change by Ammar Askar : -- pull_requests: -19023 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue13645] import machinery vulnerable to timestamp collisions

Change by Ammar Askar : -- nosy: +ammar2 nosy_count: 8.0 -> 9.0 pull_requests: +19023 pull_request: https://github.com/python/cpython/pull/19651 ___ Python tracker ___

[issue13645] import machinery vulnerable to timestamp collisions

Antoine Pitrou added the comment: Now pushed in. Thanks for the reviews! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue13645] import machinery vulnerable to timestamp collisions

Roundup Robot added the comment: New changeset 87331661042b by Antoine Pitrou in branch 'default': Issue #13645: pyc files now contain the size of the corresponding source http://hg.python.org/cpython/rev/87331661042b -- ___ Python tracker

[issue13645] import machinery vulnerable to timestamp collisions

Antoine Pitrou added the comment: > One is possibly deprecating path_mtime() so people don't waste time > implementing it (we actually never need to remove it thanks to the > ABC; otherwise we need to make sure the docs strongly state to only > bother with path_stats()). Ok, I saw I also forgot

[issue13645] import machinery vulnerable to timestamp collisions

Brett Cannon added the comment: LGTM (although I didn't run the unit tests and focused mainly on the importlib._bootstrap and abc changes). Only two things I would change. One is possibly deprecating path_mtime() so people don't waste time implementing it (we actually never need to remove it

[issue13645] import machinery vulnerable to timestamp collisions

Antoine Pitrou added the comment: > Then a method that returns some object representing all of the needed info > on the source file is needed, but that does NOT blindly return the stat info Then it's simpler for the object to be a dict, and backwards compatibility is straightforward (by ignori

[issue13645] import machinery vulnerable to timestamp collisions

Brett Cannon added the comment: On Mon, Jan 9, 2012 at 18:05, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > I'm not suggesting two stat calls (in the general case); you would > > call one or the other depending on the magic number of the pyc file. > > The proposal is to st

[issue13645] import machinery vulnerable to timestamp collisions

Antoine Pitrou added the comment: > I'm not suggesting two stat calls (in the general case); you would > call one or the other depending on the magic number of the pyc file. The proposal is to store both mtime and size, actually, to make false positives less likely. -- ___

[issue13645] import machinery vulnerable to timestamp collisions

Brett Cannon added the comment: I'm not suggesting two stat calls (in the general case); you would call one or the other depending on the magic number of the pyc file. Anyway, it would probably be best to have some method that is expected to return a specific object which embodies all the des

[issue13645] import machinery vulnerable to timestamp collisions

Charles-François Natali added the comment: The patch looks good to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue13645] import machinery vulnerable to timestamp collisions

Antoine Pitrou added the comment: > You could add the requisite path_size() method to get the value, and > assume 0 means unsupported I thought: - calling two methods means two stat calls per file, this could be slightly inefficient - if future extensions of the import mechanism require yet mo

[issue13645] import machinery vulnerable to timestamp collisions

Brett Cannon added the comment: Why change importlib's API and instead add to it? You could add the requisite path_size() method to get the value, and assume 0 means unsupported (at least until some future version where a deprecation warning about not requiring file size comes about). But I d

[issue13645] import machinery vulnerable to timestamp collisions

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue13645] import machinery vulnerable to timestamp collisions

Antoine Pitrou added the comment: Here is a patch adding the source code size to the pyc header. The number of places where details of the pyc file format are hard coded is surprisingly high... Unfortunately, I had to modify importlib's public API (path_mtime -> path_stats). I find it unfortun