[Python-checkins] [Python-Dev] Exposing pkguitl's import emulation (was Re: r85538 - python/branches/py3k/Doc/library/pkgutil.rst)

Brett Cannon brett at python.org
Fri Oct 22 21:11:03 CEST 2010


On Fri, Oct 22, 2010 at 09:26, Georg Brandl <g.brandl at gmx.net> wrote:
> Am 19.10.2010 17:24, schrieb P.J. Eby:
>> At 08:03 AM 10/18/2010 +1000, Nick Coghlan wrote:
>>>I'm a little dubious about exposing these officially. They're mainly a
>>>hack to get some parts of the standard library working (e.g. runpy) in
>>>the absence of full PEP 302 support in the imp module, not really
>>>something we want to encourage anyone else to use (and yes, they
>>>should probably have underscores in their names, but we missed that
>>>when the various private implementations scattered around the stdlib
>>>were consolidated in pkgutil).
>>
>> Well, my intention at least was that they should be documented and
>> released; it's the documenting part I didn't get around to.  ;-)
>>
>> Of course, this was also pre-importlib; were we starting the work
>> today, the obvious thing to do would be to expose the Python
>> implementations of the relevant objects.
>
> I don't care much either way; however I don't really like when there are
> public APIs (i.e. non-underscore-prefixed globals in a non-underscore-
> prefixed module) that aren't documented, because it is confusing to
> developers who don't know if they can use it or not.  (See re.scanner.)
>
> The best thing is probably to let Brett (Hello Brett!) determine how
> much of it can be replaced by importlib, and add a note to that effect
> to the pkgutil docs.

The pkgutil stuff that was exposed cannot be directly replaced with a
public API in Python 3.2, but the plan is that it will be in Python
3.3 when *all* concrete implementations of importers are exposed
(because I will be attempting to bootstrap importlib). So if people
are willing to wait and take me at my word that this will happen in
Python 3.3, then this can come back out. But obviously I cannot make
promises as Real Life will *actually* be starting for me when the
Python 3.3 development cycle begins.


More information about the Python-checkins mailing list