[Python-ideas] typing.modifiers

[אלעזר]

Thanks for the reply

בתאריך יום ו׳, 16 בספט' 2016, 13:16, מאת Steven D'Aprano ‏<
steve at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160916/2f25f621/attachment.html>