On Fri, Sep 16, 2016 at 12:10:22AM +0000, אלעזר wrote: [...] > Benefits of putting such a collection in stdlib (instead of as an external > package) include:
Slow down! Before getting all excited about adding these typing hints(?) into typing.modifiers, you first have to convince people that they are useful and deserve a place in the std library. What problem are these hints/classes supposed to solve? What solutions already exist? Why aren't those solutions good enough? > 1. This information can be used by typecheckers, and also by users, to > reason about programs. If isinstance(x, ImmutableArray), then x is an > instantiation of ImmutableArray. That's how type-checkers work. The class doesn't need to be in the std lib for a type-checker to reason about it. > 2. A conventional syntax and a single answer for "How do I make my class > immutable", "How do I make my class unsubclassable" Do we need syntax for those? > 3. The syntax, especially for Struct as above, is pretty and clean. The > Array syntax is less so. I don't even understand what the Array syntax is supposed to mean. > 4. I think that the array implementation can use internal CPython details > to be implemented efficiently. What happens to Jython, PyPy, IronPython etc? > I am not sure that typing.modifiers is the right place, since these are not > exactly type hints; they generate methods, and are intended to be enforced > at runtime. Then I think your answer is: no, typing.modifiers is NOT the right place. > I think that even if this idea is not accepted, the general theme is > something that might be useful to keep in mind, stdlib might accumulate > such modifiers, and it will be nice to keep things uniform. The stdlib might accumulate many things. Why should it accumulate these? -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/