Sounds reasonable. It could be done by just reading the entire file contents after the shebang and re-writing them with the necessary offset all in RAM, truncating the file if necessary, without involving the zipfile module very much; the shebang could have some amount of padding by default; the file could just be re-compressed in memory depending on your appetite for complexity. On Mon, Feb 23, 2015 at 1:49 PM, Paul Moore
On 23 February 2015 at 18:40, Brett Cannon
wrote: Couldn't you just keep it in memory as bytes and then write directly over the file? I realize that's a bit wasteful memory-wise but it is possible. The docs could mention the memory cost is something to watch out for when doing an in-place replacement. Heck the code could even make it an io.BytesIO instance so the rest of the code doesn't have to care about this special case.
I did consider this option, and I still quite like it. In fact, originally I wrote the API to *only* be in-place, until I realised that wouldn't work for things bigger than memory (but who has a Python app that's bigger than RAM?)
I'm happy to modify the API along these lines (details to be thrashed out) if people think it's worthwhile. Paul