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 -- 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/Q2UOEO3VOLG762WJ5N7LMJGX6ULUE6JR/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to