Mark wrote, in reply to me:
On 09/12/2019 3:01 pm, Paddy McCarthy wrote:
> "Bear in mind that the costs of higher limits are paid by everyone, but
> the benefits are gained by few."
>
> Is there some evidence for the above statement? One of the issues with C
> programming is the need for limits Its hard to choose the right limits
> leading to so many failures. You propose limiting Python for performance
> gains but loose in ease of use and security.

How does this make anything less secure?
Many basic exploits have components taking advantage of limits known as buffer overflows

Suppose we can improve the interpreter in such a way that it takes
advantage of the one million bytecode per code object and speeds it up
by 0.1% (I can do a *lot* better than that).
What would the performance gain save globally? $100k, $1M p.a.?
What does it cost? A few developer hours.

You are looking to unproven execution gains. Adding an arbitrary limit might make it 0.1% faster to get the wrong result .
Optimisation isn't just speedThe less mind-clutter spent on such micro optimisations might leave one able to think of a better algorithm
or a better data structure that could give thousands of % speedups.
You should only quote C or C++ compiler limitations as a warning of what not to do. Python wins by being different; by being more
orthoganal; by having less arbitrary restrictions.

Case in point: http://paddy3118.blogspot.com/2019/11/quasi-random-sobol-sequence.html Itook decade old C++ library, converted it
to straight python, Python allowed me to see the opportunity for improvement leading to a Python version that is half the speed of
the C++ code and generates points on demand. That's how Python wins big time. Having to worry about stifling limits is the wrong
direction for the language to take.

On Mon, 9 Dec 2019 at 21:26, David Mertz <mertz@gnosis.cx> wrote:
I think a much more sensible approach than mandating a limit because "who knows, it might speed something up" would be finding the speedup first.

Probably that means one limit at a time too. E.g. maybe some patch imposes the 1 million LOC limit and demonstrates a repeatable benchmark improvement because of some coffee change that allows. That cold be interesting.

Even them, I wouldn't want some arbitrary round number just for its own sake. For example, if taking 10 bits away from a word that holds a LOC index speeds something up, make the LOC limit 4,194,304 (2**22)... Maybe. If you only need 9 bits for that use, make the limit twice as much.

On Mon, Dec 9, 2019, 12:53 PM Mark Shannon <mark@hotpy.org> wrote:

On 09/12/2019 2:15 pm, Chris Angelico wrote:
> On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon <mark@hotpy.org> wrote:
>> Bear in mind that the costs of higher limits are paid by everyone, but
>> the benefits are gained by few.
>
> Can we get some stats on what the costs of higher limits (or having no
> limit at all) is? Or, putting it the other way: Since CPython
> currently does not enforce limits, what are the benefits of placing
> those limits? Merely having a limit doesn't in itself give a benefit
> (and is a (minor) cost); it would help the discussion if we knew
> exactly WHAT the costs of the higher limits were.

Given there is an infinite number of potential optimizations that it
would enable, it is a bit hard to put a number on it :)

It is also impossible to put precise numbers on the speedups of a
particular optimizations unless it is implemented. I suspect no one is
going to do that unless paid to do so, or are guaranteed that the work
won't be thrown away because the PEP is rejected.

Cheers,
Mark.

>
> ChrisA
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/4IKBEMNGC5DZXOAR555ZUGNJGWSFV3QI/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/BWTOEHKYZ3NES4XPZA7QA57UHTVGRMQZ/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/MAOXN66JYZAN4L4ER6SH43TP3YMKHCVY/
Code of Conduct: http://python.org/psf/codeofconduct/