There is still a problem here, though not something a typical user would
run into:

rdmurray@partner:~/python/trunk>./python
Python 2.7a0 (trunk:73845M, Jul  4 2009, 12:43:10)
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logging.basicConfig(level=object())
>>> logging.info("test")

However, I've expanded the title to cover a second way this bug can be
encountered that is more likely to bite someone (and thus I am reopening
it):

Python 2.7a0 (trunk:73845M, Jul  4 2009, 12:43:10) 
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logging.basicConfig(level=logging.DEBUG)
>>> logging.info('test')
INFO:root:test
>>> logging.getLogger().setLevel("DEBUG")
>>> logging.info('test')

Neither one of these is a problem in 3.x in the sense that if you pass a
string argument under 3.x, the result is not silence:

Python 3.2a0 (py3k:73867M, Jul  6 2009, 12:52:11) 
[GCC 4.1.2 (Gentoo 4.1.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logging.basicConfig(level=object())
>>> logging.info("foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/py3k/Lib/logging/__init__.py", line 1471,
in info
    root.info(msg, *args, **kwargs)
  File "/home/rdmurray/python/py3k/Lib/logging/__init__.py", line 1045,
in info
    if self.isEnabledFor(INFO):
  File "/home/rdmurray/python/py3k/Lib/logging/__init__.py", line 1236,
in isEnabledFor
    return level >= self.getEffectiveLevel()
TypeError: unorderable types: int() >= object()

However, it seems like it would be much better even in the 3.x case to
have the error occur when the level is set rather than when it is used.

To fix this bug I think setLevel should do a type check.  Log already
does a type check (isintance(level, int)), so that's what I think
setLevel should do.  One could alternatively enhance the logging API to
have setLevel accept a string.  That, however, is an enhancement and not
a bugfix, IMO.

I've included a patch that adds the isinstance check, and tests for
same, and reverts the basicConfig change.  Vinay, if you'd rather have
the level-name-lookup enhancement I'd be happy to do it and also do the
doc update, but I don't think the enhancement bits should be backported
to 2.6 or 3.1 so I would do it as a separate patch.

Oh, and one last note: I didn't do the raiseExceptions test in setLevel
the way 'log' does because I figure an error at the config level should
not be suppressed...but raiseExceptions doesn't seem to be documented
(at least, I couldn't find it) so I'm not sure if that's the right thing
to do.