I'm going to second Chris' comment about efficiency. The purposes of
this PEP (as I read it) are:
(1) Security (less chance of code intentionally or accidentally
exceeding low-level machine limits that allow a security exploit);
(2) Improved memory use;
(3) And such improved memory use will lead to faster code.
1 and 2 seem to be obviously true, but like Chris, I think its a bit
much to expect us to take 3 on faith until after the PEP is accepted:
> Reference Implementation
> ========================
>
> None, as yet. This will be implemented in CPython, once the PEP has
> been accepted.
I think the change you are asking for is akin to asking us to accept the
GILectomy on the promise that "trust me, it will speed up CPython, no
reference implementation is needed". It's a big thing to ask.
Most of us a Python programmers, not experts on the minutia of the
interaction between C code and CPU cache locality and prediction etc.
Speaking for myself, all I know is that it is *really hard* to predict
what will and won't be faster:
improving memory locality will speed things up
but doing more work on every access will slow things down
so I'd like to see something more than just an assertion that this will
speed things up.
Another question: how will this change effect CPython on less common
CPUs like Atom etc?
As for the other objections I've seen so far, I think they are specious.
(Sorry guys, I just think you are being knee-jerk naysayers. Convince me
I am wrong.)
Obviously none of them is going to apply to hand-written code. Despite
Rhodri's skepticism I don't think there is any really question of
hand-written code hitting the limits of a million constants or a million
local variables *per function*.
I just grepped the 3.8 stdlib for "class" and came up with fewer than
22000 instances of the word:
[steve@ando cpython]$ grep -r "class" Lib/ | wc -l
21522
That includes docstrings, comments, the word "subclass" etc, but let's
pretend that they're all actual classes. And let's round it up to 25000,
and assume that there's another 25000 classes built into the
interpreter, AND then *quadruple* that number to allow for third party
libraries, that comes to just 250,000 classes. So we could load the
entire stdlib and all our third-party libraries at once, and still be
able to write 750,000 classes in your own code before hitting the limit.
Paddy: if you are generating a script from a log file, and it hits the
million line boundary, it's easy to split it across multiple files. Your
objection
why limit a "quick hack"
has a simple answer: limiting that quick hack allows Python code to be
quicker, more memory efficient and safer. If the cost of this is that
you have to generate "quick hack" machine-generated Python scripts in
multiple million-lines each files instead of one ginormous file, then
that's a tradeoff well worth making.
Random832, I think the intention of this PEP is to specify limits for
*CPython* specifically, not other implementations. Mark, can you
clarify?
I don't understand why Steve Downer raises the issue of a million blank
lines or comments. Machine generated code surely doesn't need blank
lines. Blank lines could be stripped out; comments could be moved to
another file. I see no real difficulty here.
--
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/3X3WGIJYBWGLBY6DUUJMBXWUKVSCQQ4C/
Code of Conduct: http://python.org/psf/codeofconduct/
