[Python-ideas] typing.modifiers

Steven D'Aprano steve at pearwood.info
Fri Sep 16 06:15:56 EDT 2016


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


More information about the Python-ideas mailing list