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 <p.f.moore at gmail.com> wrote: > On 23 February 2015 at 18:40, Brett Cannon <brett at python.org> 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
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