> Don't know about Macs (although I believe the Metrowerks libc can be still > be *configured* to swap \r and \n there), but it caught a bug in Python in > the 2.0 release cycle (where Python was opening .pyc files in text mode by > mistake, but only on Windows). Well, actually, it didn't catch anything, it > caused import from .pyc to fail silently. Having *some* specific gross > thing fail every time is worth something. Sounds to me that we'd caught this sooner without the \r\n gimmic. :-) > But the \r\n thingie can be pushed into the extended header instead. Here's > an idea for "the new" magic number, assuming it must remain 4 bytes: > > byte 0: \217 will never change > byte 1: 'P' will never change > byte 2: high-order byte of version number > byte 3: low-order byte of version number > > "Version number" is an unsigned 16-bit int, starting at 0 and incremented by > 1 from time to time. 64K changes may even be enough to get us to Python > 3000 <wink>. A separate text file should record the history of version > number changes, associating each with the date, release and reason for > change (the CVS log for import.c used to be good about recording the reason, > but not anymore). > > Then we can keep a 4-byte magic number, Eric can have his invariant two-byte > tag at the start, and it's still possible to compare "version numbers" > easily for more than just equality (read the magic number as a "network > standard" unsigned int, and it's a total ordering with earlier versions > comparing less than later ones). The other nifty PNG sanity-checking tricks > can also move into the extended header. +1 from me. I'm +0 on adding more magic to the marshalled code. --Guido van Rossum (home page: http://www.python.org/~guido/)
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