[Python-3000] Minor addition to Python interactive shell...

[Abdallah El Guindy]

Adding a package to the repositories searched by apt-get is a much
> higher-ceremony operation than copying a file into some sys.path
> directory or changing sys.path, so that indexing makes sense for
> apt-get but not for Python's imports -- I can imagine the poor Python
> interpreter churning away all the time updating the index all the
> time.
>
You are definitely right about that, I totally missed this when first
thinking about it...

there is absolutely
> nothing to be gained by having the functionality inside the core
> rather than in a third-party package.
>
I guess you are right once again.

If and when your extension "takes the Python world by storm"


I guess this is never gonna happen (that's why I probably tagged the feature
minor).

I did not realized at the beginning that it has as much technical
complications.. Thanks for pointing that out, I'm convinced that perhaps it
is not a good idea after all.

Thanks.

On Sun, Aug 24, 2008 at 12:35 AM, Alex Martelli <aleaxit at gmail.com> wrote:

> On Sat, Aug 23, 2008 at 2:10 PM, Abdallah El Guindy
> <abdallah.elguindy at gmail.com> wrote:
> > I believe there must be a way... Maybe by creating an index file for each
> > module. I'm not sure, but I think the number of packages on apt-get is
> much
> > more than the number of python built-in modules (obviously I don't know
> > their number), yet it is doable with the case of apt-get.
>
> Adding a package to the repositories searched by apt-get is a much
> higher-ceremony operation than copying a file into some sys.path
> directory or changing sys.path, so that indexing makes sense for
> apt-get but not for Python's imports -- I can imagine the poor Python
> interpreter churning away all the time updating the index all the
> time.  And even then, the Python index WOULD still potentially miss
> some entries, because a Python module is vastly more dynamic than the
> totally-static repositories used by apt-get, where each package is
> mandated to very explicitly state what it requires, and what it
> provides.
>
> If you want to try your hand at this kind of extension, I recommend
> you do it as a pypi package -- since all you want is peculiar messages
> in response to some NameError or ImportError exceptions, you can hang
> your functionality neatly into sys.excepthook -- there is absolutely
> nothing to be gained by having the functionality inside the core
> rather than in a third-party package.  Moreover, I would recommend
> targeting the extension (solely or primarily) at "rich" environments
> such as IDLE or ipython (http://ipython.scipy.org/moin/), whose users
> already expect and obviously appreciate getting especially rich
> interactive functionality even if it comes at the potential cost of
> some overhead -- users of the Python built-in interactive interpreter
> are more likely to be after lean-and-mean functionality instead.
>
> If and when your extension "takes the Python world by storm", you will
> have strong practical arguments to recommend its inclusion in some
> future version of Python -- its popularity will have proven that there
> is strong demand for that functionality, after all.  Until such
> support does exist, it's hard to argue for including in the Python
> core offering something that can be done just as well as a 3rd party
> package, has no proven demand, AND presents potentially delicate
> tradeoffs in terms of implementation (is the user going to be asked to
> explicitly reindex each time they alter sys.path, or is the overhead
> of the reindexing going to be implicit in ANY alteration at all?  etc,
> etc).
>
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-3000/attachments/20080824/0075ecf7/attachment.htm>