>>>>> "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
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