Hi!

Exciting to see work on a modular typeshed happening!

> * What to do with distributions that have only modules, but not packages? Since it is not easy to add a data file (like .pyi) not in a package, we use "dummy" packages named module_name-stubs with a single __init__.pyi.

PEP 561 actually says " This PEP does not support distributing typing information as part of module-only distributions. The code should be refactored into a package-based distribution and indicate that the package supports typing as described above." So your understanding is correct, stubs should be refactored into a package for module-only distributions.

> * What to do with packages that have different stub files for Python 2 and 3 (for example six)? Currently we just add two packages to the distribution, one six-stubs (as specified by PEP 561) and another six-python2-stubs.

PEP 561 requires that stus for a package *name* be installed under *name-stubs*, so puting python2-stubs is not PEP compliant. I see two solutions:

1) the stubs have if sys.version_info ... checks throughout the stubs

2) you have two packages, one for each Python version, but only install one into *name-stubs* at install time depending on the Python version they are being installed into. This seems sub-optimal as it would disallow wheels for distribution of such packages and require the stubs to be installed into the Python version you are checking.

I personally think that while 1) is a bit more work, it is the best solution for version straddling code. In addition, I expect the number of packages that need to straddle 2/3 will be fewer and more far between as time goes on.