> I also would suggest for PEP 611 that any limits are discoverable (maybe in sys) so it can be used by other implementations like Jython.
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. On Mon, Dec 9, 2019 at 8:51 PM Jim Baker <jim.ba...@python.org> wrote: > I was thinking the same thing. We should distinguish limits with respect > to the codegen process, which seem reasonable, vs runtime. Classes and > coroutines are objects, and like objects in general, the program should > have the option of filling its heap with any arbitrary objects. (Whether > wise or not, this design is not for us to arbitrarily limit. For example, I > recall that Eve Online is/was running large numbers of stackless > coroutines, possibly well in excess of 1M.) > > For some comparison: > Note the JVM has it made easier to tune the use of the native heap for > class objects since Java 8, in part to relax earlier constraints around > "permgen" allocation - by default, class objects are automatically > allocated from the heap without limit (this is managed by "metaspace"). I > suppose if this was a tunable option, maybe it could be useful, but > probably not - Java's ClassLoader design is prone to leaking classes, as we > know from our work on Jython. There's nothing comparable to my knowledge > for why this would be the case for CPython class objects more than other > objects. > > I also would suggest for PEP 611 that any limits are discoverable (maybe > in sys) so it can be used by other implementations like Jython. There's no > direct correspondence between LOC and generated Python or Java bytecode, > but it could possibly still be helpful for some codegen systems. Jython is > limited to 2**15 bytes per method due to label offsets, although we do have > workarounds for certain scenarios, and could always compile, then run > Python bytecode for large methods. (Currently we use CPython to do that > workaround compilation, thanks!) > > Lastly, PEP 611 currently erroneously conjectures that "For example, > Jython might need to use a lower class limit of fifty or sixty thousand > becuase of JVM limits." > > - Jim > > > On Mon, Dec 9, 2019 at 9:55 AM Guido van Rossum <gu...@python.org> wrote: > >> I want to question two specific limits. >> >> (a) Limiting the number of classes, in order to potentially save space in >> object headers, sounds like a big C API change, and I think it's better to >> lift this idea out of PEP 611 and debate the and cons separately. >> >> (b) Why limit coroutines? It's just another Python object and has no >> operating resources associated with it. Perhaps your definition of >> coroutine is different, and you are thinking of OS threads? >> >> -- >> --Guido van Rossum (python.org/~guido) >> *Pronouns: he/him **(why is my pronoun here?)* >> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >> _______________________________________________ >> 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/CJO36YRFWCTEUUROJVXIQDMWGZBFAD5T/ >> 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/RQIVRB4YHNQZ2M7GCXRRCOZHZSOSNSZL/ > 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/S22M4XH6PY6VKH446FDWC4JT2PFEDHL2/ Code of Conduct: http://python.org/psf/codeofconduct/
