Thanks for the reply בתאריך יום ו׳, 16 בספט' 2016, 13:16, מאת Steven D'Aprano < st...@pearwood.info>:
> 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. > I was thinking this is the place to do this? What problem are these hints/classes supposed to solve? What solutions > already exist? Why aren't those solutions good enough? > I have addressed that only very briefly; I will try to elaborate later (I'm writing from the phone. Sorry) > > > 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. > No, it's not how they work, since it's not true. I meant the actual type, not a subtype. > > > > 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. > That's already a bad sign... Each underscore gives type to its index. The last index is the maximal. > > > 4. I think that the array implementation can use internal CPython details > > to be implemented efficiently. > > What happens to Jython, PyPy, IronPython etc? > Similarly or even more so. > > 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. > Speculating it will make its way, where should it land then? > > > 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? > In this part I wasn't talking about what should happen, but rather what might happen gradually, in which case it'll be nice to fit in a uniform structure. > > > -- > 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/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
