On Fri, 9 Sep 2016, Dirk Rothe wrote:
Am 09.09.2016, 00:29 Uhr, schrieb Andi Vajda <va...@apache.org>:
On Thu, 8 Sep 2016, Dirk Rothe wrote:
Am 08.09.2016, 15:56 Uhr, schrieb Andi Vajda <va...@apache.org>:
On Thu, 8 Sep 2016, Dirk Rothe wrote:
I've made initReader() python-overridable (see patch). What do you
think?
Not sure what to think. While your change looks fine, if Lucene decided
to make this 'hard', it may be a sign that you're doing something wrong
or going the wrong way about it.
I suggest you ask on the java-u...@lucene.apache.org list as you're
probably not the first one to transition from 3.x to something more
recent.
Please let pylucene-dev@ know what you find out...
OK.
Making Analyzer.initReader() python-overridable is also important for
use-cases like this: http://stackoverflow.com/a/10290635
So the patch should be fine independently of my usage/hack.
Actually, your patch is not good enough. You need to add an implementation
for initReader() in all the tests that make a subclass of PythonAnalyzer
(search for createComponents() implementations) otherwise, when
initReader() gets called from Java, you'll get a stack overflow (it'd be
good, as an aside, if I could make a better error out of that...).
OK, I see the effect in samples/PorterStemmerAnalyzer.py (fixed some imports
there, use patch).
Shouldn't the need for implementation be optional? I don't understand.
Once you define a native method on a class, a native method implementation
must be provided. JCC does that but that native implementation just invokes
the python implementation on the python subclass instance. If that python
subclass has no method implementation, the inherited method is invoked
again, which in turn calls the native method again, and so on until the
stack overflows.
This could maybe be improved at the JCC level but until it is, a Python
implementation must be provided. The default initReader() method just
returns 'reader' and so should the python default implementation.
Andi..
--dirk
