jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)

[Jython-dev] autoloading site.py

[Robert W. B. <rb...@di...>]

I just added a FAQ entry and had second thoughts about it's
accuracy...

The registry key python.path appends the value *before* it appends
sys.prefix/lib.  While appending to sys.path in autoloaded site.py happens
*after* sys.prefix/lib.

Q1- This is intended behavior? (I assumed so, just checking because there
isn't an obvious counterpart in CPython.  Both *.pth and site.py append
after sys.prefix/lib.)

Q2- Is the python.path key obsolete in the registry?  The lib does come
with Jython, and site.py is autoloaded- what more could people want?  


Note: a search:replace with JPython:Jython on the registry file would be
good- attached in case it saves any work (from 20001205 nightly CVS).

Thanks,

Robert

[Jython-dev] Default re module: sre or pre?

[<bc...@wo...>]

Hi,

We have two bugs regarding the parentheses counting in re for named
groups like (?P<name>). This situation works in the sre module, so I'm
not all that inclined to begin adding lots of code to re to handle it.

Should we switch to sre as the default re module for alpha-2 ?
I think we should; the feedback I got when sre was the default re in the
errata makes me confident that it is ready. The ORO matcher will still
be available with the name "pre" and as the "re" name by editing the
registry file.

The bugs:


http://sourceforge.net/bugs/?func=detailbug&bug_id=122852&group_id=12867

http://sourceforge.net/bugs/?func=detailbug&bug_id=122815&group_id=12867

regards,
finn

[Jython-dev] Shallow freeze.

[<bc...@wo...>]

Hi,

In the Demo/javaclasses/readme.txt it says that jythonc creates a
shallow frozen java class where the actual python module is still loaded
and used:

2. run "jythonc -package pygraph Graph.py" in this directory

   This should produce the Java class pygraph.Graph.  Because this is
   only a shallow freeze of the code in Graph.py, you can modify the
   actual Python code (and any libraries it depends on) without needed
   to perform the freeze process again.  You will need to repeat this
   freeze process any time you add new methods to the Graph class that
   override Java methods in its superclass.

That isn't the case at the moment. If we want to re-enable this feature,
it add an interesting situation to the discussion of whether "Graph" is
a module or a java class. (The example conveniently uses a package to
make the java class and module different).

regards,
finn

Re: [Jython-dev] work in progress notes

[<bc...@wo...>]

[Samuele]

>I'm working on the cache fix, as I wrote I would like to write different
>caches that are chosen depending on java 1.1/2 env
>and options from the config files.
>I have noticed that in general Options.setFromRegistry is called before the
>first PyJavaClass.lookup, which is good, but for example in the embedding
>case (e.g. SimpleEmbedded.java) when PythonInterpreter ctr is called without
>first issueing a
>Py.initialize, PyJavaClass.lookup is called before Options.setFromRegistry.

Yeah, the initialization is a little screwy. It probably didn't improve
when I made PySystemState subclass PyObject. 

>Should we state that Py.initialize should be issued before using any other
>part of runtime. 

I think that is acceptable if we enforce it in the code. If the
PySystemState.initialize() call is moved to the top the
PythonInterpreter(d, s) method we satisfy the requirement for the usual
cases. The remaining situations are where the developer is creating a
PySystemState by hand before calling the PythonInterpreter ctor. That
must be rare.

The Py.initPython() call in PyJavaClass.lookup() should then be changed
to the functional equivalent of an assert:

 if (!PySystemState.initialized)
    throw new IllegalStateException("PySystemState.initialized() "+ 
                  "not called")


regards,
finn

RE: [Jython-dev] Map interface for PyDictionary...

[Steven M. <sr...@ya...>]

The Java2 Collections classes are available for use with java1.
Download at
http://java.sun.com/products/javabeans/infobus/index.html#COLLECTIONS

The package name has been changed to allow it to work within
java 1 browsers too.

Some care must be taken when using the package. For example, the
Comparator interface is NOT implemented by String in Java 1.
Therefore, Collections.sort(stringarray) will work in Java2 but
fail with Java1 and the retrofitted collections package.

[My opinion is that people should be using the Java Plug In to
run their apps. This is the only option with Netscape 6 and
Mozilla.]

best,
Steven Marcus


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: [Jython-dev] jython 2.0a1 binary

[<ba...@di...>]

>>>>> "TL" == Ted Leung <te...@en...> writes:

    TL> What happened to the Jython 2.0a1 binary?  The download page
    TL> from sourceforge say it isn't there?

Mailman lost it's 2.0 tarball too.  I wonder if SourceForge screwed up
in some way?

-Barry

[Jython-dev] jython 2.0a1 binary

[Leung, T. <te...@en...>]

Hi,

What happened to the Jython 2.0a1 binary?  The download page
from sourceforge say it isn't there?

Thanks,

Ted Leung

[Jython-dev] work in progress notes

[Samuele P. <pe...@in...>]

Hi.

[Finn]
> Update of /cvsroot/jython/jython/Tools/jythonc
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv28475
>
> Modified Files:
> compile.py SimpleCompiler.py
> Log Message:
> A small hack to fix bug 123627. This does not solve the dynamic
> issues with finding modules in __path__, but it works in the
> situations where the dotted package names matches the directory
> structure.
Very good. I don't think it makes very much sense too support the dynamic
__path__ values in jythonc,
in python it seems to me they are supposed to be set depending on something
only known at runtime.
To use their values at compilation time seems not so much useful.
I'm not sure of that: should not also SimpleCompiler._getnames be modified
to support pkg rel imports.

