[PATCH] Fix readfp behaviour

[Debarshi 'Rishi' Ray]

Please find attached a patch against iniparse-0.2 to fix the behaviour
of the readfp methods.

Currently iniparse uses the following construct to read from a file
object, which requires the file object to be iterable:

for line in fp:
...
...

While using iniparse with YUM, I discovered that this leads to a
problem. YUM does not use a standard file object as the first
parameter to these readfp methods. It passes an instance of
ConfigPreProcessor instead, which tries to behave as a file object.

However ConfigPreProcessor is not iterable. It implements a method
called readline which returns one line after another of the file. This
leads to the following problem:

>>> q = iniparse.compat.ConfigParser()
>>> q.readfp(file('/etc/yum.repos.d/fedora-local.repo', 'r'))
>>> q.sections()
['fedora-local', 'fedora-7-buildgroups-local', 'fedora-development-local']
>>>
>>> q.readfp(cp)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line
106, in readfp
self.data.readfp(fp)
File "/usr/lib/python2.5/site-packages/iniparse/ini.py", line 471, in readfp
for line in fp:
TypeError: iteration over non-sequence
>>>

Since the original Python ConfigParser uses the readline method of
file objects, unlike iniparse, YUM works fine with it.

The definition of a readline method is more general and user-friendly
than the requirement of iterable file objects because while iterating
we are making use of the readline method itself.

Moreover since we are aiming to be be compatible with the original
implementation, we need to ensure that not only the interface but also
the internal behaviour is backward compatible.

What do you think?

Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu

[Paramjit Oberoi]

You're right - the standard library's ConfigParser only uses the
.readline() method on the file object. I agree that this change is a
good idea.

Would you like to check it in yourself, or shall I apply the patch?

-param

[Debarshi 'Rishi' Ray]

> Would you like to check it in yourself, or shall I apply the patch?

I shall commit it tonight, if there is no further objection.

[Tim Lauridsen]

Debarshi 'Rishi' Ray wrote:

Would you like to check it in yourself, or shall I apply the patch?
    

I shall commit it tonight, if there is no further objection.

Happy hacking,
Debarshi
  

Looks fine to me.

Tim

[Debarshi 'Rishi' Ray]

Committed.

Tim, can you please include this patch in the RPM as well?

[Paramjit Oberoi]

I would prefer a new release - we don't want different variants of the
code in the wild with identical version numbers.

-param

[Debarshi 'Rishi' Ray]

> I would prefer a new release - we don't want different variants of the
> code in the wild with identical version numbers.

Whatever it is. Without the patch, iniparse can not be used by YUM.
:-) So a newer RPM release number or a newer upstream version number
would be fine.

[Tim Lauridsen]

Paramjit Oberoi wrote:
> I would prefer a new release - we don't want different variants of the
> code in the wild with identical version numbers.
>
> -param
>

I agree a new release is need, the rpm must match upstream.

Tim

[Paramjit Oberoi]

With this change, it works with YUM, right?
If there are any other small issues, I'd like to get them cleared up
as well before the 0.2.1 release.

-param

On 7/27/07, Debarshi 'Rishi' Ray <debars...@gmail.com> wrote:
>

[Debarshi 'Rishi' Ray]

> With this change, it works with YUM, right?

Yes, it does.

> If there are any other small issues, I'd like to get them cleared up
> as well before the 0.2.1 release.

Will let you know before this week-end gets over.

[Paramjit Oberoi]

The readline change broke some tests - if the file contained an empty
line at the end, that empty line was not being preserved. I just
checked in a fix.

-param

PS: you can run the tests by running "runtests.py" script from the
root of the source.