[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Benjamin Peterson added the comment: Let's keep any discussion on the preëxisting issue for this. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> support reproducible Python builds ___ Python

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Filipe Laíns added the comment: Sorry for the spam, I am trying to figure out the best option here, which is hard to do by myself. IMO it would be reasonable to create set objects with elements in the order they appear in the code, instead of based on the hash. I am not really sure where is

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Filipe Laíns added the comment: Nevermind, AFAIK that depends on the hash seed, correct? So, the most viable option to me would be a sorting algorithm that could take type into account. Would that be an acceptable solution? -- ___ Python tracker

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Filipe Laíns added the comment: I just realized my fix is wrong because list.sort does not handle different types. Similarly to other reproducibility fixes, how does skipping the item randomization when SOURCE_DATE_EPOCH is set sound? -- ___

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Change by Filipe Laíns : -- nosy: +christian.heimes ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Change by Filipe Laíns : -- keywords: +patch pull_requests: +24143 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25411 ___ Python tracker ___

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

hon/marshal.c#L505 -- messages: 391104 nosy: FFY00, Mark.Shannon, benjamin.peterson, yselivanov priority: normal severity: normal status: open title: unreproducible bytecode: set order depends on random seed for compiled bytecode type: behavior ___ Pyth

[issue36466] Adding a way to strip annotations from compiled bytecode

cary added the comment: Thanks for the feedback! I wasn't aware that modules depended on this during runtime. Abandoning this :) -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue36466] Adding a way to strip annotations from compiled bytecode

Guido van Rossum added the comment: (I just found out that Cary is on vacation until 4/17.) -- ___ Python tracker ___ ___

[issue36466] Adding a way to strip annotations from compiled bytecode

Guido van Rossum added the comment: One way would be to compile only their own source to bytecode using this flag. But I agree it doesn't look very viable in general. I'll talk to Cary offline. -- ___ Python tracker

[issue36466] Adding a way to strip annotations from compiled bytecode

Raymond Hettinger added the comment: FYI, this partially breaks functools.singledispatch() and completely breaks both typing.NamedTuple() and dataclasses.dataclass(). A user may be able to avoid these in their own code, but I don't see how they can avoid it in third-party code. --

[issue36466] Adding a way to strip annotations from compiled bytecode

Guido van Rossum added the comment: @cary are you planning on updating with the suggested/requested improvements to the patch? If not, let us know and we'll see if someone else is interested in taking over. -- ___ Python tracker

[issue36466] Adding a way to strip annotations from compiled bytecode

Ivan Levkivskyi added the comment: +1 from me. There are two ways to enable this: * Add -OOO that would remove all three: asserts, docstrings, annotations * Add separate --O-asserts --O-docstrings --O-annotations (or similar) I think I like the second option more. @cary Please note that our

[issue36466] Adding a way to strip annotations from compiled bytecode

Raymond Hettinger added the comment: Here are some quick measurements on a single module¹ that uses typing. It shows about a 7% space savings between the baseline and patched versions: -rw-r--r-- 1 raymond staff 3490 Mar 31 15:07 kmeans.cpython-38.opt-2.pyc -rw-r--r-- 1 raymond staff

[issue36466] Adding a way to strip annotations from compiled bytecode

Raymond Hettinger added the comment: > So as long as we have a separate mechanism to disable this I'm not worried Having a separate mechanism is a good solution. -- ___ Python tracker

[issue36466] Adding a way to strip annotations from compiled bytecode

Guido van Rossum added the comment: There's a similar thing with docstrings though. Some code depend on docstrings (e.g. David Beazley's parser generator). help() of course also depends on it. And yet we have a way to disable it. (Same with asserts, plenty of code depends on them even

[issue36466] Adding a way to strip annotations from compiled bytecode

Raymond Hettinger added the comment: Also note that functools.singledispatch depends on type annotations being present.¹턒² ¹ https://docs.python.org/3/library/functools.html#functools.singledispatch ² https://forum.dabeaz.com/t/singledispatch-and-the-visitor-pattern/395 --

[issue36466] Adding a way to strip annotations from compiled bytecode

Raymond Hettinger added the comment: +1 for a command-line option decouples this from eliminating docstrings. The latter generally has no semantic effect, but the former might. Ideally, we don't want to break non-typing uses of annotations. One example below uses annotations for argument

[issue36466] Adding a way to strip annotations from compiled bytecode

Guido van Rossum added the comment: +1 from me. Looking for a better way to enable this from the command line. Our alternative would be to maintain a local patch, since this definitely helps us. On Sat, Mar 30, 2019 at 12:04 AM Raymond Hettinger wrote: > > Raymond Hettinger added the

[issue36466] Adding a way to strip annotations from compiled bytecode

Raymond Hettinger added the comment: -0 At first blush, this seems reasonable. Like removing docstrings, it would make the bytecode more compact. That said, annotations can be used for more things than typing (they predate typing and could be used for anything). It's unclear whether

[issue36466] Adding a way to strip annotations from compiled bytecode

Change by Ivan Levkivskyi : -- nosy: +gvanrossum, levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36466] Adding a way to strip annotations from compiled bytecode

New submission from cary : Similar to how `-OO` currently strips docstrings from compiled bytecode, it would be nice if there were a way to strip annotations as well to further compact the bytecode. Attached is my initial attempt. From some simple manual testing, Python with this patch

Re: Compiled bytecode

Rocco Moretti wrote: Peter Hansen wrote: The main script is generally not compiled, but all imported scripts are generally compiled automatically, the first time they are imported, and never again unless the source changes. Someone please correct me if I'm wrong, but I'm under the impression that

Compiled bytecode

This may be a dumb question, but are there any practical advantages of compiling a python application to *.pyo, or *.pyc? I haven't noticed any difference in the performance of text *.py or a bytecompiled file. -- http://mail.python.org/mailman/listinfo/python-list

Re: Compiled bytecode

Dnia 29 Dec 2004 23:57:14 GMT, LutherRevisited napisa(a): I haven't noticed any difference in the performance of text *.py or a bytecompiled file. Importing modules works faster. -- JZ ICQ:6712522 http://zabiello.com -- http://mail.python.org/mailman/listinfo/python-list

Re: Compiled bytecode

LutherRevisited wrote: This may be a dumb question, but are there any practical advantages of compiling a python application to *.pyo, or *.pyc? I haven't noticed any difference in the performance of text *.py or a bytecompiled file. For a large application, the startup cost may be noticable, as

Re: Compiled bytecode

LutherRevisited wrote: This may be a dumb question, but are there any practical advantages of compiling a python application to *.pyo, or *.pyc? I haven't noticed any difference in the performance of text *.py or a bytecompiled file. The main script is generally not compiled, but all imported