On 19 November 2015 at 02:50, Ryan Gonzalez <rymg19 at gmail.com> wrote: > Well, not quite the same thing, but > https://github.com/kirbyfan64/pfbuild/blob/master/pfbuild embeds the > compressed version of 16k LOC. Would it be affected negatively in any way be > this? > > Since all the data is on one line, I'd think the old (current) parser would > end up reading in the whole line anyway. Right. The other main "embedded binary blob" case I'm familiar with is get-pip.py, which embeds a base85 encoded copy of pip as a zip archive in a DATA variable, and there aren't any appending tricks there either - it's a normal variable, and the "if __name__ == '__main__':" block is the final two lines of the file, so Python already has to read the whole thing before it starts the process of unpacking it and executing it. Two things worth keeping in mind here is that if a script is embedding enough data for reading the whole thing into memory it to pose a problem: * compiling and executing it is likely to pose an even bigger problem than reading it in * downloading it in the first place is also likely to be annoying We couldn't make a change like this in a maintenance release, but for a new feature release, the consistency gain is definitely worth it. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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