[Python-Dev] Re: [Import-sig] Re: Proposal for a modified import mechanism.

[Barry A. Warsaw]

>>>>> "PR" == Prabhu Ramachandran <prabhu@aero.iitm.ernet.in> writes:

    PR>   (1) Re-nesting a package is a pain.  What I mean by
    PR> re-nesting is that say I have a package, A, that is separate
    PR> (and that has its own sub packages) and now I want it as part
    PR> of another package, B.

Why would you want to do that?  Why not just keep them separate
top-level packages that cooperate?  Or export A's names in B's
modules?  I think distutils helps out here because it's now easy to
install A in a way that B could just use, or add to.

FWIW, we knit things together as well, e.g. with StandaloneZODB.  It's
got a bunch of top-level packages that are treated as a single entity
via a figment of CVS's imagination.  So what if it installs a bunch of
separate top-level package names that aren't all treed under a single
package?
    
    PR> Lets further suppose that the module which re-nests the
    PR> package, B, tracks the development of A and keeps their copy
    PR> updated.

Okay.
    
    PR> In this case A is developed as a standalone package and B adds
    PR> something to it that A cannot/refuses to use.

Okay.
    
    PR> With the current approach B would be forced to modify A every
    PR> time A changes in some significant way simply because A was
    PR> re-nested.  Yes, this is contrived but such situations do
    PR> occur.

Why does B have to add packages to A's namespace?  Why can't the B
author simply use distutils to ensure that vanilla A is installed,
import the bits and pieces of A that you want to expose, overriding
what you want to change, and export an interface through B that
clients can use instead of A?  I.e. through the use of "from foo
import bar" and "from foo import bar as baz", you can present whatever
public interface you want, through B's namespace, and mimic as much or
as little of A's as you want.

    PR> Its not the application that I'm concerned about - an
    PR> application is typically a single/few file(s) and editing them
    PR> to suit things is certainly not an issue.

Well, not /all/ applications!
    
    JH> I expect there is more to the issue than just wanting to avoid
    JH> some extra typing.  A short PEP that describes the specific
    JH> problems being solved and discussing alternatives would help.

    BAW> Indeed.  We've been here before (perhaps, several "befores"
    BAW> :).  Every time this comes up I get the feeling like there
    BAW> are easy ways to accomplish what you want if you think of the

    PR> So do I need to write a PEP?  Is there some special
    PR> formality/format I need to keep in mind?

PEP 1 and PEP 9 are your guidelines to proper PEP form and procedure.

    BAW> Are the needs of application authors different than library
    BAW> authors?

    PR> I would think so.

That would be good to outline in your PEP then <wink>.

-Barry