On Mon, Dec 09, 2019 at 11:27:56PM -0500, Kyle Stanley wrote:
> I agree, I think that sys would likely be the most reasonable place to read
> these limits from. Also, it seems like a good location for setting of the
> limits, if that becomes an option. This would go along well with the
> existing sys.getrecursionlimit() and sys.setrecursionlimit().
>
> In general, this proposal would be much easier to consider if the limits
> were customizable. I'm not sure if it would be reasonable for all of the
> options, but it would at least allow those who have a legitimate use case
> for going beyond the limits (either now or in the future) to still be able
> to do so.
Someone will correct me if I'm wrong, but my reading of the PEP tells me
that these are structural limits in the interpreter's internal data
structures, so they can't be configured at runtime.
The impression I get is that you believe that the proposal is to add a
bunch of runtime checks like this:
# pseudo-code for the module-loading code
lines = 0;
while 1
{
read and process line of code
lines += 1;
if lines >= 1000000:
GOTO error condition
}
In that case, it would be easy to change the 1000000 constant to a value
that can be configured at runtime. You wouldn't even need to quit the
running interpreter.
As I understand the PEP, the proposal is to change a bunch of C-level
structs which currently contain 32-bit fields into 20-bit fields. To
change that, you would need to recompile with new struct definitions and
build a new interpreter binary.
If I'm right, making this configurable at *build-time* could be
possible, but that's probably a bad idea. That's like the old "narrow
versus wide Unicode" builds. It doubles (at least!) the amount of effort
needed to maintain Python, for something which (if the PEP is correct)
benefits nearly nobody but costs nearly everyone.
--
Steven
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/Q2UOEO3VOLG762WJ5N7LMJGX6ULUE6JR/
Code of Conduct: http://python.org/psf/codeofconduct/