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

[Prabhu Ramachandran]

>>>>> "JH" == Jeremy Hylton <jeremy@zope.com> writes:

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

    JH> I haven't followed this thread closely.  Is there some reason
    JH> that explicit names in imports is not sufficient?

    PR> Yes indeed there is.  I've already explained my reasons twice.
    PR> Eric also explained why this was important for Scipy.

[snip]

    JH> I have had a hard time trying to figure out precisely what the
    JH> problems are.

I think you got it mostly right. Let me try to elaborate on it.

  (1) Re-nesting a package is a pain.  What I mean by re-nesting is
  that say I have a package, A, that is separate (and that has its own
  sub packages) and now I want it as part of another package, B.  Lets
  further suppose that the module which re-nests the package, B,
  tracks the development of A and keeps their copy updated.  In this
  case A is developed as a standalone package and B adds something to
  it that A cannot/refuses to use.  With the current approach B would
  be forced to modify A every time A changes in some significant way
  simply because A was re-nested.  Yes, this is contrived but such
  situations do occur. 

  To make things clearer.  My main objection is that the name of a
  package when one imports it depends on its parent packages name.
  This is IMHO absurd.

       foo/
	   sub/
	   sub1/

  From sub1 if you had to import anything from sub you'd have to do
  import foo.sub.module.  So if foo is now part of something else -
  you have to change all references to foo.

  (2) If you have a complex package with more than 2-3 nested sub
  directories it becomes a huge pain to use clean import statements
  and not have to type long lines just to get to different modules.

  (3) If you argue that import must always do only absolute imports
  then why are sibling packages allowed?  i.e. if there are two
  modules in the same directory Python currently allows one to import
  them with a relative name rather than an absolute foo.sub.pkg kind
  of name.  If this is valid, then its natural to expect that
  searching also be done in the local package structure.

  (4) Yes, its possible re-factoring code but sometimes this can be a
  pain if you have a CVS tree and you want to re-organize your package
  structure.  Bernhard Herzog posted a solution for my specific
  problem, so that really is not the issue.  In my case the current
  cvsroot for my sources is this:

  cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mayavi/mayavi/

  and Bernhard's solution would create a directory structure like so:

  cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mayavi/mayavi/mayavi/

  Which is pretty crazy if you ask me, its bad enough as it is. :)
  this will solve my particular problem but is dirty.

    JH> What does "re-nesting" mean?  It get the impression you mean
    JH> putting one package inside another after it was developed and
    JH> pacakged for use as a top-level package.  If so, it doesn't
    JH> seem like a problem that occurs that often, right?  I'd be
    JH> hesitant to add features to the import mechanism to cater to
    JH> an infrequent case.

I've had about 4 others mailing me about their related problems.  So I
wouldn't classify this as a rare problem that can be safely ignored.

    JH> I'd rather see the imports be explicit "import root.a.b.c"
    JH> than "import b.c".  Then re-nesting requires all the import
    JH> statements to be edited.  It's more typing and might even
    JH> require a simple script to do search-and-replace, but it
    JH> doesn't sound like a prohibitive burden.

It all depends.  I think Eric explained his position pretty clearly.
I'm convinced that Python's import structure needs improvement.

    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.

Well, its all about convenience anyway - if not we'd all be talking to
computers in binary! <wink> Why do we need 'high-level' programming
languages?  Yes, I'm digressing into te philosophy of computing but I
dont think syntactic sugar is something to be ignored because its
silly.

    PR> from pkg import subpkg is also not the best way to do
    PR> imports. I personally prefer import pkg.subpkg and I believe
    PR> this is the recommended way of doing imports.

    JH> Why do you think this is the recommended way of doing imports?
    JH> I use both in my code and haven't been able to come up with a
    JH> clear rationale for doing one or the other.  The from
    JH> ... import form seems useful when the name of the
    JH> package/module is long or when it's only one or two names I'm
    JH> using.

Well, the Python howto explains it much better than I could hope to:

    http://py-howto.sourceforge.net/doanddont/node8.html

Since re-loading packages is important for me, I prefer using plain
imports.

prabhu