Hello, On Tue, 1 Dec 2020 11:43:07 +0000 Rob Cliffe wrote: []

...

...

Somehow "dire" doesn't strike me as the right word.... Maybe you were looking for "conceivably useful in niche cases."? Perhaps we can bargain on "really useful in many cases".

Can I echo Chris Angelico's question to Marco Sulla?  Are you advocating syntax (possibly including a keyword "const") that means     (a) "will not be rebound"     (b) "is immutable"     (c) both     (d) something else

I'm personally advocating for ability to mark variable bindings as not reboundable, i.e. the choice (a). This is clearly orthogonal feature to object immutability, the choice (b). These also should be separate, easily (well, without further restrictions) composable. A solution which welds both too firmly is apparently not flexible enough. And I don't mention variable value/object mutability, aka choice (b), in my posts at all because Python already has fairly advanced control of that. Almost each fundamental data structure in Python comes both in mutable and immutable counterparts, e.g.: mutable list - immutable tuple mutable set - immutable frozenset mutable object - (may come as surprise, but becomes obvious if you think about it) - immutable namedtuple If you want immutable dict you [know whom to thank for the lack of it - stroked thru] can use types.MappingProxyType, as was explained (it's all about PEP603). The last case with immutable dict also shows that proliferation of both mutable and immutable type counterparts doesn't scale. What we need is some generic types.roproxy (yes, all lower-case, to emphasize its fundementalness) which can be applied to any object, and will filter out __setitem__ and __setattr__ (and del counterparts, and custom list of mutator methods, you get an idea).

(and if you can spare the time, give a toy example or two explaining how they would behave).

I'm about to post my pseudo-PEP on the so-called "strict mode", which uses const'ness as one of its biggest constituents, it will have various examples. In the meantime, let's theorize what it might mean for sys.argv to get a "const" annotation? (It doesn't have to, just a figure of thought.) You would still be able to run .append() and .clear() on it. But you would be 100% sure that the type of value stored in sys.argv is a list, and only a list. (So for example, you could write an optimized JIT which would bypass any type checks and support for other possible types when accessing sys.argv, but inline operations which work directly on lists without extra checks).

Because I've read every post in this thread (though I haven't kept them) and I'm still not clear. If we're clear about what we're discussing, we can avoid talking past each other. Thanks Rob Cliffe

-- Best regards, Paul mailto:pmiscml@gmail.com