A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-December/041044.html below:

[Python-Dev] Re: Christmas Wishlist

[Python-Dev] Re: Christmas WishlistBill Janssen janssen at parc.com
Mon Dec 15 18:45:11 EST 2003
> Why?  I'd really like to see some concrete use cases for relative
> imports, other than just saving some typing.

Suppose you've developed a Python top-level application, composed of a
package 'foo' containing a number of submodules and subpackages.
You'd now like to add this to a Jython application as a library, part
of a larger application.  It's nice to be able to just add a
higher-level package structure, com.mycompany.myapp, to the Python
package, to fit in with the style of your application.  Yet you don't
want to edit the Python code to 'import
com.mycompany.myapp.foo.submodule' everywhere; you'd like 'import
submodule' or 'import foo.submodule' to continue working.  Often the
code has to work in both the stand-alone and the federated case.

This is just a special case of the federation problem that we've seen
for years in distributed computing; previously top-level names get
federated when new higher-level constructs are formed.  Ken mentioned
enterprise programming; it's another case of this.  Two companies
merge and start merging their code.  It's much better to be able to
write (in the new higher-level module bletch.py)

     import foo
     import bar

and have the subpackages under foo and bar continue to work without
rewrites, than have to go through all the code under foo and bar and
change it to know about the new higher-level bletch namespace.

Bill

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4