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 <[EMAIL PROTECTED]> wrote: > On Sat, Aug 23, 2008 at 2:10 PM, Abdallah El Guindy > <[EMAIL PROTECTED]> 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 >
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
