The script must have thought about it somehow :-) Have a great,
undisturbed vacation!
roman
On Thu, Jul 19, 2012 at 9:33 AM, Andi Vajda wrote:
>
> On Fri, 13 Jul 2012, Roman Chyla wrote:
>
>> Hi,
>> I was playing with the idea of creating virtual packages, attached is a
>> working script that illustrates it. I am getting this output:
>>
>> Dit it work?
>
>
> No, I haven't forgotten, I'm just on vacation.
>
> Andi..
>
>
>> ==
>> from org.apache.lucene.search import SearcherFactory; print
>> SearcherFactory
>>
>> from org.apache.lucene.analysis import Analyzer as Banalyzer; print
>> Banalyzer
>>
>> print sys.modules['org']
>> print sys.modules['org.apache']
>> print sys.modules['org.apache.lucene'] > (built-in)>
>> print sys.modules['org.apache.lucene.search'] > 'org.apache.lucene.search' (built-in)>
>>
>> Cheers,
>>
>> roman
>>
>>
>> On Fri, Jul 13, 2012 at 1:34 PM, Andi Vajda wrote:
>>
>>>
>>> On Jul 13, 2012, at 18:33, Roman Chyla wrote:
>>>
I think this would be great. Let me add little bit more to your
observations (whole night yesterday was spent fighting with renames -
because I was building a project which imports shared lucene and solr
--
there were thousands of same classes, I am not sure it would be possible
without some sort of a flexible rename...)
JCC is a great tool and is used by potentially many projects - so
>>>
>>> stripping
"org.apache" seems right for pylucene, but looks arbitrary otherwise
>>>
>>>
>>> Yes, I forgot to say that there would be a way to declare one or more
>>> mappings so that org.apache.lucene becomes lucene.
>>>
>>> Andi..
>>>
(unless there is a flexible stripping mechanism). Also, if the full
namespace remains original, then the code written in Python would be
also
executable by Jython, which is IMHO an advantage.
But this being Python, the packages cannot be spread in different
>>>
>>> locations
(ie. there can be only one org.apache.lucene.analysis package) - unless
there exists (again) some flexible mechanism which populates the
>>>
>>> namespace
with objects that belong there. It may seem an overkill to you, because
>>>
>>> for
single projects it would work, but seems perfectly justifiable in case
of
imported shared libraries
I don't know what is your idea for implementing the python packages, but
your last email got me thinking as well - there might be a very simple
>>>
>>> way
of getting to the java packages inside Python without too much work.
Let's say the java "org.apache.lucene.search.IndexSearcher" is known to
python as org_apache_lucene_search_IndexSearcher
and users do:
import lucene
lucene.initVM()
initVM() first initiates java VM (and populates the lucene namespace
with
all objects), but then it will call jcc.register_module(self)
A new piece of code inside JCC grabs the lucene module and creates (on
>>>
>>> the
fly) python packages -- using types.ModuleType (or new.module()) -- the
>>>
>>> new
packages will be inserted into sys.modules
so after lucene.initVM() returns
users can do "from org.apache.lucene.search import IndexSearcher" and
get
lucene.org_apache_lucene_search_IndexSearcher object
and also, when shared libraries are present (let's say 'solr') users do:
import solr
solr.initVM()
The JCC will just update the existing packages and create new ones if
needed (and from this perspective, having fully qualified name is safer
than to have lucene.search.IndexSearcher)
I think this change is totally possible and will not change the way how
extensions are built. Does it have some serious flaw?
I would be of course more than happy to contribute and test.
Best,
roman
On Fri, Jul 13, 2012 at 11:47 AM, Andi Vajda wrote:
>
> On Tue, 10 Jul 2012, Andi Vajda wrote:
>
> I would also like to propose a change, to allow for more flexible
>>>
>>> mechanism of generating Python class names. The patch doesn't change
>>> the default pylucene behaviour, but it gives people a way to replace
>>> class names with patterns. I have noticed that there are more
>>> same-name classes from different packages in the new lucene (and it
>>> becomes worse when one has to deal with both lucene and solr).
>>>
>>
>> Another way to fix this is to reproduce the namespace hierarchy used
>> in
>> Lucene, following along the Java packages, something I've been
>>>
>>> dreading to
>>
>> do. Lucene just loves a really long deeply nested class structure.
>> I'm not convinced yet it is bad enough to go down that route, though.
>>
>> Your proposal to use patterns may in fact yield a much more convenient
>> sol