[Python-ideas] Allow mutable builtin types (optionally)

[Guido van Rossum]

Hey Eloi,

I think you need to just give up on this. Nobody here seems to support or
understand your use case. At this point you are repeating yourself (again
claiming there is no good reason for the prohibition and that it's only a
few lines of code to change) and you can be assured that the response will
also be the same.

--Guido

On Tue, Jun 26, 2018 at 8:00 AM Eloi Gaudry <Eloi.Gaudry at fft.be> wrote:

> 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 at 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.be at python.org>
> on behalf of Eloi Gaudry <Eloi.Gaudry at fft.be>
> *Sent:* Thursday, June 21, 2018 5:26:37 PM
> *To:* python-ideas at python.org; encukou at 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.be at python.org>
> on behalf of Eloi Gaudry <Eloi.Gaudry at fft.be>
> *Sent:* Tuesday, May 8, 2018 9:26:47 AM
> *To:* encukou at gmail.com; python-ideas at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180626/e0c33e36/attachment.html>