Re: [Jython-users] int vs. boolean

this is just a quick answer so is a bit rough.
>>     
>>>>> b1 = Boolean.TRUE
>>>>> b1
>>>>>           
>> 1
>>     
shouldn't this be True ?

>  Integer -> int
>  String -> str
>  Boolean -> bool
>  ...
>  otherwise-> javainstance
>
> Where javainstance is a thin wrapper for "generic" objects. So this
> means that any java method returning a `Boolean` gets it's result
> transformed to a python's `bool`.
>
> Now the cause. The transformation described above is _not_ done for
> constructors. Constructor "return values" (i.e. `this`) is directly
> mapped to `javainstance`:
>
>   
>>>> type(Boolean(1))
>>>>         
> <type 'javainstance'>
>   
>>>> type(Boolean.TRUE)
>>>>         

Question about ihook

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Jython-users mailing list
Jython-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-users

Pydev 1.3.19 Released

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
pydev-code mailing list
pydev-code <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pydev-code

Re: Question about ihook

In article 
<FB83E9898C8DDE4CA58DFFCA5CE455C802A0472F <at> ntsydexm03.pc.internal.macquar
ie.com>,
 "Anthony Kong" <Anthony.Kong <at> macquarie.com> wrote:

> ImportError: No module named ihooks
>  
> So, I am just wondering
> 1) is there any workaround ?
> 2) why ihooks is not present? Is it due to any technical limitation (of
> java)?

I was able to get past this by adding ihooks.py and fixing a constant so 
Jython could import it, but it revealed another problem.

