Closed GoogleCodeExporter closed 9 years ago
Issue 151 has been merged into this issue.
Original comment by djc.ochtman
on 19 Sep 2010 at 12:59
Well, okay, but the result of that patch isn't compatible with Python 2. There
are two solutions here: have a hybrid codebase that supports Python 2.4-3.2 and
everything in between (except 3.0, if that helps), or have a setup.py that can
do 2to3 stuff.
In any case, the first step here is to identify things that can be fixed in our
codebase that will work in 2.4 and 3.2 at the same time (such as replacing
filter by a listcomp and list(dict.iteritems()) instead of dict.items()). I'm
not sure where the instanceof(x, basestring) idiom falls, that can be a bit
tricky.
In general, kxepal, I love that you work so hard on fixing things, but it would
be supremely helpful if you publish a series of small patches instead of
putting big patches in issues, because a series of small patches is often much
easier to review than one big patch. I suggest you take a look at Mercurial's
mq extension to help manage the series.
Original comment by djc.ochtman
on 19 Sep 2010 at 1:04
Original comment by djc.ochtman
on 19 Sep 2010 at 1:16
Just 2to3 script run doesn't solving all problems. There also a little work for
correct bytes/string handling and others: http import package, getting slices
from ListField and etc. I could split it for little patches, no problem, but
they are will be only useful together, not one by one.
I support that there may be separate branch for just python 3+ and parallel
development for py2 and py3 branches.
However, there is very useful decorator from my ViewServer patch
http://code.google.com/p/couchdb-python/issues/attachmentText?id=146&aid=-777434
6187731936696&name=util.py&token=92bf191ff152b27d715148c77ecddaed
I've used it to have full-wide support for multiply couchdb servers while each
one has it own specific protocol, but with a little changes it could also be
used to split programming logic for different python version, so there will no
needs in separate distribution. One general drawback of this solution - a
little unoblivious code due to there is one common function and a lot of
version specific ones. But thats just idea(:
Original comment by kxepal
on 19 Sep 2010 at 1:19
The problem here is the best way to maintain both the 2 and the 3 version at
the same time. I don't think having separate branches is the best solution for
that. There are two solutions that are better:
- support all Pythons from the exact same codebase (kind of a pain, especially
while still supporting 2.4)
- make the codebase 2to3 safe so that python3 setup.py installs a 2to3-ified
version (several other projects are doing this, too, there should be support in
setuptools)
Original comment by djc.ochtman
on 19 Sep 2010 at 2:55
> make the codebase 2to3 safe so that python3 setup.py installs a 2to3-ified
version
>(several other projects are doing this, too, there should be support in
setuptools)
Interesting idea...I'm not sure in success with using only 2to3 tool, but I'll
try this way. However, some blocks of code will looks very weird(:
Original comment by kxepal
on 19 Sep 2010 at 4:40
any progress?
Original comment by KevinZu...@gmail.com
on 27 Apr 2011 at 7:15
I have to finish issues #146 and #166 before because they are required less
time that this one for now. However, modification of 2to3 tool is good idea,
but this modifications would be very couchdb-python specific due to module
names at least.
Original comment by kxepal
on 27 Apr 2011 at 7:46
https://github.com/lilydjwg/couchdb-python3
Original comment by lapcc...@gmail.com
on 13 May 2012 at 12:41
Can you release this Py3 compatible version please?
Original comment by hubscher.remy
on 4 Jan 2014 at 4:55
Not sure that this is good idea. It 1) a bit outdated 2) breaks 2.x
compatibility. See issue #231 for more recent patch set.
Original comment by kxepal
on 4 Jan 2014 at 5:00
Merging this into issue 231, since that seems to have a better way forward.
Original comment by djc.ochtman
on 5 Jan 2014 at 10:01
I saw that it breaks python 2.x compatibility but there is couchdb-python3 in
its name.
For my use case it is working but yes, we definitly have to work on py3 support.
Original comment by hubscher.remy
on 7 Jan 2014 at 8:56
Original issue reported on code.google.com by
kxepal
on 19 Sep 2010 at 12:43Attachments: