I've written a convenience wrapper around ConfigObj (which is a imporved
ConfigParser).
Now if I use an instance of the base class, I can easily test is the
instance exists by " if ini:",
like in this example
ini = None
if ini:
print 'ok',type(ini)
else:
print 'wrong',type(ini)
ini = ConfigObj (filename)
if ini:
print 'ok',type(ini)
else:
print 'wrong',type(ini)
Now if I derive a new class form this:
class inifile (ConfigObj):
def __init__ (self, filename):
self.ini = ConfigObj ( filename , list_values = False,
write_empty_values = True )
self.ini.newlines = '\r\n' # not strictly necessary
self.Section = ''
self.Modified = False
the test if an instance exists, always returns false.
ini = inifile (filename)
if ini:
print 'ok',type(ini)
else:
print 'wrong',type(ini)
Why is that ?
What should I do to the same simple test for existance ?
thanks,
Stef Mientki
First, object construction always gives you an object or raises an
exception, so you don't have to test for existence. If you don't know
if an object has been created, you should initialise ini to None, and
test with 'if ini is not None:'.
'if x' doesn't test if x exists, it tests if x when cast to a bool is
True. ConfigParser acts like a container, and returns False if it's
empty. Your class is (indirectly) a subclass of ConfigParser, but is
never initialised as such, and so is empty. So 'if ini' returns False,
and you get your confused result.
You need to decide if inifile is a subclass of ConfigObj, or is a
wrapper round a ConfigObj. Probably you want the former and your init
method should be something like:
def __init__(self, filename):
ConfigObj.__init__(self, filename, list_values=False,
write_empty_values=True)
self.newlines = '\r\n'
self.Section = ''
self.Modified = False
--
Paul Hankin
Use isinstance(obj, type).
Diez
> stef mientki schrieb:
> > What should I do to the same simple test for existance ?
>
> Use isinstance(obj, type).
No, that's *far* more specific than "does it exist", and will give
false negatives.
Much better is::
foo = None
foo = do_something_to_get_instance()
# ...
if foo is not None:
# foo was bound to an instance correctly
Even better is just to use the object, and if it's not what was
expected, catch the exception at a level that knows what to do about
it.
--
\ "At my lemonade stand I used to give the first glass away free |
`\ and charge five dollars for the second glass. The refill |
_o__) contained the antidote." -- Emo Philips |
Ben Finney
> 'if x' doesn't test if x exists, it tests if x when cast to a bool is
> True.
To be pedantic:
Python doesn't have type casts. bool(x) doesn't cast x as a bool, it
creates a brand new Boolean object from x.
Also, the "if x" test looks at x.__nonzero__() first, and if that method
doesn't exist, it looks to see if x.__len__() returns 0 or not. See
http://docs.python.org/ref/customization.html
--
Steven.
> On Wed, 17 Oct 2007 23:12:15 +0000, Paul Hankin wrote:
>
>> 'if x' doesn't test if x exists, it tests if x when cast to a bool is
>> True.
>
> To be pedantic:
>
> Python doesn't have type casts. bool(x) doesn't cast x as a bool, it
> creates a brand new Boolean object from x.
Actually, to be even more pedantic, True and False are both singletons,
and so bool() doesn't actually create a new Boolean object but reuses the
existing ones.
--
Steven.
To be even more pedantic, 'if x' does not invoke the builtin bool(),
instead it uses PyObject_IsTrue, which returns a plain C integer, not a
Python bool object.
--
Gabriel Genellina
> "Diez B. Roggisch" <de...@nospam.web.de> writes:
>
>> stef mientki schrieb:
>> > What should I do to the same simple test for existance ?
>>
>> Use isinstance(obj, type).
>
> No, that's *far* more specific than "does it exist", and will give
> false negatives.
I've misread the post entirely, so just... discard my message :)
Diez
To be lazy, you can get away with 'if x:' if you *know* that neither
the class nor its superclasses override .__nonzero__ or .__len__,
because the instance then defaults to true. Classes that *do*
override these methods are generally emulating a numeric or collection
type, or are using False to signal "something isn't there".
ConfigParser is doing the latter. That may or may not have been a
good choice by the ConfigParser developers, because it's debatable how
useful it is for empty ConfigParsers to be False. But the fact
remains that it is this way, and an instance of *any* third-party
class may be false for reasons you don't expect.
--Mike