*****
I'm working on the cache fix, as I wrote I would like to write different
caches that are chosen depending on java 1.1/2 env
and options from the config files.
I have noticed that in general Options.setFromRegistry is called before the
first PyJavaClass.lookup, which is good, but for example in the embedding
case (e.g. SimpleEmbedded.java) when PythonInterpreter ctr is called without
first issueing a
Py.initialize, PyJavaClass.lookup is called before Options.setFromRegistry.
Should we state that Py.initialize should be issued before using any other
part of runtime. Or someone can propose
a workaround. I should be able to know the value of the newly introduced
cache options in PyJavaClass.lookup
in order to construct the right/requested kind of cache.
Hints are welcome.

regards, Samuele.

Re: [Jython-dev] Map interface for PyDictionary...

[<bc...@wo...>]

[Chris Knight]

>Needless to say, any possibility of using conditional compilation?  (I use
>CPP in my Java project for such a thing, any preprocessor would do.)

If the need emerge, we can look at that as a possibility. So far, the
dynamic Class.forName("<java2supportclass>") have worked nicely.

regards,
finn

RE: [Jython-dev] Map interface for PyDictionary...

[Chris K. <ck...@ma...>]

Finn Bock:
> This is my personal opinion, but as long the default JVM on windows is
> 1.1.4, I prefer to stay on that as the minimum requirement.

Unluckily, given Microsoft's goals with .NET and C#, I suspect IE will
always stick with Java 1.1.  (What better way to limit Java's acceptance
rate?)

Needless to say, any possibility of using conditional compilation?  (I use
CPP in my Java project for such a thing, any preprocessor would do.)

Re: [Jython-dev] Map interface for PyDictionary...

[<bc...@wo...>]

[Finn Bock]

> The real problem with this approach is java1 compatibility. It is an
> unmoving requirement that jython can be used in a java1 browser like IE.

[Robert W. Bill]

>This 'unmoving' part makes me curious.  I would like to
>hear more of the reasoning behind it.

This is my personal opinion, but as long the default JVM on windows is
1.1.4, I prefer to stay on that as the minimum requirement.

>The conditional sounds like:
>    1. We must support Java1 browsers, so 
>    2. we must support Java1 compatibility.
>
>This often repeated scenario assumes there's no other way to
>support these browsers, and there is no other reason
>given for Java1 compatibility.

The fact that you most likely can point your browser to

  http://jython.sourceforge.net/applets/index.html

and see a jython applet is IMHO such a valuable marketing point, that I
will loath to lose it.

>However:
>    1. Java2 plug-in is intended to support such browsers, and
>    2. it seems there must be other reasons involved in
>       choosing Java1 compatibility, so
>    3. both antecedent and consequent of the conditional
>       seem arbitrary and flimsy to me.
>
>Does the Java2 plug-in not work well?  

I'm sure it works perfectly. I don't make applets myself, so I'm not
familiar with the features and possible tradeoff with the java2 plug-in.

>Is there a legal
>implication to requiring the plug-in that bothers people?
>Are there essential tools other than browsers that lack 1.2
>drivers/support?  Are embedded or real-time-Java ventures
>working only with Java1?  Does Java1 compatibility increase
>chances of eventually working with alternative JVM's? 
>
>Without additional reasons, someone could propose:
>    *"The Java2 plug-in enables Java2 for most broswers"
>    *"Java1 compatibility is not essential for Java1 browsers
>      because of the Java2 plug-in"
>    *"Unless other valid reasons are proposed, using
>      Java2 with the plug-in is reasonable."
>
>I expected more of a discussion after last years conference.  
>See:
>http://www.python.org/pipermail/jpython-interest/2000-January/005222.html

Unfortunately, I was not attending the conference, so I don't know what
the discussion turned up.

Deciding that java2 is the requirement, would make certain things easier
for the jython-dev'ers, but would not gain anything usefull for the
users. We can still include java2 features in jython, it is just more
difficult to do so. 

I predict that I will remain unmoved, at least until there is a java2
feature that is impossible to implement without braking java1
compatibility. I have not yet seen such a feature.

PS. Please keep in mind that a java2 requirement isn't needed to improve
the support for java2 collections in jython. We can still do that, but
first there are some issues regarding the exact design of mutability
that must be finalized.

regards,
finn

Re: [Jython-dev] Access to Java protected members from a Jython subclass

[<bc...@wo...>]

[Jorge Mireles J.]

>How can I access Java protected (static) members from a Jython subclass?

The short answer: you can't. At least not without setting the registry
option python.security.respectJavaAccessibility to false.

It is difficult to add in a nice manner. The problem is a bit like this:

A normal (public) static method is from jython called on the parent java
class:
   javaclass.method()
Such a call does not originate from the subclass, but from internal
reflection code in jython. If we want to add support for calling
protected static methods from a jython subclass, the call will have to
originate from the subclass (ie. the proxy class), so we will have to
generate a referring method in subclass proxy like:

  public static void method() {
     javaclass.method()
  }

(with the right return type and throws clauses) and the jython subclass
will have to call the method on its own class, not the java class.

A little more though is needed before I charge in and start making
modifications. Where have you seen this? I might be more inclined to add
this if it occur for some well known library.

