Issue 22 in iniparse: Adaptation to python 3
inip...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 22 by robert.h.de.vries: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
Hi,
I have taken to port iniparse to python 3.
Attached you will find my patch.
A second patch is a file that is missing causing the compat unit test to
fail.
The resulting set passes all unit tests.
Robert de Vries
Attachments:
iniparse.py3.patch 17.9 KB
cfgparser.1 23 bytes
inip...@googlecode.com
Status: Accepted
Comment #1 on issue 22 by psoberoi: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
Thanks. What's your opinion about how to transition to Python 3? Here are
the
options that I see:
* Release parallel Python 2 and Python 3 versions for a while
* Arrange things so that setup.py invokes 2to3.py when installing on Python
3.x
* Release the Python 3 version and stop development on the Python 2 version
inip...@googlecode.com
Comment #2 on issue 22 by robert.h.de.vries: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
The patch consists of some differences generated by 2to3, but there are
also many
changes made by me manually. Some of these changes were in the
documentation part
that contains usage examples. The code in those parts is not automatically
converted
by 2to3. All in all I think it is best to keep the two versions separate in
two branches.
I would propose to use git for this as it supports a rebase command that
allows to
merge changes in branches in an easy way. After you have made a change in
the master
branch you simply rebase the other branch to the tip of the master branch.
This keeps
the list of difference neatly synchronized between the two versions and you
can see
immediately the difference between the version for python 2 and 3.
inip...@googlecode.com
Comment #3 on issue 22 by tim.lauridsen: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
For now I think that making setup.py invokes 2to3 is the best way and test
that it
works for both 2.x and 3.x, 2.x will not go away for many years.
having 2 braches is also an option, but i dont think there are many benefit
to make it
at this point in time.
inip...@googlecode.com
Comment #4 on issue 22 by psoberoi: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
I'll experiment with 2to3 a bit and see how far we can take automatic
conversion.
Now that I have Fedora 13, it should be easy.
The 2.x branch has to remain the main branch for now to support existing
users. If
automatic conversion is not possible, I think the rebase idea is a good one
- the
code base is small enough that maintaining two branches is not too
impractical.
inip...@googlecode.com
Comment #5 on issue 22 by psoberoi: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
On further reflection... if two branches are needed, I'd want them to be
standard
branches rather than using rebase - so that they can be visible to other
people and
so that others can help to fix 3.x bugs.
inip...@googlecode.com
Comment #6 on issue 22 by robert.h.de.vries: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
Scrap my previous remark about rebase. It is better to maintain two separate
branches. After you have made a release of the python2 and python3 version
you cannot
rebase anyway.
The process I followed was along the same lines as the process recommended
on the
python website:
1. run unit tests for python2 version to verify all unit tests pass (they
did not
btw) see missing file remark in the original submission.
2. run 2to3
3. fix until all unit tests pass
I did the port on Fedora13 as well. Beware that the python3 package lacks
the module
test.support, if you install the python3-test package you should be fine.
inip...@googlecode.com
Comment #7 on issue 22 by tim.lauridsen: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
I rest my case, lets make 2 branches: one for 2.x and one for 3.x, when we
have a
release for Python3, i will make the packaging work for Fedora
inip...@googlecode.com
Comment #8 on issue 22 by robert.h.de.vries: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
I have already built a fedora13 package myself (not for the latest version
but
version 0.3.1) However it should easily translate to the latest version.
Attached my python3-iniparse.spec file
Attachments:
python3-iniparse.spec 1.5 KB
inip...@googlecode.com
Comment #9 on issue 22 by klaussfr...@gmail.com: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
Currently, test_fuzz fails after applying 2to3 to everything plus the
manual changes in test_unicode and test_compat:
======================================================================
FAIL: test_fuzz (tests.test_fuzz.test_fuzz)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/claudiofreire/src/iniparse-0.4/tests/test_fuzz.py", line 102,
in test_fuzz
self.assertEqualConfig(cc_py, cc)
File "/home/claudiofreire/src/iniparse-0.4/tests/test_fuzz.py", line 123,
in assertEqualConfig
self.assertEqual(c1.get(sec, opt), c2.get(sec, opt))
AssertionError: 't\\f5AcmV;e}x9{GSusOXbY/?<(K"kf=k\n\n\nH\'&j]`c4\'a*7(l(v>S/h?jl%o*UtjhbHA:u{H>
[truncated]... != 't\\f5AcmV;e}x9{GSusOXbY/?<(K"kf=k\nH\'&j]`c4\'a*7(l(v>S/h?jl%o*UtjhbHA:u{H>AR0u
[truncated]...
t\f5AcmV;e}x9{GSusOXbY/?<(K"kf=k
-
-
H'&j]`c4'a*7(l(v>S/h?jl%o*UtjhbHA:u{H>AR0urFZH)!Zoh,)d;`A0L(?OD4XezFnsc!ufFt-1A.-f3BDm:{K:wqA`^@&+qVC%
J0qA4~XfzVg!.)x3e$Ojf2W0%GN%M:w?u-MgTo3>46T#6~JTu~?B4y-P$\<9ZLG=<#t8SJC(CLraSvdJ#.A6jA$-
----------------------------------------------------------------------
Ran 96 tests in 0.071s
FAILED (failures=1)
inip...@googlecode.com
Comment #10 on issue 22 by robert.h...@gmail.com: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
I noticed there is a difference in handling empty lines in the value part.
The python3 configparser seems to preserve them, while iniparse removes
them.
The empty lines are indeed in the generated random settings file.
Question is now why iniparse seems to remove those empty lines.
inip...@googlecode.com
Comment #11 on issue 22 by psobe...@gmail.com: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
Older versions of Python didn't handle empty lines in multi-line values
properly. I made iniparse behave identically. If the bugs have been
fixed, it probably makes sense to fix iniparse's behavior too.
inip...@googlecode.com
Comment #12 on issue 22 by dewayneneal94: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
Look like work good I like see
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
inip...@googlecode.com
Comment #13 on issue 22 by slavek.k...@gmail.com: Adaptation to python 3
http://code.google.com/p/iniparse/issues/detail?id=22
Hi guys, in case you're interested, I made a patch that supports both
Python 2 and 3 using python-six. Attaching.
Attachments:
iniparse-python-3-with-six.patch 16.0 KB