On Thu, Sep 7, 2017, at 16:58, Gregory P. Smith wrote:
+1 on this PEP.
Thanks!
Questions:
Input from OS package distributors would be interesting. Would they use this? Which way would it impact their startup time (loading the .py file vs just statting it. does that even matter? source files are often eventually loaded for linecache use in tracebacks anyways)?
I an anticipate distributors will use the mode where the pyc is simply trusted and the source file isn't hashed. That would make the io overhead identical to today.
Would they benefit from a pyc that can contain _both_ timestamp+length, and the source_hash? if both were present, I assume that only one would be checked at startup. i'm not sure what would make the decision of what to check. one fails, check the other? i personally do not have a use for this case so i'd omit the complexity without a demonstrated need.
Yeah, it could act as a multi-tiered cache key. I agree with your conclusion to pass for now.
Something to also state in the PEP:
This is intentionally not a "secure" hash. Security is explicitly a non-goal.
Added a sentence.