[Python-ideas] PEP 484 (Type Hints) -- first draft round

Guido van Rossum guido at python.org
Mon Jan 19 17:15:54 CET 2015

On Sun, Jan 18, 2015 at 10:06 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 1/18/2015 10:40 PM, Guido van Rossum wrote:
>> On Sun, Jan 18, 2015 at 12:36 PM, Stefan Behnel
>      does anyway. If it means "exactly list and no subtypes of list",
>>     Cython can
>>     use it to avoid generating generic fallback code.
>> Can you explain how this works? How does Cython manage to use the
>> knowledge that the argument's __class__ is equal to builtins.list to
>> generate more efficient code?
> The obvious part is that Cython will directly access the C array of
> pointers .. and *assume* that each pointer points to a member of the
> sequence, in order.  The less obvious part is how a subclass can break that
> assumption.
> Suppose, for instance, one wants a list of pairs, without the space
> overhead of a concrete tuple object for each pair.  Here is the beginning
> of a list subclass solution (not necessarily the best approach, but a
> possible one).
> class PairList(list):
>     def __getitem__(self, i):
>         g = super().__getitem__
>         return g(2*i), g(2*i+1)
> pl = PairList([1,2,3,4])
> print(pl[0], pl[1])
> >>>
> (1, 2) (3, 4)
> For Cython to execute this correctly, it would need the subclass fallback
> code that would go through the custom .__getitem__.
> Storing a triangular matrix in a list, with __getitem__ calculating the
> linear index from an input row, col pair, is another possible example.

But these are toy examples. For "real" code, you have to override a lot
more methods, and the usual implementation approach is not to subclass list
but to subclass collections.abc.MutableSequence. Then the problem goes
away, in some sense, because MutableSequence isn't compatible with
typing.List anyway.

> > Very few people subclass builtins.list ...
> > So perhaps Cython could just assume that typing.List means
> > builtins.list and (dynamically) reject calls that pass a subclass
> > of builtins.list?
> Identifying a triangular matrix as a List might not be too useful in any
> case.
> ...
> >    would be nice to at least be able to explicitly express somehow
> >    that subtypes should be disallowed.
> > Can you come up with a specific proposal? Maybe we're not as far
> > apart as we think. :-)
> Is the use of concrete types like list disallowed?

You mean as an argument type hint? It is allowed, but we're not mutating
the builtins.list to allow subscripting as a class, so you could only use
e.g. "def foo(a: list) -> list:", you couldn't use list[int]. And it would
still mean "allow subclasses".

> ---
> My memory of the pre-3.0 discussion is that we did not add something like
> typing then because we did not know how to write it.  You suggested
> (something like) "let people experiment and we can adopt and adapt the best
> result."  Now is the anticipated future.  I agree that mypy seems to be the
> best starting point of something both usable and useful that we are likely
> to get. It would be nice to have adapted version in an early alpha.  I
> presume you plan to label typing 'experimental', as I believe asyncio was.

Yes. (Actually, provisional is the term. But yes.)

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150119/1b91dac6/attachment.html>

More information about the Python-ideas mailing list