On Sat, 7 Dec 2019 at 02:42, Michael <aixto...@felt.demon.nl> wrote: > A program has exactly - zero (0) of something, one (1) of something, or > infinite. The moment it gets set to X, the case for X+1 appears. > > Since we are not talking about zero, or one - I guess my comment is make > sure it can be used to infinity.
I suspect the professor saying this hadn't worked on any industrial systems were it was critically important to degrade gracefully under load, or done much in the way of user experience design (which is often as much about managing the way things fail to help guide users back towards the successful path as it is about managing how the system behaves when things go well). One of the first systems I ever designed involved allocating small modular audio processing components across a few dozen different digital signal processors. I designed that system so that the only limits on each DSP was the total amount of available memory, and the number of audio inputs and outputs. Unfortunately, this turned out to be a mistake, as it made it next to impossible to design a smart scheduling engine, since we didn't have enough metadata about how much memory each component would need, nor enough live information about how much memory fragmentation each DSP was experiencing. So the management server resorted to a lot of "just try it and see if it works" logic, which made the worst case behaviour of the system when under significant load incredibly hard to predict. CPython's own recursion limit is a similar case - there's an absolute limit imposed by the C stack, where if we go over it, we'll get an unrecoverable failure (a segfault/memory access violation). So instead of doing that, we impose our own arbitrarily lower limit where we throw a *recoverable* error, before we hit the unrecoverable one. So I'm broadly in favour of the general principle of the PEP. However, I also agree with the folks suggesting that the "10e6 for all the limits" approach may be *too* simplified. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/5CH4X3SDCTZ7KMOE5G4IJSI3O2U2STBF/ Code of Conduct: http://python.org/psf/codeofconduct/
