On 31 May 2016 07:17, "Steven D'Aprano" 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.