<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 12, 2016 at 2:51 PM, Pavol Lisy <span dir="ltr"><<a href="mailto:pavol.lisy@gmail.com" target="_blank">pavol.lisy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2016-05-12 20:49 GMT+02:00, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>>:<br>
<br>
> There are some subtleties, e.g. in the above example we would actually like<br>
> to know that the return type varies with the argument type:<br>
><br>
> joe = new_user(ProUser)  # Really, joe is a ProUser, not just a User<br>
><br>
> This can be done using a type variable, e.g.<br>
><br>
> U = TypeVar('U', bound=User)<br>
> def new_user(user_class: Type[U]) -> U: ...<br>
> joe = new_user(ProUser)<br>
<br>
</span>It is very probably I dont understand. Is U here same type (=ProUser)<br>
for parameter and for return?<br></blockquote><div><br></div><div>Their status is different though. The return type is inferred from the argument type but (usually) not the other way around.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Because in PEP484 is written:<br>
<br>
-> CT = TypeVar('CT', bound=Comparable)<br>
-><br>
->   def min(x: CT, y: CT) -> CT:<br>
->       if x < y:<br>
->           return x<br>
->       else:<br>
->          return y<br>
-><br>
->  min(1, 2) # ok, return type int<br>
->  min('x', 'y') # ok, return type str<br>
-><br>
->(Note that this is not ideal -- for example ``min('x', 1)`` is invalid<br>
->at runtime but a type checker would simply infer the return type<br>
->``Comparable``.  Unfortunately, addressing this would require<br>
->introducing a much more powerful and also much more complicated<br>
->vconcept, F-bounded polymorphism.  We may revisit this in the future.)<br>
<br>
which I understand that CT could be different type for x (=str) and y (=int).<br>
</blockquote></div><br></div><div class="gmail_extra">No, *in a given call* CT will be the same for all. The example with Comparable is that for `min('x', 1)` there is a solution where CT *is* actually the same for both arguments -- both 'x' and 1 are instances of Comparable. In that example this is not ideal.<br><br></div><div class="gmail_extra">But in the new_user(UserPro) example there's only one occurrence of U in the argument list, and that will be inferred as the return type.<br><br></div><div class="gmail_extra">An example more similar to the CT example with users would be something like<br><br></div><div class="gmail_extra">def pair_accounts(personal_user_class: Type[U], business_use_class: Type[U]) -> List[U]: ...<br><br></div><div class="gmail_extra">Here the return type of pair_accounts(ProUser, ProUser) would be inferred as List[ProUser], but the return type of pair_accounts(ProUser, TeamUser) would be inferred as List[User], since User is the common base class of ProUser and TeamUser.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>