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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
