Design and build a plugin architecture

[gvanrossum]

One area where this comes up is SQLAlchemy table definitions.

[jstasiak]

I was just gonna create a similar ticket, code using Injector[1] would be another case here.

[1] https://github.com/alecthomas/injector

[JukkaL]

I'm enumerating here a bunch of things that this might be good for. These fall roughly under two categories -- metaclasses (or more generally runtime configuration of classes) and callables with atypical signatures.

Metaclasses:

• SQLAlchemy
• Django models
• (and ORMs in general)

Functions with special signatures (some of these are of marginal utility):

• open() (and similar functions elsewhere; return type depends on mode string argument)
• re.findall (return type depends on structure of a regular expression)
• sys.exc_info (return value has no None items within except: block)
• universal_newlines in subprocess (boolean toggles between str / bytes)
• str.format and '...' % x (the latter is currently special cased in the type checker)
• dict(key=value) and dict.update with keyword arguments (the prior is currently special cased)
• sum (works for anything that supports +)
• Parts of itertools and functools
• struct (could infer type from format string)
• SQLAlchemy queries

For some of these I can also imagine more general type system support instead of a plugin.

[jstasiak]

Two examples of libraries that generate modules and classes based on some form of data schema:

• https://github.com/eleme/thriftpy
• https://github.com/jparyani/pycapnp

[JukkaL]

Other functions with tricky signatures:

• pow (return type varies based on the sign of the exponent)
• __pow__ (similar)

[dmoisset]

Things like numpy also fall here; some functions accept a "dtype" argument that controls the type of the output. Some functions return values or arrays depending on the arity of the "axis" argument.