No, I’ve not measured (I’m not even sure I’ll use Python). But converting large file from base64 to bytes could impact the program initialization time. Also, base64 requires more characters.
Base64 is just one of the encodings you could use. It’s also possible to
write the literal bytes string directly using the repr() of the binary
string. You then don’t need any post-processing at runtime, but
gzip+base64 tends to be more space efficient 
1 Like
Makes sense, but only disadvantage is that the string literal has to be scanned (including its escape sequences), so it can be inefficient to compile the Python program. Another thing that worries me is how str will be converted to bytearray or memoryview, considering the Python engine (like V8) uses different string views.
Like any other non ECMAScript-language, the CPython interpreter cannot be natively run inside a browser directly; that relies on WASM support, cross-compilation via Emscripten or other external means, and each typically involves deploying Python code in a more tailored form than typically used with the desktop Pyton interpreter, and/or involving specific preprocessing (with the one arguable exception being something you state you dislike and presumably wouldn’t use). Therefore, these toolkits are cross-compilers would likely be in the best position to be able to offer the most deployment target appropriate means of embedding text or binary data appropriate for the use-cases they target, rather than it being a feature of the Python language or the CPython interpreter.
Furthermore, given the restrictions on the Python runtime in browsers and the aforementioned differences in deployment, bundling, preprocessing and compilation, it seems unlikely any upstream-impelemented mechanism would even work properly with such projects.
The same generally holds for things like standalone executable or other scenarios where this might matter; these specialized deployment mechanisms are in the best, and perhaps only position to be able to package binary resources in a form most suitable for their deployment formats and target, not the Python language itself.
To quote Donald Knuth, “Premature optimization is the root of all evil.” Given you may not even use Python at all, and there surely are many other important concerns driving your program design than a minor increase in initialization time, it seems a bit premature to propose a new core language feature to accommodate what appears to be a fairly narrow use case.
- Yes, I’m aware that Python does not run natively in browsers. The framework I quoted, PyScript, uses WebAssembly. However, that’s not what I’m talking about, what I’m talking is that form of embedding is well supported for octet-stream or plain-text in languages (that are compiled to bytecode (case of Rust for its internal code structure) or ZIP archive (case of ActionScript’s
.swc, even though ActionScript does have its ABC (AVM bytecode) format)) like Rust and ActionScript (while for .NET, they use a resources API combined with project configuration that is local to the class library or console app). - I’m interested in Python because Rust does not have OOP inheritance and I ran into several problems to get the equivalent. Being able to embed content directly like this is not a “premature” optimization.
Also note I mispelled PyScript by PythonScript (I meant PyScript). Anyway, that’s off-topic.