This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients barry, brett.cannon, doko, ncoghlan, petr.viktorin
Date 2017-02-10.17:39:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1486748389.99.0.187233748276.issue29514@psf.upfronthosting.co.za>
In-reply-to
Content
We *do* ship the bytecode in the built RPMs - the issue is that Python maintenance releases shouldn't be triggering rebuilds of thousands of system components (cf http://fedora.portingdb.xyz/ ) and potentially breaking otherwise working end user applications.

As far as "What about bytecode generation bugs?" goes, then my answer would be to find a way to fix the bug for freshly generated bytecode, without forcing stale bytecode to be regenerated. That way folks that actually hit the original bug have a way of solving it (clear their bytecode cache), while we also don't forcibly break the world.

That is, the problem with the resolution of issue 27836 wasn't fixing the bytecode generation when using double-star unpacking twice in a single function call - it was forcing the regeneration of *all* bytecode just because *some* bytecode would be broken if it used a particular new language feature. It's the equivalent of deliberately breaking the ABI for all extension modules just because we found a header bug affecting one particular function signature.
History
Date User Action Args
2017-02-10 17:39:50ncoghlansetrecipients: + ncoghlan, barry, brett.cannon, doko, petr.viktorin
2017-02-10 17:39:49ncoghlansetmessageid: <1486748389.99.0.187233748276.issue29514@psf.upfronthosting.co.za>
2017-02-10 17:39:49ncoghlanlinkissue29514 messages
2017-02-10 17:39:49ncoghlancreate