On Tue, Dec 3, 2019, at 12:22, Steve Dower wrote: > > * The number of constants in a code object. > > SGTM.
Two things... First, for this one in particular, the number of constants in a code object is hard to predict. For example, recently (I want to say 3.7), the number of constants generated for most code was reduced by removing duplicate constants and intermediate constants that are optimized away by constant-folding. Adding the "x in [list or set literal]" optimization introduces a tuple or frozenset constant (and removes the constants for the items) You also mentioned names - it's easy to imagine an implementation whose version of a code object shares names and constants in a single array with a single limit, or which has constants split up per type [and maybe doesn't implement tuple and frozenset constants at all] and shares names and string constants. Or one which does not store names at all for local variables in optimized code. I also don't think characteristics of cpython-specific structures like code objects should be where limits are defined. One of the purposes of specifying a formal limit is to give other implementations a clear target for minimum support. In C, there's a long list of limits like these [some of which are quite a bit smaller than what typical implementations support], but all of them are for characteristics that can actually be determined by looking at the source code for a program. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/67OFA4G6A2X3XRBLG6XR4PWLEYBJLNLV/ Code of Conduct: http://python.org/psf/codeofconduct/
