Steve D'Aprano wrote:
> 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.
Ah, if that's case I'll withdraw the suggestion for allowing the limits to
be configurable through sys then. Thanks for the clarification.
I have some basic understanding of how C structs work, but I'll admit that
it's far from an area that I'm knowledgeable about. My feedback is mostly
based on experience as a user and involvement with stdlib development, not
as a C developer. I don't have a strong understanding of the implementation
details behind the limits.
Although if they're not (reasonably) configurable by most users, I would
consider that to further reinforce my previous statement that we should
have some form of concrete evidence; to prove that imposing the limits will
provide tangible benefits to the vast majority of Python users.
On Tue, Dec 10, 2019 at 4:45 AM Steven D'Aprano <st...@pearwood.info> wrote:
> 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/
>
_______________________________________________
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/V5T3GYC5UB4HICCSNHXXUKIZ4KV4YWQC/
Code of Conduct: http://python.org/psf/codeofconduct/
