re: comprehension Perhaps PEP can, at least, have a short list/summary of limitations? I recall something was mentioned, but I can't find a section like that in PEP.
re: example following https://github.com/JukkaL/mypy/blob/master/stubs/3.2/socket.py # socket.pyi python2 class _socketobject: family = 0 # inferred from initializer (?) type = 0 # type: int # explicit # socket.pyi python3 class socket: family = AddressFamily.AF_UNSPEC # inferred I presume? def settimeout(timeout: Union[int, float, None]) -> None: pass # negative arguments illegal timeout = -1.0 # yet, that's what you get by default (set None) Perhaps, after all, socket module is a bad example. I suppose you have a point that well-written modules are self-documenting anyway... Here's another try: # _sqlite3.pyi python2 version # warning, readonly: module allows reassignment, but you really shouldn't! # instead use sqlite3.register_xxx functions converters = {} # type: Dict[str, Callable[[str], Any]] adapters = {} # type: Dict[Tuple[Type, SomethingInternal], Callable[[Any], str]] On 7 May 2015 at 17:39, Guido van Rossum <gu...@python.org> wrote: > On Thu, May 7, 2015 at 7:25 AM, Dima Tisnek <dim...@gmail.com> wrote: >> >> On 30 April 2015 at 14:33, Steven D'Aprano <st...@pearwood.info> wrote: >> > On Thu, Apr 30, 2015 at 01:41:53PM +0200, Dima Tisnek wrote: >> >> # internal vs external >> >> @intify >> >> def foo() -> int: >> >> b = "42" >> >> return b # check 1 >> >> x = foo() // 2 # check 2 >> >> >> >> Does the return type apply to implementation (str) or decorated >> >> callable (int)? >> > >> > I would expect that a static type checker would look at foo, and flag >> > this as an error. The annotation says that foo returns an int, but it >> > clearly returns a string. That's an obvious error. >> >> Is this per PEP, or just a guess? >> >> I think PEP needs to be explicit about this. > > > The PEP shouldn't have to explain all the rules for type inferencing. > There's a section "What is checked?" that says (amongst other things): > > The body of a checked function is checked for consistency with the > given annotations. The annotations are also used to check correctness > of calls appearing in other checked functions. > >> > Normally local variables will have their type inferred from the >> > operations done to them: >> > >> > s = arg[1:] # s has the same type as arg >> >> Good point, should be mentioned in PEP. > > > Again, what do you want the PEP to say? I am trying to keep the PEP shorter > than the actual code that implements the type checker. :-) > >> >> Technically, type can be empty list, mixed list or custom return type >> for overloaded __getitem__ that accepts slices. >> >> I'm sorry if I was not clear. My question was how should type of >> ephemeral `x` be specified. >> In other words, can types be specified on anything inside a comprehension? > > > That's actually a good question; the PEP shows some examples of #type: > comments in peculiar places, but there's no example using list > comprehensions. Your best bet is to leave it to the type inferencer; if your > comprehension is so complex that need to put type annotations on parts of > it, you may be better off rewriting it as a regular for-loop, which offers > more options for annotations. > >> >> Stub is better (required?) because it allows to specify types of >> attributes that are not assigned in class scope, but that are expected >> to be there as result of __init__ or because it's a C extension. > > > Note that the PEP does not explicitly say whether the information of a stub > might be *merged* with the information gleaned from the source code. The > basic model is that if a stub is present the implementation source code is > not read at all by the type checker (and, conversely, information from stubs > is not available at all at runtime). But it is possible for some type > checker to improve upon this model. > >> >> An example in PEP would be good. > > > Can you give an example that I can edit and put in the PEP? > > -- > --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
