[Python-ideas] Declaring immutability (was Re: Proposal to change List Sequence Repetition (*) so it is not useless for Mutable Objects)

[Nick Coghlan]

On 31 May 2016 07:17, "Steven D'Aprano" <steve at pearwood.info> wrote:
>
> On Tue, May 31, 2016 at 01:36:31PM +0000, Joseph Martinot-Lagarde wrote:
> > > I can only agree here. Even today, despite knowing the fact, it's
> > > causing some headaches in some cases.
> >
> > How about raising an exception if mutable objects are in the list ?
>
> -1
>
> It's a gratuitous breakage that cannot solve the problem, because you
> cannot tell in advance which objects are mutable and which are not.

Steven raised the iterator windowing example I was going to point to as the
canonical use case that means the current behaviour won't change.

However, if folks want a somewhat-related genuinely interesting language
design problem to chew on: try to come up with a way a way to formally
define-and-enforce instance immutability in Python. As a pragmatic matter,
you'll probably still need to allow mutation at least until __new__
finishes running, and some use cases, like weak referencing and some
caching techniques, involve storing mutable state on semantically immutable
instances, so this is likely to be better approached as a type hinting
problem rather than as a runtime feature.

The closest related concept I'm personally familiar with is const pointers
and references in C and C++, so there may be some insights to be gained
there (e.g. being able to declare __new__ as returning "->
typing.Immutable" or "-> typing.Mutable", and being able to explicitly
annotate function parameters as either Immutable parameters, which
definitely won't be modified, and Mutable parameters, which definitely will
be modified. Pure and impure methods could then use those annotations on
their "self" parameter to indicate whether or not they had side effects)

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160601/a6102dfb/attachment.html>