Possible Bachelor's thesis?

[tomascapek]

I am in my final year of studying theoretical computer science - compilers and stuff like that. It is not a surprising fact, that I need to write my thesis and I am looking for some topic, which results would actually help somebody. Since I fell in love with Python, I am here.

I am thinking, solving/creating something CS related in project like this, would easily qualify as my thesis and I'd love to do so!

Do you think, would this be possible (and if so, would you cooperate with me on my efforts?) Thanks!

[refi64]

Well, I think this was @JukkaL's thesis?

[tomascapek]

That's pretty cool thesis then :)

[elazarg]

I'm not sure what will count as thesis, but I have some ideas. None of these is guaranteed (or even likely) to be integrated into mypy, but they might be interesting. I also have only vague idea about the difficulty of the different ideas.

• Support user-defined type guard functions #1203 / Idea: allow description of type-effect for functions that return bool #2357: abstraction for the use of control-sensitive type checking
• The "problematic" part of Proposal: use binder (or similar) to track which attributes are defined. #4019
• Simple dependent types #3062: Add singleton types, or some kind of dependent type
• Type constraints: dict.get doesn't accept Union type as key #1472: Type constraints
• Adding intersection types, or maybe "ordered intersection types", and using it instead of
  -- Fallbacks in mypy
  -- Inheritance and method lookup
  -- Overloading
• Other fancy type systems:
  -- typestate (for files and iterators)
  -- session types (for generator functions)
• Automatic insertion of casts (actually, assertions), a-la gradual-typing "cast calculus". It will hurt performance badly, but can be useful in testing
• Some formalization of the mypy type system. I guess Jukka's PhD thesis can help, but AFAIK it is very different from the current version of mypy (I did not read it)
• Use mutation testing to check the quality of mypy's test suites. Find a way to integrate it into the development process in a usable way

Again, please don't take any of these blindly.

[JukkaL]

Other random ideas (with caveats similar to what @elazarg wrote):

• Numpy support
• Types for immutability (for example, declaring a function as "pure" and verifying this statically)
• Using and extending the mypy plugin system to support a complex framework like SQLalchemy
• Stubgen v2 that can generate usually-correct stubs somehow (for some definition of correctness)
• Type system support for monkey patching (I have some ideas about this that can perhaps serve as a starting point)

@ilinum might have some ideas as well.

[ilevkivskyi]

For numpy support see also #3345

[ilinum]

Here are some ideas that I have written down (that haven't been mentioned before):

• Support for Tensorflow Tensors
• Infer return types of functions and use them during typechecking.

[tomascapek]

Sorry for taking me this long to reply. At first, thank you all for your ideas. How about adding support for http://www.attrs.org/en/stable/ ?

[hroncok]

And possibly PEP 557.

[elazarg]

I'm not a fan of adding more hard-coded support for special types before we have an appropriate plugin system. At the moment we have hard-coded support for NamedTuples, Enums and TypedDict with significant code duplication and little to no reuse and abstraction, which is part of why #4083 is badly needed.

[ilevkivskyi]

@tomascapek If you will go with the attrs/plugin system, then please take into account that you shouldn't replace the corresponding TypeInfos, but you should modify them in-place (otherwise this will break forward references). There are some other ideas in #2088 dedicated to track this.

[tomascapek]

So after very long thinking, I decided not to do anything from mypy, as my thesis. Thanks for the ideas.