You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(38) |
Nov
(98) |
Dec
(58) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(114) |
Feb
(123) |
Mar
(96) |
Apr
(66) |
May
(84) |
Jun
(72) |
Jul
(128) |
Aug
(126) |
Sep
(82) |
Oct
(80) |
Nov
(148) |
Dec
(55) |
| 2002 |
Jan
(137) |
Feb
(85) |
Mar
(118) |
Apr
(67) |
May
(71) |
Jun
(28) |
Jul
(69) |
Aug
(48) |
Sep
(83) |
Oct
(79) |
Nov
(54) |
Dec
(32) |
| 2003 |
Jan
(44) |
Feb
(47) |
Mar
(59) |
Apr
(57) |
May
(43) |
Jun
(45) |
Jul
(44) |
Aug
(39) |
Sep
(27) |
Oct
(62) |
Nov
(17) |
Dec
(23) |
| 2004 |
Jan
(41) |
Feb
(51) |
Mar
(38) |
Apr
(30) |
May
(25) |
Jun
(12) |
Jul
(11) |
Aug
(27) |
Sep
(16) |
Oct
(56) |
Nov
(23) |
Dec
(29) |
| 2005 |
Jan
(75) |
Feb
(82) |
Mar
(50) |
Apr
(77) |
May
(19) |
Jun
(104) |
Jul
(47) |
Aug
(42) |
Sep
(28) |
Oct
(143) |
Nov
(62) |
Dec
(13) |
| 2006 |
Jan
(20) |
Feb
(10) |
Mar
(59) |
Apr
(45) |
May
(25) |
Jun
(129) |
Jul
(162) |
Aug
(91) |
Sep
(15) |
Oct
(39) |
Nov
(186) |
Dec
(191) |
| 2007 |
Jan
(134) |
Feb
(140) |
Mar
(106) |
Apr
(77) |
May
(92) |
Jun
(63) |
Jul
(233) |
Aug
(102) |
Sep
(119) |
Oct
(63) |
Nov
(68) |
Dec
(32) |
| 2008 |
Jan
(69) |
Feb
(91) |
Mar
(129) |
Apr
(44) |
May
(18) |
Jun
(53) |
Jul
(50) |
Aug
(25) |
Sep
(11) |
Oct
(28) |
Nov
(67) |
Dec
(36) |
| 2009 |
Jan
(20) |
Feb
(24) |
Mar
(66) |
Apr
(53) |
May
(48) |
Jun
(48) |
Jul
(59) |
Aug
(82) |
Sep
(49) |
Oct
(30) |
Nov
(16) |
Dec
(16) |
| 2010 |
Jan
(52) |
Feb
(25) |
Mar
(36) |
Apr
(34) |
May
(14) |
Jun
(15) |
Jul
(14) |
Aug
(16) |
Sep
(23) |
Oct
(6) |
Nov
(4) |
Dec
(5) |
| 2011 |
Jan
(4) |
Feb
(22) |
Mar
(45) |
Apr
(9) |
May
(8) |
Jun
(13) |
Jul
(12) |
Aug
(4) |
Sep
(6) |
Oct
(10) |
Nov
(21) |
Dec
(5) |
| 2012 |
Jan
(6) |
Feb
(9) |
Mar
(25) |
Apr
(6) |
May
(4) |
Jun
(23) |
Jul
(6) |
Aug
(18) |
Sep
(21) |
Oct
(34) |
Nov
(19) |
Dec
(25) |
| 2013 |
Jan
(8) |
Feb
(34) |
Mar
(35) |
Apr
(4) |
May
(11) |
Jun
(4) |
Jul
(7) |
Aug
(5) |
Sep
(20) |
Oct
(12) |
Nov
(11) |
Dec
(7) |
| 2014 |
Jan
(10) |
Feb
(18) |
Mar
(50) |
Apr
(26) |
May
(53) |
Jun
(21) |
Jul
(12) |
Aug
(39) |
Sep
(43) |
Oct
(26) |
Nov
(8) |
Dec
(6) |
| 2015 |
Jan
(18) |
Feb
(32) |
Mar
(31) |
Apr
(42) |
May
(38) |
Jun
(13) |
Jul
(6) |
Aug
(11) |
Sep
(29) |
Oct
(25) |
Nov
(10) |
Dec
(11) |
| 2016 |
Jan
(24) |
Feb
(12) |
Mar
(13) |
Apr
(15) |
May
(22) |
Jun
(8) |
Jul
(12) |
Aug
(25) |
Sep
(8) |
Oct
(6) |
Nov
(13) |
Dec
(7) |
| 2017 |
Jan
(6) |
Feb
(29) |
Mar
(32) |
Apr
(8) |
May
(82) |
Jun
(42) |
Jul
(20) |
Aug
(17) |
Sep
(27) |
Oct
(14) |
Nov
(22) |
Dec
(6) |
| 2018 |
Jan
(12) |
Feb
(9) |
Mar
(22) |
Apr
(19) |
May
(14) |
Jun
(9) |
Jul
(9) |
Aug
(22) |
Sep
(22) |
Oct
(12) |
Nov
(13) |
Dec
(8) |
| 2019 |
Jan
(22) |
Feb
(3) |
Mar
(30) |
Apr
(20) |
May
(20) |
Jun
(6) |
Jul
(15) |
Aug
(25) |
Sep
(11) |
Oct
(24) |
Nov
(11) |
Dec
(6) |
| 2020 |
Jan
(9) |
Feb
(12) |
Mar
(29) |
Apr
(10) |
May
(22) |
Jun
(11) |
Jul
(15) |
Aug
(5) |
Sep
(6) |
Oct
(7) |
Nov
(7) |
Dec
(13) |
| 2021 |
Jan
(21) |
Feb
(5) |
Mar
(5) |
Apr
(6) |
May
(10) |
Jun
(7) |
Jul
(6) |
Aug
(8) |
Sep
(5) |
Oct
(9) |
Nov
(5) |
Dec
(6) |
| 2022 |
Jan
(5) |
Feb
(4) |
Mar
(8) |
Apr
(6) |
May
(5) |
Jun
(5) |
Jul
(10) |
Aug
(6) |
Sep
(7) |
Oct
(4) |
Nov
(4) |
Dec
(6) |
| 2023 |
Jan
(5) |
Feb
(5) |
Mar
(6) |
Apr
(4) |
May
(5) |
Jun
(6) |
Jul
(5) |
Aug
(5) |
Sep
(5) |
Oct
(5) |
Nov
(7) |
Dec
(8) |
| 2024 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2025 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <bc...@wo...> - 2000-12-06 08:55:52
|
[Humbel Otmar] >first many thanks for moving Jython on! > >I admit I was'nt fully able to follow (mean: understand) the latest >discussion on proxies and cache design, so please forgive me if the >questions below sound too naive. > >How is the relation of the new cache/proxy design to the old JPython 1.0.3. >style proxy savedir ? > [snippet from good old registry file:] > #Only enable this if you're SURE you want it > python.proxy.savedir = n:/java/lib The proxy cache recently discussed here is the in-memory mapping from class names to the PyJavaClass which represent the class. Calling it a cache is probably wrong, the PyJavaClass.classes hashtable is not about performance, but about ensuring a 1-1 mapping between a class and its PyJavaClass. The problem we have been talking about is how to ensure this 1-1 mapping when the java class haven't been loaded yet (what we call "lazy loading") and when the java class gets reloaded (different class with the same name). The proxy.savedir option were OTOH a true performance cache with the name of the java class as cache-key. The option was never enabled for JPython-1.1. There were several reasons for this omission: - The proxies classes does not have a uniquely identifiable name anymore. The generated proxy class name include a serial number that makes it difficult to use a cache like the one in 1.0.3. - JPython-1.1 included new and much improved ways of freezing. If the dynamic proxy creation is too slow, jpythonc can create the proxies for you in advance. - Having a performance cache without any means of flushing the cache when it gets stale is bad design. We still have no way of detecting when a java have changed. >Do we still need these proxies with Jython 2.0 ? We definitely need them in >JPython 1.0.3 and we almost rebuilt them again for JPython 1.1 - for runtime >performance reasons. We always need better performance. I have been thinking a little about a design where the generated proxies is stored at the end of the $py.class file. This would still not solve the flushing issue, but it would make a manual flush of the cached proxy much easier. regards, finn |
|
From: Humbel O. <Otm...@bi...> - 2000-12-06 06:54:34
|
Hello Jython developers, first many thanks for moving Jython on! I admit I was'nt fully able to follow (mean: understand) the latest discussion on proxies and cache design, so please forgive me if the questions below sound too naive. How is the relation of the new cache/proxy design to the old JPython 1.0.3. style proxy savedir ? [snippet from good old registry file:] #Only enable this if you're SURE you want it python.proxy.savedir = n:/java/lib Do we still need these proxies with Jython 2.0 ? We definitely need them in JPython 1.0.3 and we almost rebuilt them again for JPython 1.1 - for runtime performance reasons. Thank you for your comments, Oti |
|
From: Robert W. B. <rb...@di...> - 2000-12-05 22:50:40
|
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 |
|
From: <bc...@wo...> - 2000-12-05 21:45:22
|
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 |
|
From: <bc...@wo...> - 2000-12-03 12:40:14
|
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 |
|
From: <bc...@wo...> - 2000-12-01 23:04:05
|
[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
|
|
From: Steven M. <sr...@ya...> - 2000-12-01 03:01:20
|
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/ |
|
From: <ba...@di...> - 2000-11-30 20:53:08
|
>>>>> "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
|
|
From: Leung, T. <te...@en...> - 2000-11-30 19:14:29
|
Hi, What happened to the Jython 2.0a1 binary? The download page from sourceforge say it isn't there? Thanks, Ted Leung |
|
From: Samuele P. <pe...@in...> - 2000-11-30 14:18:14
|
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. |
|
From: <bc...@wo...> - 2000-11-29 22:08:07
|
[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
|
|
From: Chris K. <ck...@ma...> - 2000-11-29 15:23:20
|
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.) |
|
From: <bc...@wo...> - 2000-11-29 10:37:13
|
[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 |
|
From: <bc...@wo...> - 2000-11-29 09:44:40
|
[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
|
|
From: <bc...@wo...> - 2000-11-28 23:37:39
|
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 |
|
From: <bc...@wo...> - 2000-11-28 23:09:53
|
[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 |
|
From: Jorge M. J. <jmi...@se...> - 2000-11-28 23:02:07
|
How can I access Java protected (static) members from a Jython subclass? Thanks in advance... |
|
From: Ype K. <yk...@xs...> - 2000-11-28 21:11:04
|
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())
|
|
From: Robert W. B. <rb...@di...> - 2000-11-28 19:29:11
|
[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
|
|
From: Chris K. <ck...@ma...> - 2000-11-28 14:50:31
|
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. |
|
From: <bc...@wo...> - 2000-11-28 12:13:03
|
[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 |
|
From: <bc...@wo...> - 2000-11-28 11:13:53
|
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 |
|
From: Chris K. <cla...@ca...> - 2000-11-28 02:07:52
|
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. |
|
From: Jorge M. J. <jmi...@se...> - 2000-11-27 15:53:05
|
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... |
|
From: <bc...@wo...> - 2000-11-26 19:20:59
|
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
|