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