regards,
finn

[Jython-dev] FAQ wizard

[<bc...@wo...>]

Hi,

I moved the Jython FAQ to a faqwizard at:

   http://jython.sourceforge.net/cgi-bin/faqw.py?req=index

The password for adding new entries is "jython" (without the quotes). 

regards,
finn

Re: [Jython-dev] jython20a1 regression test from py2.0

[<bc...@wo...>]

[Ype Kingma]

>Hello Jythoners,
>
>First a  question just out of curiosity.
>Why was the 'p' dropped from the name JPython?

The JPython license forced us to find another name.

>Where has Monty's flying circus gone?
>
>Ok. A bit more serious now. I downloaded 20a1 and
>tried to run the regression tests from python 2.0.
>This worked to some extent after "adapting" the main program
>regrtest.py to some modules not available in java.

I did a diff between the CPython2.0 and your version of regrtest and it
seems to be the getopt module. But the getopt module is part of the
jython2.0a1 and is install along with core jython. At least it works for
me.

>Below is the summary of the test output.
>I suppose you have done sth. like this yourself.
>Still, would you be interested in more details?
>Does this make any sense? If so, can I suggest to
>include the regression test in the distribution of Jython?
>
>
>The details (terse):
>
>Slightly modified regrtest.py from python2.0 Lib/test
>running under jython20a1 running under Blackdown java 1.2.2 for powerpc
>with 60Mb of memory (the vm fails with a segfault at the default 30Mb
>during a finalize, so I concluded the garbage collector is not yet
>completely sane.)
>All this running under Suse Linux 6.4 (kernel 2.2.14 with some additions).
>
>I copied the files from python2.0/Lib/test/*.py to a separate directory
>and ran jython regrtest.py. The output ends ao. with the following:
>
>16 tests OK.
>11 tests failed:
>test_opcodes
>test_operations
>test_StringIO

This we can fix.

>test_class
>test_format

We can fix test_format.

>test_longexp
>test_pow

We can fix test_pow.

>test_socked
>test_ucn

We can fix test_ucn.

>test_unicode

test_unicode already works but there are some acceptable differences in
the output.

>test_unicodedata

There will always be difference here because CPython is using
Unicode-3.0 and Java is using Unicode-2.x

regards,
finn

[Jython-dev] Access to Java protected members from a Jython subclass

[Jorge M. J. <jmi...@se...>]

How can I access Java protected (static) members from a Jython subclass?
Thanks in advance...

[Jython-dev] jython20a1 regression test from py2.0

[Ype K. <yk...@xs...>]

Hello Jythoners,

First a  question just out of curiosity.
Why was the 'p' dropped from the name JPython?
Where has Monty's flying circus gone?

Ok. A bit more serious now. I downloaded 20a1 and
tried to run the regression tests from python 2.0.
This worked to some extent after "adapting" the main program
regrtest.py to some modules not available in java.
Below is the summary of the test output.
I suppose you have done sth. like this yourself.
Still, would you be interested in more details?
Does this make any sense? If so, can I suggest to
include the regression test in the distribution of Jython?


The details (terse):

Slightly modified regrtest.py from python2.0 Lib/test
running under jython20a1 running under Blackdown java 1.2.2 for powerpc
with 60Mb of memory (the vm fails with a segfault at the default 30Mb
during a finalize, so I concluded the garbage collector is not yet
completely sane.)
All this running under Suse Linux 6.4 (kernel 2.2.14 with some additions).

I copied the files from python2.0/Lib/test/*.py to a separate directory
and ran jython regrtest.py. The output ends ao. with the following:

16 tests OK.
11 tests failed:
test_opcodes
test_operations
test_StringIO
test_class
test_format
test_longexp
test_pow
test_socked
test_ucn
test_unicode
test_unicodedata
80 tests skipped


The failing test_opcodes and test_class are not surprising, the fact that
they were not skipped is puzzling me. I have not read into the details.


Kind regards,
Ype

P.S. I had to manually patch the indentation of the modified parts a bit,
probably because of my tab setting (4) in vi. I hope I got it all right,
it might fail the syntax checker now.


Here is the modified regrtest.py:
(I should learn how to use diff and just send the patch, just a
handful of changes were needed.)


#! /usr/bin/env python

"""Regression test.

This will find all modules whose name is "test_*" in the test
directory, and run them.  Various command line options provide
additional facilities.

Command line options:

-v: verbose   -- run tests in verbose mode with output to stdout
-q: quiet     -- don't print anything except if a test fails
-g: generate  -- write the output file for a test instead of comparing it
-x: exclude   -- arguments are tests to *exclude*
-s: single    -- run only a single test (see below)
-r: random    -- randomize test execution order
-l: findleaks -- if GC is available detect tests that leak memory
--have-resources   -- run tests that require large resources (time/space)

If non-option arguments are present, they are names for tests to run,
unless -x is given, in which case they are names for tests not to run.
If no test names are given, all tests are run.

-v is incompatible with -g and does not compare test output files.

-s means to run only a single test and exit.  This is useful when Purifying
the Python interpreter.  The file /tmp/pynexttest is read to find the next
test to run.  If this file is missing, the first test_*.py file in testdir or
on the command line is used.  (actually tempfile.gettempdir() is used instead
of /tmp).


27 Nov 2000 YK: try and adapt this for jython20a1:
- worked around module getopt, not available in jython20a1
- idem modules traceback, random

"""

import sys
import string
import os

try:
     import getopt
     getoptavailable = 1
except:
     getoptavailable = 0

# import traceback
# import random

import test_support

def main(tests=None, testdir=None, verbose=0, quiet=0, generate=0,
          exclude=0, single=0, randomize=0, findleaks=0,
          use_large_resources=0):
     """Execute a test suite.

     This also parses command-line options and modifies its behavior
     accordingly.

     tests -- a list of strings containing test names (optional)
     testdir -- the directory in which to look for tests (optional)

     Users other than the Python test suite will certainly want to
     specify testdir; if it's omitted, the directory containing the
     Python test suite is searched for.

     If the tests argument is omitted, the tests listed on the
     command-line will be used.  If that's empty, too, then all *.py
     files beginning with test_ will be used.

     The other seven default arguments (verbose, quiet, generate, exclude,
     single, randomize, and findleaks) allow programmers calling main()
     directly to set the values that would normally be set by flags on the
     command line.

     """

   if getoptavailable:
	try:
	    opts, args = getopt.getopt(sys.argv[1:], 'vgqxsrl', 
['have-resources'])
	except getopt.error, msg:
	    print msg
	    print __doc__
	    return 2
	for o, a in opts:
	    if o == '-v': verbose = verbose+1
	    if o == '-q': quiet = 1; verbose = 0
	    if o == '-g': generate = 1
	    if o == '-x': exclude = 1
	    if o == '-s': single = 1
	    if o == '-r': randomize = 1
	    if o == '-l': findleaks = 1
	    if o == '--have-resources': use_large_resources = 1
	if generate and verbose:
	    print "-g and -v don't go together!"
	    return 2
     else: # YK, for jython20a1:
         verbose = 1
	    args = []

     good = []
     bad = []
     skipped = []

     if findleaks:
         try:
             import gc
         except ImportError:
             print 'No GC available, disabling findleaks.'
             findleaks = 0
         else:
             # Uncomment the line below to report garbage that is not
             # freeable by reference counting alone.  By default only
             # garbage that is not collectable by the GC is reported.
             #gc.set_debug(gc.DEBUG_SAVEALL)
             found_garbage = []

     if single:
         from tempfile import gettempdir
         filename = os.path.join(gettempdir(), 'pynexttest')
         try:
             fp = open(filename, 'r')
             next = string.strip(fp.read())
             tests = [next]
             fp.close()
         except IOError:
             pass
     for i in range(len(args)):
         # Strip trailing ".py" from arguments
         if args[i][-3:] == '.py':
             args[i] = args[i][:-3]
     stdtests = STDTESTS[:]
     nottests = NOTTESTS[:]
     if exclude:
         for arg in args:
             if arg in stdtests:
                 stdtests.remove(arg)
         nottests[:0] = args
         args = []
     tests = tests or args or findtests(testdir, stdtests, nottests)
     if single:
         tests = tests[:1]
     if randomize:
         random.shuffle(tests)
     test_support.verbose = verbose      # Tell tests to be moderately quiet
     test_support.use_large_resources = use_large_resources
     save_modules = sys.modules.keys()
     for test in tests:
         if not quiet:
             print test
         ok = runtest(test, generate, verbose, quiet, testdir)
         if ok > 0:
             good.append(test)
         elif ok == 0:
             bad.append(test)
         else:
             skipped.append(test)
         if findleaks:
             gc.collect()
             if gc.garbage:
                 print "Warning: test created", len(gc.garbage),
                 print "uncollectable object(s)."
                 # move the uncollectable objects somewhere so we don't see
                 # them again
                 found_garbage.extend(gc.garbage)
                 del gc.garbage[:]
         # Unload the newly imported modules (best effort finalization)
         for module in sys.modules.keys():
             if module not in save_modules and module.startswith("test."):
                 test_support.unload(module)
     if good and not quiet:
         if not bad and not skipped and len(good) > 1:
             print "All",
         print count(len(good), "test"), "OK."
     if bad:
         print count(len(bad), "test"), "failed:",
         print string.join(bad)
     if skipped and not quiet:
         print count(len(skipped), "test"), "skipped:",
         print string.join(skipped)

     if single:
         alltests = findtests(testdir, stdtests, nottests)
         for i in range(len(alltests)):
             if tests[0] == alltests[i]:
                 if i == len(alltests) - 1:
                     os.unlink(filename)
                 else:
                     fp = open(filename, 'w')
                     fp.write(alltests[i+1] + '\n')
                     fp.close()
                 break
         else:
             os.unlink(filename)

     return len(bad) > 0

STDTESTS = [
     'test_grammar',
     'test_opcodes',
     'test_operations',
     'test_builtin',
     'test_exceptions',
     'test_types',
    ]

NOTTESTS = [
     'test_support',
     'test_b1',
     'test_b2',
     ]

def findtests(testdir=None, stdtests=STDTESTS, nottests=NOTTESTS):
     """Return a list of all applicable test modules."""
     if not testdir: testdir = findtestdir()
     names = os.listdir(testdir)
     tests = []
     for name in names:
         if name[:5] == "test_" and name[-3:] == ".py":
             modname = name[:-3]
             if modname not in stdtests and modname not in nottests:
                 tests.append(modname)
     tests.sort()
     return stdtests + tests

def runtest(test, generate, verbose, quiet, testdir = None):
     """Run a single test.
     test -- the name of the test
     generate -- if true, generate output, instead of running the test
     and comparing it to a previously created output file
     verbose -- if true, print more messages
     quiet -- if true, don't print 'skipped' messages (probably redundant)
     testdir -- test directory
     """
     test_support.unload(test)
     if not testdir: testdir = findtestdir()
     outputdir = os.path.join(testdir, "output")
     outputfile = os.path.join(outputdir, test)
     try:
         if generate:
             cfp = open(outputfile, "w")
         elif verbose:
             cfp = sys.stdout
         else:
             cfp = Compare(outputfile)
     except IOError:
         cfp = None
         print "Warning: can't open", outputfile
     try:
         save_stdout = sys.stdout
         try:
             if cfp:
                 sys.stdout = cfp
                 print test              # Output file starts with test name
             __import__(test, globals(), locals(), [])
             if cfp and not (generate or verbose):
                 cfp.close()
         finally:
             sys.stdout = save_stdout
     except (ImportError, test_support.TestSkipped), msg:
         if not quiet:
             print "test", test,
             print "skipped -- ", msg
         return -1
     except KeyboardInterrupt:
         raise
     except test_support.TestFailed, msg:
         print "test", test, "failed --", msg
         return 0
     except:
         type, value = sys.exc_info()[:2]
         print "test", test, "crashed --", str(type) + ":", value
         #if verbose: # 27 Nov 2000, YK
             #traceback.print_exc(file=sys.stdout)
         return 0
     else:
         return 1

def findtestdir():
     if __name__ == '__main__':
         file = sys.argv[0]
     else:
         file = __file__
     testdir = os.path.dirname(file) or os.curdir
     return testdir

def count(n, word):
     if n == 1:
         return "%d %s" % (n, word)
     else:
         return "%d %ss" % (n, word)

class Compare:

     def __init__(self, filename):
         self.fp = open(filename, 'r')

     def write(self, data):
         expected = self.fp.read(len(data))
         if data <> expected:
             raise test_support.TestFailed, \
                     'Writing: '+`data`+', expected: '+`expected`

     def writelines(self, listoflines):
         map(self.write, listoflines)

     def flush(self):
         pass

     def close(self):
         leftover = self.fp.read()
         if leftover:
             raise test_support.TestFailed, 'Unread: '+`leftover`
         self.fp.close()

     def isatty(self):
         return 0

if __name__ == '__main__':
     sys.exit(main())

Re: [Jython-dev] Map interface for PyDictionary...

[Robert W. B. <rb...@di...>]

[On Tue, 28 Nov 2000, Finn Bock wrote:]
> The real problem with this approach is java1 compatibility. It is an
> unmoving requirement that jython can be used in a java1 browser like IE.

This 'unmoving' part makes me curious.  I would like to
hear more of the reasoning behind it.

The conditional sounds like:
    1. We must support Java1 browsers, so 
    2. we must support Java1 compatibility.

This often repeated scenario assumes there's no other way to
support these browsers, and there is no other reason
given for Java1 compatibility.

However:
    1. Java2 plug-in is intended to support such browsers, and
    2. it seems there must be other reasons involved in
       choosing Java1 compatibility, so
    3. both antecedent and consequent of the conditional
       seem arbitrary and flimsy to me.

Does the Java2 plug-in not work well?  Is there a legal
implication to requiring the plug-in that bothers people?
Are there essential tools other than browsers that lack 1.2
drivers/support?  Are embedded or real-time-Java ventures
working only with Java1?  Does Java1 compatibility increase
chances of eventually working with alternative JVM's? 

Without additional reasons, someone could propose:
    *"The Java2 plug-in enables Java2 for most broswers"
    *"Java1 compatibility is not essential for Java1 browsers
      because of the Java2 plug-in"
    *"Unless other valid reasons are proposed, using
      Java2 with the plug-in is reasonable."

I expected more of a discussion after last years conference.  
See:
http://www.python.org/pipermail/jpython-interest/2000-January/005222.html

This is just sincere curiosity- not a proposal, and I look
forward to hearing comments.

-Robert

RE: [Jython-dev] Map interface for PyDictionary and List interface for PyList? Also, cgi.FieldStorage and Cookie.SimpleCookie Java classes...

[Chris K. <ck...@ma...>]

Finn Bock:
> >All, I would like to use PyLists and PyDictionaries
> interchangably between
> >Java and Jython.
>
> The real problem with this approach is java1 compatibility. It is an
> unmoving requirement that jython can be used in a java1 browser like IE.
> So all uses of java2 features must be wrapped in a separate class. See
> CollectionProxy2.java and Java2Accessibility.java for example on how
> this can be done.

Gah, you're correct...My biggest problem is I'm constructing Py classes in
Java and sometimes wanting to pass them to Python and sometimes wanting to
pass them to other Java methods that are expecting Maps or Lists.
(Actually, I wonder if the Map and Collection interfaces would compile in
Java 1.1?  They're fairly simplistic.  I don't really need the functionality
in 1.1 but I don't want to break Jython.)

> >Also, one other thing of note:  I've been trying to execute CGI scripts
> >under the Servlet architecture without having to make code mods to the
> >Python script (or at least making minimal changes.)  As such, I've
> >implemented a cgi.FieldStorage class in Java that acts like the CPython
> >equivalent, as well as a Java class equivalent for Cookie.SimpleCookie.
>
> Couldn't these classes also be created as python modules?

Eh, I went that route for a while and found it to be a pain in the arse, in
particular, when you need to send the cookie information back to the client,
you'd have to traverse through the Jython objects, calling methods along the
way to properly format the cookie data.  (It's not just a matter of doing
"str(cookies)", since they have to be mapped into the addCookie() method.)
I also ran into some weird incompatability problems with the SmartCookie
classes, since JPython mis-identified an e-mail address cookie as a
serialized object and tried to deserialize it.

Re: [Jython-dev] synchronized methods

[<bc...@wo...>]

[Jorge Mireles J.]

>How can I overload a Java synchronized method in order it mantains
>synchronized in jython? I'm using the class Thread for creations of
>threads. There are more options?
>Thanks...

I found these examples in the archives:


http://www.python.org/pipermail/jpython-interest/1999-January/003673.html

http://www.python.org/pipermail/jpython-interest/1999-March/004076.html

regards,
finn

Re: [Jython-dev] Map interface for PyDictionary and List interface for PyList? Also, cgi.FieldStorage and Cookie.SimpleCookie Java classes...

[<bc...@wo...>]

On Mon, 27 Nov 2000 18:07:45 -0800, you wrote:

>All, I would like to use PyLists and PyDictionaries interchangably between
>Java and Jython.

Me too. So would JimH a long time ago (item #2):


http://www.python.org/pipermail/jpython-interest/1998-October/003270.html


The seconds half of this item is already in place, but the first "This
will both allow JPython collections to be easily used from Java" is not.

>I thought of subclassing PyDictionary and implementing the
>Map interface, but there's a name collision with the "values()" method (as
>PyDictionary returns a PyList.  Friggin' Java and it's lack of return type
>overloading.)
>
>Needless to say, I thought of one other way, modify the PyList and
>PyDictionary classes so that they implement the above-mentioned interfaces.
>Given that they use Java classes under the hood that do support these
>interfaces, these methods would simply be a pass-through to the protected
>object's methods by the same name.
>
>Additionally, given that PyLists would (indirectly) implement the Collection
>interface, the values() method would make both Jython and Java happy.

It is not that simple, but it can be done. Python must use a different
version of values() than the one java is seeing. That can be done in 
PyDictionary.classDictInit where the "values" entry already are
exchanged with a high performence version.

The real problem with this approach is java1 compatibility. It is an
unmoving requirement that jython can be used in a java1 browser like IE.
So all uses of java2 features must be wrapped in a separate class. See
CollectionProxy2.java and Java2Accessibility.java for example on how
this can be done.

A possible alternative to implementing Map & Collection, could be to
extend the __tojava__() behaviour of PyList and PyDictionary. For
PyDictionary:

    public Object __tojava__(Class c) {
        if (java.util.Map.class.isAssignableFrom(c))
	    return table;
        return super.__tojava__(c);
    }

but where the actual test is moved into a separate and dynamicly loaded
class. Things get trickier for PyList & PyStringMap because they doesn't
already have a class that implements Collection or Map. If we want to
maintain the mutability of these collections, the returned object from
__tojava__ must be able to modify the original collection.

If we make such changes we can then pass python lists and dicts to java
methods:

from java.util import LinkedList, HashMap
print LinkedList([1,2,3,4])
print HashMap({ 'a':1, 'b':2 })

but I'm not sure that is what most people will expect. Take a look at
the utility functions from "Thinking in Patterns with Java"
 
   http://www.mindview.net/TIPatterns/

There is a method that converts a dict to a map:

  public static Map 
  toMap(PythonInterpreter interp, String pyName){
    PyList pa = ((PyDictionary)interp.get(pyName)).items();
    Map map = new HashMap();
    while(pa.__len__() != 0) {
      PyTuple po = (PyTuple)pa.pop();
      Object first = po.__finditem__(0).__tojava__(Object.class);
      Object second = po.__finditem__(1).__tojava__(Object.class);
      map.put(first, second);
    }
    return map;
  }

The interesting thing is the __tojava__(Object.class) on both key and
values. That will unwrap the python wrapper and make the Map must more
usefull in java IMO. But that will break all attempts to maintain
mutability. Any modification that is done on the java Map or List does
no longer show up in python dict or list.

All in all, I don't think it is worth it to add direct support for java2
collections to python. I would rather see a utility module which had the
necessary functions to convert python collection into java collections:

import jcollection
print jcollection.LinkedList([1,2,3,4])
print jcollection.HashMap({ 'a':1, 'b':2 })

This conversion should then be done recursively.

>I can probably perform these changes and send a patch set out via
>e-mail...Interested?
>
>Also, one other thing of note:  I've been trying to execute CGI scripts
>under the Servlet architecture without having to make code mods to the
>Python script (or at least making minimal changes.)  As such, I've
>implemented a cgi.FieldStorage class in Java that acts like the CPython
>equivalent, as well as a Java class equivalent for Cookie.SimpleCookie.

Couldn't these classes also be created as python modules? 

>They're surely not fully-fleshed out and may have bugs but I would be quite
>happy to send the source out via e-mail or post them to an appropriate site.
>It might be worthwhile to include them as standard libraries once the bugs
>are all worked out and they're fully compatable with the CPython
>equivalents.

regards,
finn

[Jython-dev] Map interface for PyDictionary and List interface for PyList? Also, cgi.FieldStorage and Cookie.SimpleCookie Java classes...

[Chris K. <cla...@ca...>]

All, I would like to use PyLists and PyDictionaries interchangably between
Java and Jython.  I thought of subclassing PyDictionary and implementing the
Map interface, but there's a name collision with the "values()" method (as
PyDictionary returns a PyList.  Friggin' Java and it's lack of return type
overloading.)

Needless to say, I thought of one other way, modify the PyList and
PyDictionary classes so that they implement the above-mentioned interfaces.
Given that they use Java classes under the hood that do support these
interfaces, these methods would simply be a pass-through to the protected
object's methods by the same name.

Additionally, given that PyLists would (indirectly) implement the Collection
interface, the values() method would make both Jython and Java happy.

I can probably perform these changes and send a patch set out via
e-mail...Interested?

Also, one other thing of note:  I've been trying to execute CGI scripts
under the Servlet architecture without having to make code mods to the
Python script (or at least making minimal changes.)  As such, I've
implemented a cgi.FieldStorage class in Java that acts like the CPython
equivalent, as well as a Java class equivalent for Cookie.SimpleCookie.
They're surely not fully-fleshed out and may have bugs but I would be quite
happy to send the source out via e-mail or post them to an appropriate site.
It might be worthwhile to include them as standard libraries once the bugs
are all worked out and they're fully compatable with the CPython
equivalents.

[Jython-dev] synchronized methods

[Jorge M. J. <jmi...@se...>]

How can I overload a Java synchronized method in order it mantains
synchronized in jython? I'm using the class Thread for creations of
threads. There are more options?
Thanks...

[Jython-dev] ANN: First alpha release of Jython-2.0

[<bc...@wo...>]

Hello Jython and JPython users,

Jython-2.0alpha1 is finally available. This early access release is 
governed by a patchwork license where each of the different parts of
Jython are covered by their original license and the modifications done
be the Jython-developers are release under a BSD like license.

    http://jython.sourceforge.net/index.html

The free installer LiftOff is used to create the distribution. The 
jython-20a1.class must be executed as with JPython-1.1. The 
standard python modules are included in the installer. No further 
downloads are needed.

I don't intend to announce this any more widely than these lists for
now to keep the initial set of alpha testers relatively small.

News (off the top of my head, will improve later):

    - List comprehension.
    - Extended call syntax.
    - Extended print statement
    - Augmented assignment.
    - Unicode support libraries and codecs.
    - sre unicode regular expression.

Possible Problem Changes (but big wins in general):

    - Text files will pass data read and written through the default
      codecs for the JVM. Binary files will write only the lower eight
      bits of each unicode character.
    - The precedence of java loading have changed. Now the sys.path
      is searched for python modules before the CLASSPATH and sys.path
      is searched for java class and java packages.

Take a look at the NEWS file for more information about the differences.

    http://jython.sourceforge.net/NEWS.html

Bugs can be reported to the bug manager on SourceForge:

    http://sourceforge.net/bugs/?group_id=12867


Cheers,
the jython-developers

Re: [Jython-dev] cache design + ...

[<bc...@wo...>]

[Finn on how lazy and non-lazy loaded classes could be handled]

>... jpkg.Bean classes would not be interoperable, but
> lazily loaded class would work just like the ordinarily initialized
> classes.

[Samuele]

>Very good point, that was also my first design idea, then I found bad the loading 
>needed for the check, but up to performance is not that bad to load
>something that is somehow lazy loaded.
>Given the more complicated setup of load-sets (=> many classloaders) and if we want 
>lazy load also from them we will have to check a class against all possible
>lazy versions around.

Yes, that will make the implementation more complicated but still possible.

>And to deal with the case of lazy loading coming after the creation of
>a PyJavaClass from a true class. We will have to find all the classes
>with that name, and if this set is not empty we will have to force loading
>and do the checks also in this case.

Yes. I had forgotten that situation.

>So the principle: if there is a possible ambiguity around, we should force
>loading of lazy loaded stuff with the involved name and check.

Right. And I not concerned about the performance in this situation at all.

>> I agree with all of this. I'm unsure how we should maintain this list.
>> The CPython people have their PEP-0042 for this. 
>My suggestion (given the not so formal settings of jython development) is to
>create something like a moinmoin site, like the new Python2.0 Info Area,
>that's will be a good place for the FAQ because anyone can contribute
>and developers can if the case improve, rewrite not totally correct answers,
>and for feature requests and for keeping track of design discussions.
>That's just a suggestion.

I'll look into it. Thanks.

>Some of my proposal are clearly not small features: about that I can only say:
>* jythonc things are quite interesting, given the time and when more important things
>are solved I can try to do something, but the sematics question should be solved
>before.
>* for imputil/ihooks (personally I should first read both codes) maybe we should
> join import-sig and try to be helpful, or at least to clarify jython needs.
>* rexec/security architecture is really *hard*:
> e.g. java1.1 and java2 are different in that respect,
> and we should exploit seriously the java security arch otherwise
> any security effort/statement will be vague.

I'll look at this later. (I'm trying to focus on 20a1 for now)

regards,
finn

Re: [Jython-dev] cache design + ...

[Samuele P. <pe...@in...>]

Hi.

[Finn]
> Let us for a moment say that we disable lazy loading. Each class in the
> class list will then be resolved (through Py.findClassEx I think) into a
> Class instance and the PyJavaClass will be complete including the link
> from Class to PyJavaClass in PyJavaClass.classes.
> 
> When we in this theoretical senary receive the inst0 instance from the
> java side its class either match an entry in PyJavaClass.classes and if
> it does not match, we create a new entry with inst.getClass() as key.
> 
> So, lets add lazy loading. We now have an PyJavaClass.classes dict that
> looks something like this:
> 
>   {
>      org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
>      "jpkg.Bean" : PyJavaClass(null),
>   }
> 
> meaning that the PyJavaClass is fully initialized with its .class as key
> and that jpkg.Bean is lazily loaded and uninitialized with the string
> "jpkg.Bean" as key.
> 
> When we get a java instance inst0 from the java side we first check for
> a lazy entry. We find jpkg.Bean which is then resolved using the same
> classloaders setup as if the class was not lazy loaded. When the
> PyjavaClass is initialized the lazy entry is removed and the dict looks
> like this:
> 
>   {
>      org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
>      jpkg.Bean.class@2 : PyJavaClass(jpkg.Bean.class@2),
>   }
> 
> Now the inst0.getClass() is searched in the dict. If it happens to be
> the same as jpkg.Bean.class@2, the newly initialized PyJavaClass is
> returned. If it isn't, a new entry is added.
> 
>   {
>      org.python.core.PyJavaClass.class : PyJavaClass(PyJavaClass@1),
>      jpkg.Bean.class@2 : PyJavaClass(jpkg.Bean.class@2),
>      jpkg.Bean.class@3 : PyJavaClass(jpkg.Bean.class@3),
>   }
> 
> This last dictionary would match the situation where we had disabled
> lazy loading. The two jpkg.Bean classes would not be interoperable, but
> lazily loaded class would work just like the ordinarily initialized
> classes.
> 
> I still don't have a deep and intuitive understanding of the issues, so
> there is likely something I have forgotten.
Very good point, that was also my first design idea, then I found bad the loading 
needed for the check, but up to performance is not that bad to load
something that is somehow lazy loaded.
Given the more complicated setup of load-sets (=> many classloaders) and if we want 
lazy load also from them we will have to check a class against all possible
lazy versions around.
And to deal with the case of lazy loading coming after the creation of
a PyJavaClass from a true class. We will have to find all the classes
with that name, and if this set is not empty we will have to force loading
and do the checks also in this case.
So the principle: if there is a possible ambiguity around, we should force
loading of lazy loaded stuff with the involved name and check.

> >(2) I think it would be great to have both unloading support (meaning
> >...
> 
> Cool.
 
> >(3) For reloading also MakeProxies.makeClass should be changed:
> >...
> Right.

> >  Maybe it is better to distinguish between a class implementing sys.path
> >loading and a class for dynamic
> >  loading of discardable code. Actually BytecodeLoader does both things.
> 
> Yes, that would be goodness. Much confusion in the past have its roots
> in this double duty.

And I will start working seriously on all that.

 
> >[Finn]
> >> >And with such
> >> >a patch it should be possible to produce an experimental version
> >> >of reloading support (in form of a python module using __import__ hook).
> >>
> >> Good. I would like to get broader feedback on the reloading issues, so
> >> maybe some version of java reloading can go into 2.0-final marked as
> >> experimental. I would also like Guido's view on how pythonic he consider
> >> our java reload support to be.
> >Hope that our best is enough ;), in any case if we should keep our reload
> >support
> >separate from runtime (because it is not enough pythonic) we will encouter
> >the need
> >of some ihooks/imputil-like support and suffer the destiny of import-sig,
> >which has mostly ignored jython, otherwise people will not be able to hook
> >importing for other purposes.
> >
> >* A framework for extending importing would also be great for jython, for
> >example for poor-man freezing,
> > putting support for everything directly in the runtime being not a good
> >choice.
> >
> >* jythonc side
> >+ package relative import has not been fixed yet.
> >+ proposed --depend option.
> >+ for the future:
> >  - importing of compiled code into interp, and compiling code referring to
> >separate comp results.
> >  - (maybe) jythonc able to compile against a claspath/sys.path different
> >from the classpath/sys.path under which is running
> >
> >* (mostly a potential users wish) it is really difficult to effectively use
> >java security arch from jython and
> >  for jython code,  some kind of rexec mixing java/python policies is maybe
> >a necessary framework. (very complicated)
> >* performance issues?(?)
> 
> I agree with all of this. I'm unsure how we should maintain this list.
> The CPython people have their PEP-0042 for this. 
My suggestion (given the not so formal settings of jython development) is to
create something like a moinmoin site, like the new Python2.0 Info Area,
that's will be a good place for the FAQ because anyone can contribute
and developers can if the case improve, rewrite not totally correct answers,
and for feature requests and for keeping track of design discussions.
That's just a suggestion.
Some of my proposal are clearly not small features: about that I can only say:
* jythonc things are quite interesting, given the time and when more important things
are solved I can try to do something, but the sematics question should be solved
before.
* for imputil/ihooks (personally I should first read both codes) maybe we should
 join import-sig and try to be helpful, or at least to clarify jython needs.
* rexec/security architecture is really *hard*:
 e.g. java1.1 and java2 are different in that respect,
 and we should exploit seriously the java security arch otherwise
 any security effort/statement will be vague.
 
regards, Samuele.