Webware uses the marshal module, which is not supported in Jython.  This 
is not a recommended practice (see 
http://docs.python.org/lib/module-marshal.html); it may be possible to 
get Webware working by replacing it with the pickle module.

Note - this only applies to Webware 0.8.1; current versions of Webware 
choke during install because of a parser error:

  File "/Users/nicholas/zilles/Webware-0.9.4/DocSupport/pytp.py", line 
154, in process
    exec pi in scope
  File "<string>", line 2
   results = []
   ^
SyntaxError: line 2:0 mismatched input 'results' expecting INDENT 
(<string>, line 2)
--

-- 
Nicholas Riley <njriley <at> uiuc.edu>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Jython settings - input requested

Leo, 

Thanks for all the work that you are doing and I appreciate you being open to this idea.
First a bit of a caveat. My experience with web apps is limited to testing them and I have to confess that I may
not be much of a help in comments regarding the deployment of Jythoninc web apps mainly because I've never
developed any. I have some understanding about tomcat and jboss configuration but that’s about where
it ends. Although with the work on django I might start dabbling. 

That being said, I'd like to improve portability of the tools/apps that I develop. A best case scenario is
just installing the needed files on a new system and double click on the jar (like the installer). So for
example, presume that you have developed 'aTool' that would be useful to others. These co-workers do not
have Jython installed and may never have even heard of Jython which means that you will be using the Jython
standalone jar;  which does not include a registry file. The easiest way to do that currently seems to be,
well.... not so easy. See: http://wiki.python.org/jython/JythonFaq/DistributingJythonScripts.
If you don't have Java development experience the task can be daunting at best. What I'm suggesting is a way
such an environment variable or something that could be set to point to stuff you need for your app. To use a
real example. 
 
Currently I have a classpath that looks like:
C:\Libs\dom4j-1.6.1.jar;C:\Libs\jaxen-1.1.1.jar;c:\libs\log4j-1.2.8.jar;
c:\libs\commons-codec-1.3.jar;c:\libs\commons-discovery-0.2.jar;
c:\libs\commons-logging-1.0.4.jar;C:\Libs\commons-httpclient-3.1.jar;
C:\Libs\ibmjsse.jar;C:\Libs\junit.jar;C:\Libs\Bounce-v09\bounce.jar;
C:\Libs\EasySSL.jar

All of these are needed. But if I want to give what I done to co-workers so they can use 'aTool', its a real
headache... and a MASSIVE jar file. Never mind updates to scripts or jar changes. Ok so this is still pretty
java specific so lets add some python and change it so I have a JythonImports setting that is for example:

C:\pymodules\pygments;c:\mystuff\CustomPythonModules;c:\mystuff\CustomJythonModules;
c:\libs\commons-codec-1.3.jar;c:\libs\commons-discovery-0.2.jar;
c:\libs\commons-logging-1.0.4.jar;C:\Libs\commons-httpclient-3.1.jar;
C:\otherLibs\myJavaStuff.jar

This setting would be read at startup so that import CustomJythonModules * or from org.this.myJavaStuff
import * would just work.

Obviously the name JythonImports is just an example maybe jythonpath or something else would be better.
I guess I'm looking for a hybrid setting that is a combo of pythonPath and classpath that can be use by the
standalone jar (and web apps) and not require a lot of work to move things from a development environment to
a deployment / distribution. The benefits would be easier distribution / deployment of code, easier to
debug and test, easier to modify or change individual components, and finally but hardly last improved
ease of use. I don’t believe this would impact any backward compatibility.

Did this clarify anything or just confuse the issue further.

Greg.


-----Original Message-----
From: Leo Soto M. [mailto:leo.soto <at> gmail.com] 
Sent: Thursday, July 31, 2008 3:02 PM
To: Moore, Greg
Cc: Nicholas Riley; jython-dev <at> lists.sourceforge.net; jython-users <at> lists.sourceforge.net
Subject: Re: [Jython-dev] Jython settings - input requested

On Thu, Jul 31, 2008 at 3:39 PM, Moore, Greg <Greg_W_Moore <at> adp.com> wrote:
> For my 2 cents worth, I like your suggestions and think they will help
> clarify things going forward. I'm wondering if having something like,
> for example, 'JythonImports' setting the that could be used to specify
> where external libraries are so they can be found when using standalone
> Jython or in a web application environment. Something kinda like a
> classpath but could also include python modules as well as java.

Hi Greg, and thanks for your feedback. I'd like if you can expand a
bit more about what would be possible with this new setting so we
understand how it will be different than what "python.path" currently
offers.

I'm very interested on web deployment of Jython projects, so any
feedback/ideas on that topic will be appreciated, but maybe we should
start another thread for that...
-- 
Leo Soto M.
http://blog.leosoto.com


This message and any attachments are intended only for the use of the addressee and may contain information
that is privileged and confidential. If the reader of the message is not the intended recipient or an
authorized representative of the intended recipient, you are hereby notified that any dissemination of
this communication is strictly prohibited. If you have received this communication in error, please
notify us immediately by e-mail and delete the message and any attachments from your system.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jython-dev mailing list
Jython-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: Question about ihook

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Jython-users mailing list
Jython-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-users

Re: Jython settings - input requested

Hi, 
I took another look at the URL below and it raised a few more
questions..
What the difference between 
python.packages.directories
python.packages.paths - wouldn't this be directories as well?

Wouldn't changing python.modules.builtin be a very bad thing? Why would
you want to?

Thanks,
Greg.

-----Original Message-----
From: jython-dev-bounces <at> lists.sourceforge.net
[mailto:jython-dev-bounces <at> lists.sourceforge.net] On Behalf Of Nicholas
Riley
Sent: Thursday, July 31, 2008 12:02 PM
To: jython-dev <at> lists.sourceforge.net
Cc: jython-users <at> lists.sourceforge.net
Subject: [Jython-dev] Jython settings - input requested

Hi folks,

We're trying to clean up the multitude of ways Jython reads settings 
(properties, options) and would appreciate your input on what bits of 
customization you use and which ones you'd like to see added or removed.

Jython reads settings/options/properties at startup from several 
sources.  From the standpoint of a user of the interactive interpreter, 
they are:

- Java system properties (-J-Dxxx=yyy with new launcher script)
- Registry (prop=value in file jython_home/registry or $HOME/.jython)
- Jython properties (-Dxxx=yyy)

There exist several partial attempts at documenting these settings.  
I've attempted to enumerate them all here:

   <http://wiki.python.org/jython/Settings>

Some cases in which I'm pretty sure Jython is not behaving as designed 
or expected:

1. If a registry file is present, the Java system properties are ignored

completely.

2. If both registry files are present, the "registry" one is ignored 
completely.

3. If a property exists in the registry, it takes precedence over a 
command-line option (e.g., python.verbose trumps -v[vv]).

Some changes I'm considering making:

1. Merge system properties and registry files into the registry, rather 
than replacing them outright.

2. Make command-line options take precedence over registry options.

3. Read from the JYTHONPATH environment variable, replacing python.path 
in the registry (or in system properties?).  This is analogous to 
IronPython's IRONPYTHONPATH.

CPython understands a bunch more environment variables (e.g. 
PYTHONDEBUG, PYTHONINSPECT) but I'm not sure we really need to support 
them, either in place or renamed.  Should the JYTHONPATH mapping happen 
in the launcher scripts or Jython itself?

One last thing: in CPython, setting PYTHONPATH places the items after 
the current directory, but before the standard library.  Setting 
python.path in Jython places the items after the standard library; you 
must use python.prepath to get the CPython behavior.

It looks like the reason for this change is no longer applicable:

   <http://www.jython.org/cgi-bin/faqw.py?req=show&file=faq02.003.htp>

as the Python standard library is now included with Jython by default, 
so perhaps python.prepath should be removed and python.path take its 
place?  Or do we need a python.postpath?  Does anyone take advantage of 
this ordering?
-- 
Nicholas Riley <njriley <at> uiuc.edu>

------------------------------------------------------------------------
-
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jython-dev mailing list
Jython-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev

This message and any attachments are intended only for the use of the addressee and may contain information
that is privileged and confidential. If the reader of the message is not the intended recipient or an
authorized representative of the intended recipient, you are hereby notified that any dissemination of
this communication is strictly prohibited. If you have received this communication in error, please
notify us immediately by e-mail and delete the message and any attachments from your system.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Jython settings - input requested

In article 
<4dab5f760807311543ge525c0au3804e0fa7bdc6bf3 <at> mail.gmail.com>,
 "Frank Wierzbicki" <fwierzbicki <at> gmail.com> wrote:

> > 1. If a registry file is present, the Java system properties are ignored
> > completely.
> I agree that seems strange.
> 
> > 2. If both registry files are present, the "registry" one is ignored
> > completely.
> also strange -- does seem like there should be a merging behavior.

After some more investigation, this wasn't quite as I described.  Only 
python.executable behaves like this, because it accesses the registry (a 
Properties object) as a Hashtable, which doesn't check the chained 
"defaults" Properties objects.

Assuming you use all of the various override mechanisms, the registry 
looks like this:

postProperties
  .defaults = .jython
  .defaults = registry
  .defaults = System properties

I fixed sys.executable so it accesses the entire registry in r5047, so 
things are technically correct as is, but it concerns me that Java and 
(especially) Python code can easily make a mistake accessing the 
registry.  You must remember to use .getProperty(key) instead of 
.get(key) or [key] (in Python), otherwise you'll only get the top 
"level" of the registry.

Similarly, if you try to print the registry, it only shows the top level.

I can think of a few solutions to this:

1. Merge everything into a single Properties hashtable without any 
"defaults" links.  This means any changes to the Java System properties 
after Jython starts up won't go into the registry, which I think it's 
likely at least some code probably depends on.

2. Merge everything *but* the System properties.  This at least lets you 
see the contents of the registry and reflects .

3. Don't merge anything, but create a Registry class which dynamically 
generates a merged hashtable on any access - so get and __getitem__ 
would work.

> > 2. Make command-line options take precedence over registry options.
> +1

Still to do.

> > 3. Read from the JYTHONPATH environment variable, replacing python.path
> > in the registry (or in system properties?).  This is analogous to
> > IronPython's IRONPYTHONPATH.
> +1

Done (r5050).  If you pass -Dpython.path to Jython (but not to Java), it 
overrides $JYTHONPATH.

> > One last thing: in CPython, setting PYTHONPATH places the items after
> > the current directory, but before the standard library.  Setting
> > python.path in Jython places the items after the standard library; you
> > must use python.prepath to get the CPython behavior.
> That sounds like a bug unless it is unavoidable for some reason.
[...]
> I'd be happier if we can get rid of this.

Gone (r5043).
--

-- 
Nicholas Riley <njriley <at> uiuc.edu>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Jython settings - input requested

In article 
<C30753A75484EB4AA54E379557483A981FC683F6 <at> EXCHANGEDS01.ds.ad.adp.com>,
 "Moore, Greg" <Greg_W_Moore <at> adp.com> wrote:

> I took another look at the URL below and it raised a few more
> questions..
> What the difference between 
> python.packages.directories
> python.packages.paths - wouldn't this be directories as well?

These relate to the Java package cache - see 
<http://wiki.python.org/jython/PackageScanning>.

> Wouldn't changing python.modules.builtin be a very bad thing? Why would
> you want to?

This is documented (only, as far as I can tell) in the sample registry 
file.

# Use this registry entry to control the list of builtin modules; you
# can add, remove, or override builtin modules.  The value for this
# registry key is a comma separated list of module entries, each entry 
# of which has the following allowable forms:
#
# name
#     The module name is `name' and the class name is
#     org.python.modules.name
#
# name:class
#     The module name is `name' and the class name is `class' where
#     class must be a fully qualified Java class name
#
# name:null
#     The module `name' is removed from the list of builtin modules
#
# A good example would be to use a jni version of os for more
# functionality by having an entry such as os:com.foo.jni.os
#python.modules.builtin = whatever

This could be useful for sandboxing, or to replace built-in Jython 
module implementations with custom ones more suited to embedding.

There used to be a "jnios" module that could be used as described above:

   <http://jnios.sourceforge.net/>

but since we now use JNA in the Jython os module, it's no longer 
necessary.
--

-- 
Nicholas Riley <njriley <at> uiuc.edu>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Question about ihook

In article 
<b0b163580808011620p2b15152cp3d230cab32b16c92 <at> mail.gmail.com>,
 "Anthony Kong" <anthony.hw.kong <at> gmail.com> wrote:

> Thanks Nicholas,
> 
> The doc generation was also a problem for me, so I simply by-passed it.
> 
> Just some follow-up questions to the mailing list:
> 
> 1) the ihooks.py is present in the jython 2.2 svn repos, so any reason why
> it is not in 2.5a1?

I don't see it in 2.2:

http://jython.svn.sourceforge.net/svnroot/jython/branches/Release_2_2main
t/jython/Lib/

> 2) If i used this ihooks.py, the Webware will run but will hit another
> problem: missing attribute C_BULITIN. So, what is this C_BUILTIN
> 
> Is it something easy to fix?

Yes, it's just a constant, easy enough to fix.

http://fisheye3.atlassian.com/browse/jython/branches/asm/src/org/python/m
odules/imp.java?r1=4914&r2=5041

If you're already on 2.5a1, just check out and build the asm branch; it 
will install ihooks.py.

One more thing I needed to change was 'whrandom' to 'random'; 'whrandom' 
is not available in CPython 2.5 either.
--

-- 
Nicholas Riley <njriley <at> uiuc.edu>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/