Re: [Python-Dev] Exposing pkguitl's import emulation (was Re: [Python-checkins] r85538 - python/branches/py3k/Doc/library/pkgutil.rst)
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.
That said, who knows when we'll actually have it done right, so in the meantime maybe having an official workaround is better than nothing...
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com
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. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Fri, Oct 22, 2010 at 09:26, Georg Brandl <g.brandl@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.
On Sat, Oct 23, 2010 at 5:11 AM, Brett Cannon <brett@python.org> wrote:
On Fri, Oct 22, 2010 at 09:26, Georg Brandl <g.brandl@gmx.net> wrote:
Am 19.10.2010 17:24, schrieb P.J. Eby:
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.
Given the water under this bridge (and the fact PJE actually did intend for these to be public interfaces), I'm happy enough with the idea of having these pkgutil features documented properly. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Brett Cannon -
Georg Brandl -
Nick Coghlan -
P.J. Eby