[Python-Dev] What's missing in PEP-484 (Type hints) (original) (raw)

Dima Tisnek dimaqq at gmail.com
Tue May 12 16:04:56 CEST 2015

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 <guido at python.org> wrote:

On Thu, May 7, 2015 at 7:25 AM, Dima Tisnek <dimaqq at gmail.com> wrote:

On 30 April 2015 at 14:33, Steven D'Aprano <steve at 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)

More information about the Python-Dev mailing list