Would you be interested in a PR adding type hints?

[Recursing]

I think type hints would help users and new contributors

[pietermarsman]

Yes, that's interesting! As long as it does not break anything; I am not sure if type hints are supported by Python3.4.

Some additional thoughts:

• you can start by adding types to the tools (e.g. pdf2txt.py and dumppdf.py), the high_level.py functions and the most used classes (e.g. PDFDocument, TextConverter, PDFPageAggregator, LAParams, PDFResourceManager, PDFPageInterpreter and PDFPage).
• mypy is a static type checker that could enforce the correct usage of types
• be sure to read pep484

[Recursing]

Python 3.4 does not support inline type annotations, so the valid syntax would be annoyingly verbose (and non-standard). But why do you guys even support it? I think it's not that common anymore

[pietermarsman]

I also think that very few people use that. It is much easier to upgrade from python 3.4 than it was from e.g. 2.7.

Let me check with other contributors to see what they think.

[jstockwin]

@pietermarsman Did you get any response from other contributors? In my view I think it's fine to drop python 3.4 support, and type hints would be nice.

The only drawback is it might be a slight blocker for other people contributing if they don't know how to use them.

@Recursing I appreciate it's been a long time, but we're currently trying to sort through all the open issues. Is this something you'd still be interested in helping with?

[Recursing]

The only drawback is it might be a slight blocker for other people contributing if they don't know how to use them.

They don't need to be mandatory. I think they would definitely help more than harm

Is this something you'd still be interested in helping with?

Sure

[pietermarsman]

@pietermarsman Did you get any response from other contributors? In my view I think it's fine to drop python 3.4 support, and type hints would be nice.

Not that I remember.

I like type annotations so I am pro :)

[jstockwin]

I also like them so I vote yes

[pietermarsman]

When we add this, we should also add mypy to the travis-ci test run. I just ran it locally, and there are only 8 issues. This surprised me a bit, but maybe its because we dont have type annotations yet. With mypy the type annotations add more value because we detect wrong usage of types earlier.

[jstockwin]

Agreed. Potentially also worth adding pytype as the two tools check different things

[pietermarsman]

I also wanted to add mypy to a work-related project, but after you suggested pytype I did a little research into that. And now I actually prefer pytype over mypy because of two benefits:

• pytype infers types from initialization methods, e.g. if you use str it infers the variable is a str. Mypy does not infer types and only relies on type annotations so much less coverage.
• It does type inference for every line, where mypy allows a single variable to have a single type during its entire lifetime. The latter might sound more strict and understandable, but it does not allow to map 'str' over a list or do multiple operations to the same variable.

See this presentation (by creator of pytype)

[jstockwin]

Yeah, I agree it's good. However, there are some things that mypy catches that pytype won't, so using both is a valid option.

[pietermarsman]

Lets leave it up to the one who implements it then :p I've moved this to accepted.

[djbrown]

Wouldn't it be best to add the stubs in https://github.com/python/typeshed?
Then the type hints would be completely optional.
I'm currently looking into this with local stubs.

[pietermarsman]

Closed by #661