the origin of this feature disappearing for built-in types: http://bugs.jython.org/issue1058
''' object.__set/delattr__ allow modification of built in types, this is known as the Carlo Verre hack: Jython 2.3a0+ (trunk:4630:4631M, Jun 14 2008, 20:07:38) [Java HotSpot(TM) Client VM (Apple Inc.)] on java1.5.0_13 Type "help", "copyright", "credits" or "license" for more information. >>> object.__setattr__(str, 'lower', str.upper) >>> 'dammit Carlo!'.lower() 'DAMMIT CARLO!' ''' but I do not see any reason why having an explicit flag for python extensions written in C to declare their types as static struct, and still be able to change their __setattr__, __getattr__, etc. slots would not make sense. extensions and core types have not the same constraints and purposes, this should be reflected on the capabilities the first would have somewhere then. ________________________________ From: Eloi Gaudry Sent: Tuesday, June 26, 2018 4:27:18 PM To: python-ideas@python.org Subject: Re: [Python-ideas] Allow mutable builtin types (optionally) some literature: https://mail.python.org/pipermail/python-dev/2008-February/077180.html <https://mail.python.org/pipermail/python-dev/2008-February/077180.html>https://mail.python.org/pipermail/python-dev/2008-February/077169.html where it is stated that python C struct type should not be able to have their attributes changed. but the extension needs is clearly not taken into account. ________________________________ From: Python-ideas <python-ideas-bounces+eloi.gaudry=fft...@python.org> on behalf of Eloi Gaudry <eloi.gau...@fft.be> Sent: Thursday, June 21, 2018 5:26:37 PM To: python-ideas@python.org; encu...@gmail.com Subject: Re: [Python-ideas] Allow mutable builtin types (optionally) This request didn't have a lot of traction, but I still consider this is something that would need to be supported (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> on behalf of Eloi Gaudry <eloi.gau...@fft.be> Sent: Tuesday, May 8, 2018 9:26:47 AM To: encu...@gmail.com; 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 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/
