On Thursday November 15 2007 10:05:57 pm Andi Vajda wrote:
> Agreed. If you send me a patch to the README, I'll apply it.
Woohoo! a patch I can finally write. Attached. ;)
> Yes, that's part of the complications. parseArgs() would have to be told
> about the existence of overloads, some of which could be inherited, of
> course...
Sounds stressful.
> > Again, I'll deal if necessary, but I suspect this going to bite others as
> > well. Debugging would be easier if lucene.InvalidArgsError contained
> > more info about which arg was invalid...
>
> Good point, some of that information is readily available. I should forward
> it to the error.
I'm not sure what's available, but the more info the better... Something along
the lines of "Got int expected long for arg x" would be great... I realize
there are a lot of ways to pass invalid args and it's probably easier to
detect the problem than write human-readable error messages (silly humans).
Thanks.
--
Peter Fein || 773-575-0694 || [EMAIL PROTECTED]
http://www.pobox.com/~pfein/ || PGP: 0xCCF6AE6B
irc: [EMAIL PROTECTED] || jabber: [EMAIL PROTECTED]
Index: PyLucene/README
===================================================================
--- PyLucene/README (revision 361)
+++ PyLucene/README (working copy)
@@ -48,6 +48,11 @@
hand-crafted, giving it a module name identical to the original felt
like the right thing to do.
+ - There are several functions where PyLucene formerly accepted a Python
+ int, but the underlying Java code expected a long. Such casts must be
+ done explicitly now, using long(). Failure to do so will raise a
+ InvalidArgsError.
+
- Berkeley DB support is dropped. It is simpler and easier to implement
it in Python directly via a Python implementation of the classes in
org.apache.lucene.store. For an example, please refer to
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
