Document None values in sys.modules?
Hi all, is the presence of None values in sys.modules considered an implementation detail? If not, it should be documented what the None values mean to the interpreter. 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 Jul 23, 2009, at 2:59 PM, Georg Brandl wrote:
is the presence of None values in sys.modules considered an implementation detail? If not, it should be documented what the None values mean to the interpreter.
As I recall, they're an optimization. But since sys.modules is itself documented, and many applications actually use it, I think it's worth explaining that the None values can reasonably be expected, and what they indicate. -Fred -- Fred Drake <fdrake at acm.org>
On Thu, Jul 23, 2009 at 12:09 PM, Fred Drake<fdrake@acm.org> wrote:
On Jul 23, 2009, at 2:59 PM, Georg Brandl wrote:
is the presence of None values in sys.modules considered an implementation detail? If not, it should be documented what the None values mean to the interpreter.
As I recall, they're an optimization. But since sys.modules is itself documented, and many applications actually use it, I think it's worth explaining that the None values can reasonably be expected, and what they indicate.
They should certainly be documented -- without them imports from inside package would be super expensive (at least for Python versions where implicit relative import exists). I'm somewhat surprised this isn't documented, I don't think I've tried to keep this usage hidden. I've also sometimes abused this to force some module to believe that a certain other module doesn't exist. OTOH in Py3k I'm not sure that we even *need* them any more, since there is no more implicit relative import... They would only speed up the raising of ImportError, not the finding of a similar-named module elsewhere in the hierarchy. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, Jul 23, 2009 at 13:05, Guido van Rossum <guido@python.org> wrote:
On Jul 23, 2009, at 2:59 PM, Georg Brandl wrote:
is the presence of None values in sys.modules considered an
implementation
detail? If not, it should be documented what the None values mean to
On Thu, Jul 23, 2009 at 12:09 PM, Fred Drake<fdrake@acm.org> wrote: the
interpreter.
As I recall, they're an optimization. But since sys.modules is itself documented, and many applications actually use it, I think it's worth explaining that the None values can reasonably be expected, and what they indicate.
They should certainly be documented -- without them imports from inside package would be super expensive (at least for Python versions where implicit relative import exists). I'm somewhat surprised this isn't documented, I don't think I've tried to keep this usage hidden. I've also sometimes abused this to force some module to believe that a certain other module doesn't exist.
It has not been hidden, but the only place I ever came across it was in the original essay about packages.
OTOH in Py3k I'm not sure that we even *need* them any more, since there is no more implicit relative import... They would only speed up the raising of ImportError, not the finding of a similar-named module elsewhere in the hierarchy.
None in Python 3.1 is really useless in terms of its semantics in relative imports; importlib doesn't support it and still passes as __import__ (at least last time I ran the test suite that way). I thought we had agreed a while back that supporting None was not warranted in Python 3.0? Otherwise I will do whatever work is necessary for this to happen. -Brett
2009/7/23 Brett Cannon <brett@python.org>:
None in Python 3.1 is really useless in terms of its semantics in relative imports; importlib doesn't support it and still passes as __import__ (at least last time I ran the test suite that way). I thought we had agreed a while back that supporting None was not warranted in Python 3.0? Otherwise I will do whatever work is necessary for this to happen.
I think it's still nice for the rare cases where you need to trick a module into thinking another one doesn't exist. -- Regards, Benjamin
On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <benjamin@python.org>wrote:
2009/7/23 Brett Cannon <brett@python.org>:
None in Python 3.1 is really useless in terms of its semantics in relative imports; importlib doesn't support it and still passes as __import__ (at least last time I ran the test suite that way). I thought we had agreed a while back that supporting None was not warranted in Python 3.0? Otherwise I will do whatever work is necessary for this to happen.
I think it's still nice for the rare cases where you need to trick a module into thinking another one doesn't exist.
But None does not strictly mean "I don't exist". None is supposed to trigger an another import attempt for the module with a top-level name. It's that extra import trigger that has no real use in 3.0 and just complicates import semantics (IMO) needlessly. If you want a module to not exist then you either stick something else in (e.g. '42') or we remove the special semantics for None (which I thought we had). -Brett
2009/7/23 Brett Cannon <brett@python.org>:
On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <benjamin@python.org> wrote:
2009/7/23 Brett Cannon <brett@python.org>:
None in Python 3.1 is really useless in terms of its semantics in relative imports; importlib doesn't support it and still passes as __import__ (at least last time I ran the test suite that way). I thought we had agreed a while back that supporting None was not warranted in Python 3.0? Otherwise I will do whatever work is necessary for this to happen.
I think it's still nice for the rare cases where you need to trick a module into thinking another one doesn't exist.
But None does not strictly mean "I don't exist". None is supposed to trigger an another import attempt for the module with a top-level name. It's that extra import trigger that has no real use in 3.0 and just complicates import semantics (IMO) needlessly. If you want a module to not exist then you either stick something else in (e.g. '42') or we remove the special semantics for None (which I thought we had).
I didn't realize None had other semantics attached to it. (Imagine that dealing with import!) +1 for making it simply indicate an ImportError. -- Regards, Benjamin
On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson <benjamin@python.org>wrote:
2009/7/23 Brett Cannon <brett@python.org>:
On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <benjamin@python.org> wrote:
2009/7/23 Brett Cannon <brett@python.org>:
None in Python 3.1 is really useless in terms of its semantics in relative imports; importlib doesn't support it and still passes as __import__
least last time I ran the test suite that way). I thought we had agreed a while back that supporting None was not warranted in Python 3.0? Otherwise I will do whatever work is necessary for this to happen.
I think it's still nice for the rare cases where you need to trick a module into thinking another one doesn't exist.
But None does not strictly mean "I don't exist". None is supposed to
(at trigger
an another import attempt for the module with a top-level name. It's that extra import trigger that has no real use in 3.0 and just complicates import semantics (IMO) needlessly. If you want a module to not exist then you either stick something else in (e.g. '42') or we remove the special semantics for None (which I thought we had).
I didn't realize None had other semantics attached to it. (Imagine that dealing with import!) +1 for making it simply indicate an ImportError.
I'm +0 with having import raise ImportError if None is set in sys.modules as long as we don't suddenly expect loaders to trigger the same thing if they return None (actually, as of right now what loaders return count for nothing, but just want to be clear). -Brett
So, I guess, we'll live with it for a while longer. Given that it managed to evade our attention for so long, I think that's fine. I agree that there's no reason for a None result from loaders to be interpreted the same way, assuming that's not how it works ATM. And we can live with import and importlib differing on this in 3.1 (though you could call it a bug in importlib and fix it for 3.1.1 -- not sure if you were planning on that). --Guido On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon<brett@python.org> wrote:
On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson <benjamin@python.org> wrote:
2009/7/23 Brett Cannon <brett@python.org>:
On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <benjamin@python.org> wrote:
2009/7/23 Brett Cannon <brett@python.org>:
None in Python 3.1 is really useless in terms of its semantics in relative imports; importlib doesn't support it and still passes as __import__ (at least last time I ran the test suite that way). I thought we had agreed a while back that supporting None was not warranted in Python 3.0? Otherwise I will do whatever work is necessary for this to happen.
I think it's still nice for the rare cases where you need to trick a module into thinking another one doesn't exist.
But None does not strictly mean "I don't exist". None is supposed to trigger an another import attempt for the module with a top-level name. It's that extra import trigger that has no real use in 3.0 and just complicates import semantics (IMO) needlessly. If you want a module to not exist then you either stick something else in (e.g. '42') or we remove the special semantics for None (which I thought we had).
I didn't realize None had other semantics attached to it. (Imagine that dealing with import!) +1 for making it simply indicate an ImportError.
I'm +0 with having import raise ImportError if None is set in sys.modules as long as we don't suddenly expect loaders to trigger the same thing if they return None (actually, as of right now what loaders return count for nothing, but just want to be clear). -Brett
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, Jul 23, 2009 at 20:18, Guido van Rossum <guido@python.org> wrote:
So, I guess, we'll live with it for a while longer. Given that it managed to evade our attention for so long, I think that's fine.
Can someone double-check me that the semantics can even be triggered in 3.1? I just tried and couldn't come up with anything. Heck, I quick search for a Py_None comparison in 3.1's import.c turned up nothing useful (other than mark_miss() is the function used to set None in sys.modules). We might have actually already removed it or made it so that the semantics can't be triggered.
I agree that there's no reason for a None result from loaders to be interpreted the same way, assuming that's not how it works ATM.
And we can live with import and importlib differing on this in 3.1 (though you could call it a bug in importlib and fix it for 3.1.1 -- not sure if you were planning on that).
I can if people can trigger the semantics somehow so I have a test to go by. -Brett
--Guido
On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon<brett@python.org> wrote:
On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson <benjamin@python.org> wrote:
2009/7/23 Brett Cannon <brett@python.org>:
On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <benjamin@python.org
wrote:
2009/7/23 Brett Cannon <brett@python.org>:
None in Python 3.1 is really useless in terms of its semantics in relative imports; importlib doesn't support it and still passes as
(at least last time I ran the test suite that way). I thought we had agreed a while back that supporting None was not warranted in Python 3.0? Otherwise I will do whatever work is necessary for this to happen.
I think it's still nice for the rare cases where you need to trick a module into thinking another one doesn't exist.
But None does not strictly mean "I don't exist". None is supposed to trigger an another import attempt for the module with a top-level name. It's that extra import trigger that has no real use in 3.0 and just complicates import semantics (IMO) needlessly. If you want a module to not exist then you either stick something else in (e.g. '42') or we remove the special semantics for None (which I thought we had).
I didn't realize None had other semantics attached to it. (Imagine that dealing with import!) +1 for making it simply indicate an ImportError.
I'm +0 with having import raise ImportError if None is set in sys.modules as long as we don't suddenly expect loaders to trigger the same thing if
__import__ they
return None (actually, as of right now what loaders return count for nothing, but just want to be clear). -Brett
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Still works, at least in some old 3.1 I had lying around: $ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import sys sys.modules['string'] = None import string Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named string
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import string
$
The experiment should be easily repeatable. :-) --Guido On Thu, Jul 23, 2009 at 8:35 PM, Brett Cannon<brett@python.org> wrote:
On Thu, Jul 23, 2009 at 20:18, Guido van Rossum <guido@python.org> wrote:
So, I guess, we'll live with it for a while longer. Given that it managed to evade our attention for so long, I think that's fine.
Can someone double-check me that the semantics can even be triggered in 3.1? I just tried and couldn't come up with anything. Heck, I quick search for a Py_None comparison in 3.1's import.c turned up nothing useful (other than mark_miss() is the function used to set None in sys.modules). We might have actually already removed it or made it so that the semantics can't be triggered.
I agree that there's no reason for a None result from loaders to be interpreted the same way, assuming that's not how it works ATM.
And we can live with import and importlib differing on this in 3.1 (though you could call it a bug in importlib and fix it for 3.1.1 -- not sure if you were planning on that).
I can if people can trigger the semantics somehow so I have a test to go by. -Brett
--Guido
On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon<brett@python.org> wrote:
On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson <benjamin@python.org> wrote:
2009/7/23 Brett Cannon <brett@python.org>:
On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <benjamin@python.org> wrote:
2009/7/23 Brett Cannon <brett@python.org>: > None in Python 3.1 is really useless in terms of its semantics in > relative > imports; importlib doesn't support it and still passes as > __import__ > (at > least last time I ran the test suite that way). I thought we had > agreed > a > while back that supporting None was not warranted in Python 3.0? > Otherwise I > will do whatever work is necessary for this to happen.
I think it's still nice for the rare cases where you need to trick a module into thinking another one doesn't exist.
But None does not strictly mean "I don't exist". None is supposed to trigger an another import attempt for the module with a top-level name. It's that extra import trigger that has no real use in 3.0 and just complicates import semantics (IMO) needlessly. If you want a module to not exist then you either stick something else in (e.g. '42') or we remove the special semantics for None (which I thought we had).
I didn't realize None had other semantics attached to it. (Imagine that dealing with import!) +1 for making it simply indicate an ImportError.
I'm +0 with having import raise ImportError if None is set in sys.modules as long as we don't suddenly expect loaders to trigger the same thing if they return None (actually, as of right now what loaders return count for nothing, but just want to be clear). -Brett
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Jul 24, 2009 at 10:39, Guido van Rossum <guido@python.org> wrote:
Still works, at least in some old 3.1 I had lying around:
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import sys sys.modules['string'] = None import string Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named string
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import string
$
The experiment should be easily repeatable. :-)
=) Yes, the None raising ImportError semantics can be added easily and codified as official import semantics in 3.1. I was talking about the "None triggers another import as with relative imports" semantics and if there was some rather convoluted way to trigger that. I am guessing not as that would require a value of -1 for level which is no longer valid. I will fix importlib in both 3.2 and 3.1.1. And speaking of fixing, should I put the failing test in now and decorate it with unittest.expectedFailure until I get around to fixing it? -Brett
--Guido
On Thu, Jul 23, 2009 at 8:35 PM, Brett Cannon<brett@python.org> wrote:
On Thu, Jul 23, 2009 at 20:18, Guido van Rossum <guido@python.org>
wrote:
So, I guess, we'll live with it for a while longer. Given that it managed to evade our attention for so long, I think that's fine.
Can someone double-check me that the semantics can even be triggered in 3.1? I just tried and couldn't come up with anything. Heck, I quick search for a Py_None comparison in 3.1's import.c turned up nothing useful (other than mark_miss() is the function used to set None in sys.modules). We might have actually already removed it or made it so that the semantics can't be triggered.
I agree that there's no reason for a None result from loaders to be interpreted the same way, assuming that's not how it works ATM.
And we can live with import and importlib differing on this in 3.1 (though you could call it a bug in importlib and fix it for 3.1.1 -- not sure if you were planning on that).
I can if people can trigger the semantics somehow so I have a test to go by. -Brett
--Guido
On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon<brett@python.org> wrote:
On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson <benjamin@python.org
wrote:
2009/7/23 Brett Cannon <brett@python.org>:
On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <benjamin@python.org> wrote: > > 2009/7/23 Brett Cannon <brett@python.org>: > > None in Python 3.1 is really useless in terms of its semantics
in
> > relative > > imports; importlib doesn't support it and still passes as > > __import__ > > (at > > least last time I ran the test suite that way). I thought we had > > agreed > > a > > while back that supporting None was not warranted in Python 3.0? > > Otherwise I > > will do whatever work is necessary for this to happen. > > I think it's still nice for the rare cases where you need to trick a > module into thinking another one doesn't exist.
But None does not strictly mean "I don't exist". None is supposed to trigger an another import attempt for the module with a top-level name. It's that extra import trigger that has no real use in 3.0 and just complicates import semantics (IMO) needlessly. If you want a module to not exist then you either stick something else in (e.g. '42') or we remove the special semantics for None (which I thought we had).
I didn't realize None had other semantics attached to it. (Imagine that dealing with import!) +1 for making it simply indicate an ImportError.
I'm +0 with having import raise ImportError if None is set in sys.modules as long as we don't suddenly expect loaders to trigger the same thing if they return None (actually, as of right now what loaders return count for nothing, but just want to be clear). -Brett
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Jul 24, 2009 at 10:50 AM, Brett Cannon<brett@python.org> wrote:
On Fri, Jul 24, 2009 at 10:39, Guido van Rossum <guido@python.org> wrote:
Still works, at least in some old 3.1 I had lying around:
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import sys sys.modules['string'] = None import string Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named string
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import string
$
The experiment should be easily repeatable. :-)
=) Yes, the None raising ImportError semantics can be added easily and codified as official import semantics in 3.1.
I thought it was too simple. :-) Maybe I should go back to bed and nurse my cough some more instead of playing hookie from being sick and indulging in email.
I was talking about the "None triggers another import as with relative imports" semantics and if there was some rather convoluted way to trigger that.
I can't think of one and doubt you will find one -- it was introduced (in the earliest of early package import implementations) to optimize the problem we had with code living inside a package trying to stat() a toplevel module locally each time an import of it was processed (a problem if a package contains lots of modules each of which import os, sys, etc.). Since we no longer to relative import, I don't see how there could be another use -- if it's not there it's not there.
I am guessing not as that would require a value of -1 for level which is no longer valid.
Ah. Sure.
I will fix importlib in both 3.2 and 3.1.1. And speaking of fixing, should I put the failing test in now and decorate it with unittest.expectedFailure until I get around to fixing it?
Oh, I don't know. All this new-fangled technology... Can't you just leave it in your workspace, unsubmitted, until you get to fixing it? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, Jul 24, 2009 at 10:58, Guido van Rossum <guido@python.org> wrote:
On Fri, Jul 24, 2009 at 10:50 AM, Brett Cannon<brett@python.org> wrote:
On Fri, Jul 24, 2009 at 10:39, Guido van Rossum <guido@python.org>
wrote:
Still works, at least in some old 3.1 I had lying around:
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import sys sys.modules['string'] = None import string Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named string
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import string
$
The experiment should be easily repeatable. :-)
=) Yes, the None raising ImportError semantics can be added easily and codified as official import semantics in 3.1.
I thought it was too simple. :-) Maybe I should go back to bed and nurse my cough some more instead of playing hookie from being sick and indulging in email.
I'm glad I can help provide a distraction. And I hope you get over whatever you have soon.
I was talking about the "None triggers another import as with relative imports" semantics and if there was some rather convoluted way to trigger that.
I can't think of one and doubt you will find one -- it was introduced (in the earliest of early package import implementations) to optimize the problem we had with code living inside a package trying to stat() a toplevel module locally each time an import of it was processed (a problem if a package contains lots of modules each of which import os, sys, etc.). Since we no longer to relative import, I don't see how there could be another use -- if it's not there it's not there.
I am guessing not as that would require a value of -1 for level which is no longer valid.
Ah. Sure.
I will fix importlib in both 3.2 and 3.1.1. And speaking of fixing, should I put the failing test in now and decorate it with unittest.expectedFailure until I get around to fixing it?
Oh, I don't know. All this new-fangled technology... Can't you just leave it in your workspace, unsubmitted, until you get to fixing it?
Oh sure, I normally just leave it in my scratch svn checkout until I get around to it. But since we now have the decorator I was wondering if any discussion came up while I was gone of using it within our tests when we happen to get a working (failing) test case before we have a patch to fix it. -Brett
Brett Cannon <brett <at> python.org> writes:
Oh, I don't know. All this new-fangled technology... Can't you just leave it in your workspace, unsubmitted, until you get to fixing it?
Oh sure, I normally just leave it in my scratch svn checkout until I get around to it.
What? You're not even using a DVCS?
On Fri, Jul 24, 2009 at 11:13, Antoine Pitrou <solipsis@pitrou.net> wrote:
Brett Cannon <brett <at> python.org> writes:
Oh, I don't know. All this new-fangled technology... Can't you just leave it in your workspace, unsubmitted, until you get to fixing it?
Oh sure, I normally just leave it in my scratch svn checkout until I get around to it.
What? You're not even using a DVCS?
Not for Python; waiting for hg switch (all my other code uses hg). Never got a workflow involving both hg and svn up and going (and don't even mention gitsvn). -Brett
On Fri, Jul 24, 2009 at 10:39, Guido van Rossum <guido@python.org> wrote:
Still works, at least in some old 3.1 I had lying around:
Which reminds me, do we want to change the error message for ImportError in this case to say something like "import of {0} halted; None found in sys.modules"? Might be a tough exception to debug if you are not aware that some library shoved None into sys.modules.
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import sys sys.modules['string'] = None import string Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named string
$ python3.1 Python 3.1a0 (py3k:70152, Mar 3 2009, 16:55:42) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import string
$
The experiment should be easily repeatable. :-)
--Guido
On Thu, Jul 23, 2009 at 8:35 PM, Brett Cannon<brett@python.org> wrote:
On Thu, Jul 23, 2009 at 20:18, Guido van Rossum <guido@python.org>
wrote:
So, I guess, we'll live with it for a while longer. Given that it managed to evade our attention for so long, I think that's fine.
Can someone double-check me that the semantics can even be triggered in 3.1? I just tried and couldn't come up with anything. Heck, I quick search for a Py_None comparison in 3.1's import.c turned up nothing useful (other than mark_miss() is the function used to set None in sys.modules). We might have actually already removed it or made it so that the semantics can't be triggered.
I agree that there's no reason for a None result from loaders to be interpreted the same way, assuming that's not how it works ATM.
And we can live with import and importlib differing on this in 3.1 (though you could call it a bug in importlib and fix it for 3.1.1 -- not sure if you were planning on that).
I can if people can trigger the semantics somehow so I have a test to go by. -Brett
--Guido
On Thu, Jul 23, 2009 at 7:50 PM, Brett Cannon<brett@python.org> wrote:
On Thu, Jul 23, 2009 at 19:48, Benjamin Peterson <benjamin@python.org
wrote:
2009/7/23 Brett Cannon <brett@python.org>:
On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson <benjamin@python.org> wrote: > > 2009/7/23 Brett Cannon <brett@python.org>: > > None in Python 3.1 is really useless in terms of its semantics
in
> > relative > > imports; importlib doesn't support it and still passes as > > __import__ > > (at > > least last time I ran the test suite that way). I thought we had > > agreed > > a > > while back that supporting None was not warranted in Python 3.0? > > Otherwise I > > will do whatever work is necessary for this to happen. > > I think it's still nice for the rare cases where you need to trick a > module into thinking another one doesn't exist.
But None does not strictly mean "I don't exist". None is supposed to trigger an another import attempt for the module with a top-level name. It's that extra import trigger that has no real use in 3.0 and just complicates import semantics (IMO) needlessly. If you want a module to not exist then you either stick something else in (e.g. '42') or we remove the special semantics for None (which I thought we had).
I didn't realize None had other semantics attached to it. (Imagine that dealing with import!) +1 for making it simply indicate an ImportError.
I'm +0 with having import raise ImportError if None is set in sys.modules as long as we don't suddenly expect loaders to trigger the same thing if they return None (actually, as of right now what loaders return count for nothing, but just want to be clear). -Brett
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon -
Fred Drake -
Georg Brandl -
Guido van Rossum