[Xapian-tickets] [Xapian] #346: Python 3 support

[Xapian]

#346: Python 3 support
--------------------------------------+-------------------------------------
 Reporter:  olly                      |       Owner:  richard  
     Type:  defect                    |      Status:  assigned 
 Priority:  highest                   |   Milestone:  1.3.2    
Component:  Xapian-bindings (Python)  |     Version:  SVN trunk
 Severity:  normal                    |    Keywords:           
Blockedby:                            |    Platform:  All      
 Blocking:                            |  
--------------------------------------+-------------------------------------

Comment(by barry):

 Replying to [comment:40 olly]:

 > So simply mapping std::string to/from bytes in Python is probably the
 closest to that model, but I think that wouldn't seem very comfortable to
 use.

 So, here's a plan: start with that naive mapping, and get some real-world
 experience (e.g. software-center) at what the pain points are.  I think
 until we put a stake in the ground and see how easy or hard it is to use,
 we won't have a great sense about how to make it better.  I can work with
 the s-c maintainers to adopt this interim API and adjust it as 1.3.x makes
 any future changes to its Python 3 support.

 > If we're changing 1.2.x to add Python 3 support, I'd rather be
 conservative and minimise the risks that we break Python 2 support, so
 simply splitting the two directories seems a sane approach, and avoids
 needing to consider whether to raise the minimum Python 2 version
 supported in the middle of a release series.  It's unhelpful if we force
 users to upgrade Python just to be able to upgrade to a Xapian point
 release.
 >
 > For 1.3.x, 2.6 seems a reasonable minimum requirement, especially as 1.4
 is probably at least 6 months away.  I'd prefer to solicit feedback on the
 mailing list before finalising the versions of the various languages we're
 aiming to support in 1.4, but I can't see this being controversial.

 Sounds good.

 > The context managers approach doesn't handle a case where you want to
 pass one string argument as utf-8 and the other as bytes well - you might
 want to do that when setting user metadata, for example key as utf-8,
 value as bytes.

 Good point.

 > Using something based on 1.3.x is probably a reasonable approach for
 software-centre in 12.10, provided it's made clear that the API is likely
 to change, so we don't end up with lots of other packages depending on it
 (or at least if we do, they have been warned).  1.3.x should be pretty
 stable for a "development branch" - mostly there are no ABI compatibility
 promises, and some API features are marked as experimental.  Our record is
 good so far - almost all bugs in the development branches have either been
 in new code or also present in the previous release series.  It would also
 be good to see a significant piece of real software using the Python 3
 API.
 >
 > I'd say the first step there is to get it all working but always
 returning bytes for std::string.  That should give you something usable,
 and close enough to the final API that updating shouldn't be painful.

 So looking at the git/svn head, it's the Xapian 1.3.x development branch.
 One option would be to create a separate xapian-bindings/python3 directory
 which would *only* be for Python 3.  On the plus side, we could drop
 Python 2 support there and not worry about minimum versions.  It will also
 be easier to develop and maintain if we only have to worry about the
 Python 3 API.  The downside of course is that bugs affecting either
 binding will have to be fixed twice.  I'm not sure which is better -
 opinions?

-- 
Ticket URL: <http://trac.xapian.org/ticket/346#comment:41>
Xapian <http://xapian.org/>
Xapian