Hi Brett, Sorry about that, I did not mean to be rude. What I wanted to says is:
1. That I relied on such a feature 2. Other people on this mailing-list already asked something similar at several occasions 3. HEAPTYPE would not always be a solution 4. Then I thought this was something that would indeed need more discussion and might get acceptance if discussed once again. Eloi From: Brett Cannon <br...@python.org> Sent: Tuesday, June 26, 2018 8:53 PM To: Eloi Gaudry <eloi.gau...@fft.be> Cc: encu...@gmail.com; python-ideas@python.org Subject: Re: [Python-ideas] Allow mutable builtin types (optionally) On Thu, Jun 21, 2018, 12:27 Eloi Gaudry, <eloi.gau...@fft.be<mailto:eloi.gau...@fft.be>> wrote: This request didn't have a lot of traction, but I still consider this is something that would need to be supported Please be careful about using the word "need" as it comes off as demanding instead of as a suggestion. -Brett (2 lines of code to be changed; no regression so far with python 2 and python 3). My main points are: - HEAP_TYPE is not really used (as anyone being using it ?) - HEAP_TYPE serves other purposes - extension would benefit for allowing direct access to any of its type attributes Petr, what do you think ? Eloi ________________________________ From: Python-ideas <python-ideas-bounces+eloi.gaudry=fft...@python.org<mailto:fft...@python.org>> on behalf of Eloi Gaudry <eloi.gau...@fft.be<mailto:eloi.gau...@fft.be>> Sent: Tuesday, May 8, 2018 9:26:47 AM To: encu...@gmail.com<mailto:encu...@gmail.com>; python-ideas@python.org<mailto:python-ideas@python.org> Subject: Re: [Python-ideas] Allow mutable builtin types (optionally) On Mon, 2018-05-07 at 15:23 -0400, Petr Viktorin wrote: > On 05/07/18 11:37, Eloi Gaudry wrote: > > I mean, to my knowledge, there is no reason why a type should be > > allocated on the heap (https://docs.python.org/2/c-api/typeobj.html > > ) to > > be able to change its attributes at Python level. > > One reason is sub-interpreter support: you can have multiple > interpreters per process, and those shouldn't influence each other. > (see https://docs.python.org/3/c-api/init.html#sub-interpreter-suppor > t) > > With heap types, each sub-interpreter can have its own copy of the > type > object. But with builtins, changes done in one interpreter would be > visible in all the others. Yes, this could be a reason, but if you don't rely on such a feature neither implicitly nor explicitly ? I mean, our types are built-in and should be considered as immutable across interpreters. And we (as most users I guess) are only running one interpreter. In case several intepreters are used, it would make sense to have a non-heap type that would be seen as a singleton across all of them, no ? _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
