Open GoogleCodeExporter opened 8 years ago
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
Original comment by psobe...@gmail.com
on 1 Jun 2010 at 3:37
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.
Original comment by robert.h...@gmail.com
on 1 Jun 2010 at 5:04
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.
Original comment by tim.lauridsen
on 1 Jun 2010 at 5:23
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.
Original comment by psobe...@gmail.com
on 2 Jun 2010 at 2:19
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.
Original comment by psobe...@gmail.com
on 2 Jun 2010 at 2:43
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.
Original comment by robert.h...@gmail.com
on 2 Jun 2010 at 6:45
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
Original comment by tim.lauridsen
on 5 Jun 2010 at 5:49
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
Original comment by robert.h...@gmail.com
on 5 Jun 2010 at 1:08
Attachments:
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)
Original comment by klaussfr...@gmail.com
on 31 May 2012 at 5:48
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.
Original comment by robert.h...@gmail.com
on 4 Jun 2012 at 7:52
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.
Original comment by psobe...@gmail.com
on 17 Jun 2012 at 12:55
Look like work good I like see
Original comment by dewayneneal94
on 13 Mar 2013 at 11:12
Hi guys, in case you're interested, I made a patch that supports both Python 2
and 3 using python-six. Attaching.
Original comment by slavek.k...@gmail.com
on 23 Sep 2013 at 9:55
Attachments:
Original issue reported on code.google.com by
robert.h...@gmail.com
on 26 May 2010 at 1:04Attachments: