Issue1398

I tried to run NLTK 0.99 on Jython 2.5 (final) expecting it to work
since nltk was compatible with cPython 2.5. I got the following errors
though (pointing to some missing zlib constants in Jython 2.5) .

>>> import nltk                                         
/home/raghavan/mystuff/nltk0.99/nltk-0.9.9/nltk/sem/__init__.py:24:
UserWarning:
nltk.sem.relextract and nltk.sem.chat80 modules not loaded (please
install sqlite3
library
  warnings.warn("nltk.sem.relextract and nltk.sem.chat80 modules not "
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/raghavan/mystuff/nltk0.99/nltk-0.9.9/nltk/__init__.py",
line 96, in
<module>
    import data
  File "/home/raghavan/mystuff/nltk0.99/nltk-0.9.9/nltk/data.py", line
44, in <module>
    from zlib import Z_SYNC_FLUSH
ImportError: cannot import name Z_SYNC_FLUSH

http://code.google.com/p/nltk/issues/detail?id=414&q=jython

Comments (from Frank Wierzbicki's Weblog -
https://www.blogger.com/comment.g?blogID=14276139&postID=1723495392311827770)


It looks like we are missing a few constants in zlib, I bet they are
either new since 2.2/2.3 and haven't been added or they are somehow
incompatible with Java's compression support (I'm not up on this stuff
at the moment)

Java's zip implementation doesn't support any partial flush modes like 
Z_SYNC_FLUSH (http://bugs.sun.com/bugdatabase/view_bug.do?
bug_id=4206909, http://bugs.sun.com/bugdatabase/view_bug.do?
bug_id=4255743), so we've disabled these modes and their associated 
flags. That way libs fail fast when trying to use it

However we should probably provide the flags for compatibility sake 
anyway. ntlk doesn't even seem to rely on this flush mode, it just 
references it because it subclasses gzip.GzipFile.flush which references 
it (as it's the default mode).

Our own GzipFile has a workaround for the lack of zlib.Z_SYNC_FLUSH, so 
supporting it would also rid us of that

Actually our flush() is going to eventually reject the unsupported mode 
anyway, which means if we added the flag it's just going to delay the 
error till later

I haven't been following this bug, but NLTK appear to have adopted a workaround for this problem.

http://code.google.com/p/nltk/issues/detail?id=414

http://code.google.com/p/nltk/source/detail?r=8507

NLTK fixed this issue 18 months ago.

http://code.google.com/p/nltk/source/diff?spec=svn8507&r=8507&format=side&path=/trunk/nltk/nltk/data.py