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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4