What to do when a source package has Python components in a subdir?

["Zack Weinberg" <zackw@panix.com>]

Since Python policy is being revamped just now I thought I'd bring up
a complicated situation that I ran across recently (in packages that
are currently just for private use, but I might try to get them into
Debian eventually).

Consider a source package that builds a shared library, Python
bindings for that library (consisting of both "extensions" and
"modules"), and programs for /usr/bin that are written in Python and
use the library bindings.  Upstream distributes this as one big
tarball with a top-level autoconf-based configure script and Makefile.
The Python bindings are in a subdirectory; Make recurses into that
directory and invokes setup.py there.  Upstream makes no provision for
building the bindings against multiple versions of Python; however,
they work fine with all versions I've tried (2.3 and 2.4).

Policy questions:

* What is the appropriate set of binary packages for this scenario,
and what goes in each?
* What should the /usr/bin programs have on their #! line?  (I assume
/usr/bin/python, i.e. the default version, but explicitness would be
good.)

Packaging practices question:

* What is the best way to code debian/rules for this scenario?  Hack
up the upstream Makefiles to run setup.py repeatedly, or have
debian/rules reach in there and invoke it itself, or what?

Thanks,
zw