On Fri, 8 Sep 2017 07:49:46 -0700 Nick Coghlan <ncoghlan at gmail.com> wrote: > On 8 September 2017 at 03:04, Antoine Pitrou <solipsis at pitrou.net> wrote: > > On Thu, 7 Sep 2017 18:47:20 -0700 > > Nick Coghlan <ncoghlan at gmail.com> wrote: > >> However, I do wonder whether we could encode *all* the mode settings > >> into the magic number, such that we did something like reserving the > >> top 3 bits for format flags: > >> > >> * number & 0x1FFF -> the traditional magic number > >> * number & 0x8000 -> timestamp or hash? > >> * number & 0x4000 -> checked or not? > >> * number & 0x2000 -> reserved for future format changes > > > > I'd rather a single magic number and a separate bitfield that tells > > what the header encodes exactly. We don't *have* to fight for a tiny > > size reduction of pyc files. > > One of Benjamin's goals was for the existing timestamp-based pyc > format to remain completely unchanged, so we need some kind of marker > in the magic number to indicate whether the file is using the new > format or nor. I don't think that's a useful goal, as long as we bump the magic number. Note the header format was already changed in the past when we added a "size" field beside the "timestamp" field, to resolve collisions due to timestamp granularity. Regards Antoine.
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