> ...
> I realize that PyLucene doesn't make that easy because it doesn't warn
> about deprecated API use.
>
[Thomas Koch] Well this is a general drawback in Python as interpreted
language I guess - wrong interfaces are only detected at runtime and are
thus harder to test (unless you describe the interfaces and use tools such
as pylint...)
I wouldn't expect PyLucene to provide direct support here.
> One thing I could add to JCC is a command line flag to _not_ wrap any
> deprecated APIs. With that applied to PyLucene, one could then find all
> errors they'd be hitting when upgrading to 3.x. That being said, I don't
> see
> the difference between this and just upgrading to 3.x and looking for
> the
> very same errors since, by definition, 3.0 == 2.9 - deprecations. This
> explains why I haven't implemented this feature so far.
>
> Andi..
>
[Thomas Koch] Thanks for the explanation - that makes it more clear to me
now.
The question remains if it's feasible to support 2.x *and* 3.x - as Bill
mentioned "... I'd like to make it work on both." - me too. I did fear that
this makes things much more complicated and you end up with code "if
lucene.VERSION.split('.')[0]>2: ... else ..." - we did that some time ago
during GCJ and JCC based versions of PyLucene, but at that time it was
merely a matter of different imports and init stuff (initVM).
But I understand now that as long as you remove deprecated code from 2.9 it
*should* work with 2.9 and 3.0 as well! Right?
e.g.
<method>Hits search(Query query)
Is now deprecated as
"Hits will be removed in Lucene 3.0"
2.9 already supports
<method>TopDocs search(Query, Filter, int)
Which one should use instead.
The problem here is that - as far as I understand - you can make it work
with 2.9 and 3.0 - but then you loose backward compatibility with any 2.x
version before 2.9.... The point is that you may then end up forcing your
users (admins) to install a newer version of PyLucene - which people may not
want to do...
Regards
Thomas
