jython-dev

RE: [Jython-dev] jythons module os

[Phil S. <psu...@es...>]

I was hoping to do a lazy initialization thing. 

I'm open to suggestions as to how to do it... 
I haven't actually written anything yet and I'm working
on writing some jython tasks for ant first. 

My thoughts were to create a class that implements all the
dictionary things - __getitem__ etc - and populate
the dictionary the first time any of these are called.

By cribbing from ant I should be able to put in support 
for a read-only environment for unices and win32.
I haven't thought writing through yet, but I figure 
reading will hit a large percentage of the use cases.


-----Original Message-----
From: bc...@wo... [mailto:bc...@wo...]
Sent: Wednesday, October 31, 2001 2:26 PM
To: jyt...@li...
Subject: Re: [Jython-dev] jythons module os


[Phil Surette]

>I am planning to look into adding os.environment and os.system
>support in, basically cribbing from how ant does this, but
>I have not had time yet.

I hope you and/or someone else find some time to look into it, it would
be a valuable addition. I'm not sure what the right way to enable the
os.environment should be. It isn't right to fill the os.environment dict
whenever "os" is imported, that would be way to slow for all the program
that never uses any enviroment variables. Any thoughts?

>However, I think jnios is probably the better way to go for
>you. Someone needs to finish it though. 

Any volunteers?

regards,
finn

_______________________________________________
Jython-dev mailing list
Jyt...@li...
https://lists.sourceforge.net/lists/listinfo/jython-dev

RE: [Jython-dev] jythons module os

[Phil S. <psu...@es...>]

Yeah, I'm doing that. 

I'm writing three tasks:
1) a jython task. This is like the ant <script> task
but it has several improvements:
   - handles indented jython scripts.
   - massages stack traces to make line numbers relative to
the ant build file, rather than relative to the start of the
script within the build file
   - auto-imports some packages (right now, os, os.path,
sys, string, re) - interetes to hear if others think
this is a good/evil feature
   - saves typing <jython> vs <script language="jpython">
The jython task is working.

2) jythonc task - haven't started yet, hopefully tonight.

3) jytaskdef task - define an ant task from within an
ant build file. You write some jython code with (at
the minimum) an execute(self) method; this code gets
embedded in a jython class that extends org.apache.an.main.Task;
this gets compiled  with jythonc; then the task is defined
and available everywhere in the build script.

I do not expect that the ant developers will like/want to
maintain task #3... however I think it will be very useful.
Anyway, I'll submit the tasks to the jython group when
they're ready.

-----Original Message-----
From: bc...@wo... [mailto:bc...@wo...]
Sent: Thursday, November 01, 2001 10:14 AM
To: jyt...@li...
Subject: Re: [Jython-dev] jythons module os


[Phil Surette]

>I was hoping to do a lazy initialization thing. 
>
>I'm open to suggestions as to how to do it... 
>I haven't actually written anything yet and I'm working
>on writing some jython tasks for ant first. 

On that note, if anyone feels like writing an ant task to invoke the
jythonc compiler it would be quite a usefull.

>My thoughts were to create a class that implements all the
>dictionary things - __getitem__ etc - and populate
>the dictionary the first time any of these are called.

Good. Maybe we should add a system property to completely disable all
attempt to fill os.environment. I can image there is environments where
a security manager does not allow calls to Runtime.exec().

>By cribbing from ant I should be able to put in support 
>for a read-only environment for unices and win32.

That's fine for a start. Beyond win&unix we have to let users send
patches for their own platforms anyway.

Does anyone know how ant decide that it is running on unix?

>I haven't thought writing through yet, but I figure 
>reading will hit a large percentage of the use cases.

Writing is normally done by inserting values in the os.environment dict
and using that dict for the os.system() call. We can't possibly do any
better in core jython.

regards,
finn

_______________________________________________
Jython-dev mailing list
Jyt...@li...
https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] jythons module os

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

[Phil Surette]

>Yeah, I'm doing that. 
>
>I'm writing three tasks:
>1) a jython task. This is like the ant <script> task
>but it has several improvements:
>   - handles indented jython scripts.
>   - massages stack traces to make line numbers relative to
>the ant build file, rather than relative to the start of the
>script within the build file
>   - auto-imports some packages (right now, os, os.path,
>sys, string, re) - interetes to hear if others think
>this is a good/evil feature

This part is evil. Rule #2 clearly says that explicit is better than
implicit. 
   http://www.python.org/doc/Humor.html#zen

If you really think it is usefull, I can't see any problems with adding
a xml attribute to the jython tag to enable automatic import of some
modules, say:

<jython autoimports="true">
os.mkdir("newdir")
</jython>

>   - saves typing <jython> vs <script language="jpython">
>The jython task is working.

Cool.

>2) jythonc task - haven't started yet, hopefully tonight.
>
>3) jytaskdef task - define an ant task from within an
>ant build file. You write some jython code with (at
>the minimum) an execute(self) method; this code gets
>embedded in a jython class that extends org.apache.an.main.Task;
>this gets compiled  with jythonc; 

Is the jythonc step needed? Maybe I misunderstand the intention behind
jytaskdef, but from your description, I imagine something like:

<jytaskdef taskname="MyTask">
import org
class MyTask(org.apache.tools.ant.Task):
    def execute(self):
	print "Do something usefull"
</jytaskdef>

jytaskdef would then call project.addTaskDefinition("MyTask", MyTask). 

So, how big is my misunderstanding?

>then the task is defined
>and available everywhere in the build script.
>
>I do not expect that the ant developers will like/want to
>maintain task #3... however I think it will be very useful.

I'm not sure I would want the jakarta people to maintain #2. We should
be able to add new options to the jythonc and ensure that ant
integration is in sync. Assuming it is technically possible to include
the task in jython.jar, I would prefer to maintain it outself.

OTOH, I have never maintained an ant Task. If the ant project changes
the API between every ant release it may to big a job to keep up with
them. 

>Anyway, I'll submit the tasks to the jython group when
>they're ready.

Nice.

regards,
finn

Re: [Jython-dev] jythons module os

[Phil S. <phi...@ho...>]

Finn Bock wrote:
> 
> [Phil Surette]
> 
> >Yeah, I'm doing that.
> >
> >I'm writing three tasks:
> >1) a jython task. This is like the ant <script> task
> >but it has several improvements:
> >   - handles indented jython scripts.
> >   - massages stack traces to make line numbers relative to
> >the ant build file, rather than relative to the start of the
> >script within the build file

By the way, I gave up on figuring out how PyTracebacks work
(too many PyObjects) and ended up doing a regex thing to 
patch up the line numbers. Am I missing some critical
piece of information? 

> >   - auto-imports some packages (right now, os, os.path,
> >sys, string, re) - interetes to hear if others think
> >this is a good/evil feature
> 
> This part is evil. Rule #2 clearly says that explicit is better than
> implicit.
>    http://www.python.org/doc/Humor.html#zen
> 
> If you really think it is usefull, I can't see any problems with adding
> a xml attribute to the jython tag to enable automatic import of some
> modules, say:
> 
> <jython autoimports="true">
> os.mkdir("newdir")
> </jython>
>

I admit that it is evil. However, it is also something that 
I want; otherwise my embedded scripts are often more
than 50% imports. 

I am planning to add options for
controlling it but haven't worked them out yet. Once I
have maybe I'll propose a vote.

> >   - saves typing <jython> vs <script language="jpython">
> >The jython task is working.
> 
> Cool.
> 
> >2) jythonc task - haven't started yet, hopefully tonight.
> >
> >3) jytaskdef task - define an ant task from within an
> >ant build file. You write some jython code with (at
> >the minimum) an execute(self) method; this code gets
> >embedded in a jython class that extends org.apache.an.main.Task;
> >this gets compiled  with jythonc;
> 
> Is the jythonc step needed? Maybe I misunderstand the intention behind
> jytaskdef, but from your description, I imagine something like:
> 
> <jytaskdef taskname="MyTask">
> import org
> class MyTask(org.apache.tools.ant.Task):
>     def execute(self):
>         print "Do something usefull"
> </jytaskdef>
> 
> jytaskdef would then call project.addTaskDefinition("MyTask", MyTask).
> 
> So, how big is my misunderstanding?

Well, I didn't think that you could call jython classes
directly from java... ant needs to be able to load the 
class in a classloader and call various setxxx methods
and then call execute.

Maybe jython is even more magical than I thought?
 
> 
> >then the task is defined
> >and available everywhere in the build script.
> >
> >I do not expect that the ant developers will like/want to
> >maintain task #3... however I think it will be very useful.
> 
> I'm not sure I would want the jakarta people to maintain #2. We should
> be able to add new options to the jythonc and ensure that ant
> integration is in sync. Assuming it is technically possible to include
> the task in jython.jar, I would prefer to maintain it outself.
> 
> OTOH, I have never maintained an ant Task. If the ant project changes
> the API between every ant release it may to big a job to keep up with
> them.
> 
> >Anyway, I'll submit the tasks to the jython group when
> >they're ready.
> 
> Nice.
> 
> regards,
> finn
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] jythons module os

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

>> >
>> >I'm writing three tasks:
>> >1) a jython task. This is like the ant <script> task
>> >but it has several improvements:
>> >   - handles indented jython scripts.
>> >   - massages stack traces to make line numbers relative to
>> >the ant build file, rather than relative to the start of the
>> >script within the build file
>
>By the way, I gave up on figuring out how PyTracebacks work
>(too many PyObjects) 

The trick is never to trust what you see when calling
System.out.print(). Some of the classes in the exception & traceback
subsystem override toString().

>and ended up doing a regex thing to 
>patch up the line numbers. Am I missing some critical
>piece of information? 

It turned out that jython is badly prepared for setting the start line
numbers in a call to compile(). I have added for feature request about
it, but until it is implementated you might be able to use the hack
below.

>> jytaskdef would then call project.addTaskDefinition("MyTask", MyTask).
>> 
>> So, how big is my misunderstanding?
>
>Well, I didn't think that you could call jython classes
>directly from java...

A python class which extends a java class or java interface is a
completely ordinary java class.

>ant needs to be able to load the class in a classloader 

If the new task is added by project.addTaskDefinition(String,Class)
there is no need to let ant do the loading of the class.

You can get hold of the new Task and use like this:

  PyObject newClass = interp.get("MyTask");
  Object tmp = newClass.__tojava__(Class.class);
  if (tmp != Py.NoConversion && Task.class.isAssignableFrom((Class) tmp) {
     project.addTaskDefinition("MyTask", (Class)tmp);
  }

>and call various setxxx methods
>and then call execute.
>
>Maybe jython is even more magical than I thought?

regards,
finn


public class x {
    public static void main(String[] args) {
        PythonInterpreter interp = new PythonInterpreter();
        try {
            // a syntax error
            interp.exec(
                "if 1:\n" + 
                "   a = 1\n" + 
                "  b = 0\n");
        } catch (PyException exc) {
            fixAndPrintError(exc, 20);
        }
        
        try {
            // throws a NameError
            interp.exec(
                "def foo():\n" +
                "   a = c\n" + 
                "foo()\n");
        } catch (PyException exc) {
            fixAndPrintError(exc, 20);
        }
    }

    private static void fixAndPrintError(PyException exc, int startLine) {
        System.out.println();
        System.out.println("Traceback (innermost last):");

        if (exc instanceof PySyntaxError) {
            PySyntaxError se = (PySyntaxError)exc;
            se.instantiate();
            int line = se.value.__getattr__("lineno").__int__().getValue();
            int col = se.value.__getattr__("offset").__int__().getValue();
            String text = se.value.__getattr__("text").toString();
            String filename = se.value.__getattr__("filename").toString();
            System.out.println("  File \""+filename+"\", line "+
                                (line+startLine));
            if (text != null && text.length() != 0) {
                System.out.println("\t"+text);
                String space = "\t";
                for(int j=1; j<col; j++)
                    space = space+" ";
                System.out.println(space+"^");
            }
            System.out.println("SyntaxError: " + exc.value.__getitem__(0));
            return;
        }

        PyTraceback tb = exc.traceback;
        StringBuffer buf = new StringBuffer();
        dumpStack(tb, buf, startLine);
        System.out.print(buf);

        PyObject typeName;
        if (exc.type instanceof PyClass) {
            typeName = new PyString(((PyClass)exc.type).__name__);
        } else {
            typeName = exc.type;
        }

        System.out.println(typeName + ": " + exc.value);
    }


    private static String line(PyTraceback tb, int startLine) {
        if (tb.tb_frame == null || tb.tb_frame.f_code == null)
            return "  (no code object) at line "+
                        (tb.tb_lineno + startLine)+"\n";
        return "  File \""+tb.tb_frame.f_code.co_filename+
            "\", line "+(tb.tb_lineno + startLine)+
            ", in "+tb.tb_frame.f_code.co_name+"\n";
    }

    public static void dumpStack(PyTraceback tb, StringBuffer buf,
                                 int startLine) {
        buf.append(line(tb, startLine));
        if (tb.tb_next != Py.None && tb.tb_next != tb)
            dumpStack((PyTraceback) tb.tb_next, buf, startLine);
        else if (tb.tb_next == tb) {
            buf.append("circularity detected!"+tb+tb.tb_next);
        }
    }

}

Re: [Jython-dev] testing for SyntaxError (was: jythons module os)

[Samuele P. <ped...@bl...>]

I'm a bit pedantic :)

> 
>         if (exc instanceof PySyntaxError) {
>             PySyntaxError se = (PySyntaxError)exc;
>             se.instantiate();

IMHO all code outside the jython codebase should
not rely on the fact that the codebase throws
SyntaxError wrapped as PySyntaxError instances and not
generic PyException instances. That's an impl.
detail and I can imagine a remote scenario where 
some imports trigger an import hook which sometimes
programmatically raises a SyntaxError (which then would
not be wrapped in a PySyntaxError) ...

so the above code should be in the form:

if (Py.matchException(exc,Py.SyntaxError) {
 ...

regards, Samuele.

Re: [Jython-dev] testing for SyntaxError (was: jythons module os)

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

[Samuele]

>I'm a bit pedantic :)
>
>>         if (exc instanceof PySyntaxError) {
>>             PySyntaxError se = (PySyntaxError)exc;
>>             se.instantiate();
>
>IMHO all code outside the jython codebase should
>not rely ...

Guilty as charged.

regards,
finn

Re: [Jython-dev] jythons module os

[Phil S. <phi...@ho...>]

Thanks Finn, I will try this stuff out sometime this week.

Jython _is_ more magical than I thought!

Finn Bock wrote:
> 
> >> >
> >> >I'm writing three tasks:
> >> >1) a jython task. This is like the ant <script> task
> >> >but it has several improvements:
> >> >   - handles indented jython scripts.
> >> >   - massages stack traces to make line numbers relative to
> >> >the ant build file, rather than relative to the start of the
> >> >script within the build file
> >
> >By the way, I gave up on figuring out how PyTracebacks work
> >(too many PyObjects)
> 
> The trick is never to trust what you see when calling
> System.out.print(). Some of the classes in the exception & traceback
> subsystem override toString().
> 
> >and ended up doing a regex thing to
> >patch up the line numbers. Am I missing some critical
> >piece of information?
> 
> It turned out that jython is badly prepared for setting the start line
> numbers in a call to compile(). I have added for feature request about
> it, but until it is implementated you might be able to use the hack
> below.
> 
> >> jytaskdef would then call project.addTaskDefinition("MyTask", MyTask).
> >>
> >> So, how big is my misunderstanding?
> >
> >Well, I didn't think that you could call jython classes
> >directly from java...
> 
> A python class which extends a java class or java interface is a
> completely ordinary java class.
> 
> >ant needs to be able to load the class in a classloader
> 
> If the new task is added by project.addTaskDefinition(String,Class)
> there is no need to let ant do the loading of the class.
> 
> You can get hold of the new Task and use like this:
> 
>   PyObject newClass = interp.get("MyTask");
>   Object tmp = newClass.__tojava__(Class.class);
>   if (tmp != Py.NoConversion && Task.class.isAssignableFrom((Class) tmp) {
>      project.addTaskDefinition("MyTask", (Class)tmp);
>   }
> 
> >and call various setxxx methods
> >and then call execute.
> >
> >Maybe jython is even more magical than I thought?
> 
> regards,
> finn
> 
> public class x {
>     public static void main(String[] args) {
>         PythonInterpreter interp = new PythonInterpreter();
>         try {
>             // a syntax error
>             interp.exec(
>                 "if 1:\n" +
>                 "   a = 1\n" +
>                 "  b = 0\n");
>         } catch (PyException exc) {
>             fixAndPrintError(exc, 20);
>         }
> 
>         try {
>             // throws a NameError
>             interp.exec(
>                 "def foo():\n" +
>                 "   a = c\n" +
>                 "foo()\n");
>         } catch (PyException exc) {
>             fixAndPrintError(exc, 20);
>         }
>     }
> 
>     private static void fixAndPrintError(PyException exc, int startLine) {
>         System.out.println();
>         System.out.println("Traceback (innermost last):");
> 
>         if (exc instanceof PySyntaxError) {
>             PySyntaxError se = (PySyntaxError)exc;
>             se.instantiate();
>             int line = se.value.__getattr__("lineno").__int__().getValue();
>             int col = se.value.__getattr__("offset").__int__().getValue();
>             String text = se.value.__getattr__("text").toString();
>             String filename = se.value.__getattr__("filename").toString();
>             System.out.println("  File \""+filename+"\", line "+
>                                 (line+startLine));
>             if (text != null && text.length() != 0) {
>                 System.out.println("\t"+text);
>                 String space = "\t";
>                 for(int j=1; j<col; j++)
>                     space = space+" ";
>                 System.out.println(space+"^");
>             }
>             System.out.println("SyntaxError: " + exc.value.__getitem__(0));
>             return;
>         }
> 
>         PyTraceback tb = exc.traceback;
>         StringBuffer buf = new StringBuffer();
>         dumpStack(tb, buf, startLine);
>         System.out.print(buf);
> 
>         PyObject typeName;
>         if (exc.type instanceof PyClass) {
>             typeName = new PyString(((PyClass)exc.type).__name__);
>         } else {
>             typeName = exc.type;
>         }
> 
>         System.out.println(typeName + ": " + exc.value);
>     }
> 
>     private static String line(PyTraceback tb, int startLine) {
>         if (tb.tb_frame == null || tb.tb_frame.f_code == null)
>             return "  (no code object) at line "+
>                         (tb.tb_lineno + startLine)+"\n";
>         return "  File \""+tb.tb_frame.f_code.co_filename+
>             "\", line "+(tb.tb_lineno + startLine)+
>             ", in "+tb.tb_frame.f_code.co_name+"\n";
>     }
> 
>     public static void dumpStack(PyTraceback tb, StringBuffer buf,
>                                  int startLine) {
>         buf.append(line(tb, startLine));
>         if (tb.tb_next != Py.None && tb.tb_next != tb)
>             dumpStack((PyTraceback) tb.tb_next, buf, startLine);
>         else if (tb.tb_next == tb) {
>             buf.append("circularity detected!"+tb+tb.tb_next);
>         }
>     }
> 
> }
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] jythons module os

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

[Phil Surette]

>I was hoping to do a lazy initialization thing. 
>
>I'm open to suggestions as to how to do it... 
>I haven't actually written anything yet and I'm working
>on writing some jython tasks for ant first. 

On that note, if anyone feels like writing an ant task to invoke the
jythonc compiler it would be quite a usefull.

>My thoughts were to create a class that implements all the
>dictionary things - __getitem__ etc - and populate
>the dictionary the first time any of these are called.

Good. Maybe we should add a system property to completely disable all
attempt to fill os.environment. I can image there is environments where
a security manager does not allow calls to Runtime.exec().

>By cribbing from ant I should be able to put in support 
>for a read-only environment for unices and win32.

That's fine for a start. Beyond win&unix we have to let users send
patches for their own platforms anyway.

Does anyone know how ant decide that it is running on unix?

>I haven't thought writing through yet, but I figure 
>reading will hit a large percentage of the use cases.

Writing is normally done by inserting values in the os.environment dict
and using that dict for the os.system() call. We can't possibly do any
better in core jython.

regards,
finn

Re: [Jython-dev] jythons module os

[dman <ds...@ri...>]

On Thu, Nov 01, 2001 at 03:14:17PM +0000, Finn Bock wrote:
| [Phil Surette]
 
| >I haven't thought writing through yet, but I figure 
| >reading will hit a large percentage of the use cases.
| 
| Writing is normally done by inserting values in the os.environment dict
| and using that dict for the os.system() call. We can't possibly do any
| better in core jython.

How does os.setenv() figure into this?  I imagine that this operation
is probably not possible in Java, thus the call should either silently
ignore it, or raise an exception.

I was thinking that, perhaps, some environment values can be gotten
from Java directly.  For example,

    print os.eviron[ "HOME" ]

    could be the same as

    System.out.println( System.getProperty( "user.home" ) ) ;

though on some JVMs, user.home is really messed up (ex, jdk1.1.8 on
win).  I think Java ignores the user's preferences (ie setting $HOME
in bash or cmd.exe) and using whatever it feels like, so this may not
be a good idea.

-D

Re: [Jython-dev] jythons module os

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

On Thu, 1 Nov 2001 10:26:25 -0500, you wrote:

>On Thu, Nov 01, 2001 at 03:14:17PM +0000, Finn Bock wrote:
>| [Phil Surette]
> 
>| >I haven't thought writing through yet, but I figure 
>| >reading will hit a large percentage of the use cases.
>| 
>| Writing is normally done by inserting values in the os.environment dict
>| and using that dict for the os.system() call. We can't possibly do any
>| better in core jython.
>
>How does os.setenv() figure into this? 

I guess you mean os.putenv()?

>I imagine that this operation is probably not possible in Java,

Right.

>thus the call should either silently
>ignore it, or raise an exception.

Either os.putenv() shouldn't be implemented at all or it should be
implemented as:

def putenv(varname, value):
   os.enviroment[varname] = value


>I was thinking that, perhaps, some environment values can be gotten
>from Java directly.  For example,
>
>    print os.eviron[ "HOME" ]
>
>    could be the same as
>
>    System.out.println( System.getProperty( "user.home" ) ) ;
>
>though on some JVMs, user.home is really messed up (ex, jdk1.1.8 on
>win).  I think Java ignores the user's preferences (ie setting $HOME
>in bash or cmd.exe) and using whatever it feels like, so this may not
>be a good idea.

The property route should not be mixed with the "sh -c env" route. Using
properties have been mentioned before, but nobody have picked it up and
suggested a patch. I guess it is because the defined set of properties
is too limited to be really usefull as a replacement for environment
variables.

regards,
finn

Re: [Jython-dev] jythons module os

[dman <ds...@ri...>]

On Thu, Nov 01, 2001 at 05:08:06PM +0000, Finn Bock wrote:
| On Thu, 1 Nov 2001 10:26:25 -0500, you wrote:
| 
| >On Thu, Nov 01, 2001 at 03:14:17PM +0000, Finn Bock wrote:
| >| [Phil Surette]
| > 
| >| >I haven't thought writing through yet, but I figure 
| >| >reading will hit a large percentage of the use cases.
| >| 
| >| Writing is normally done by inserting values in the os.environment dict
| >| and using that dict for the os.system() call. We can't possibly do any
| >| better in core jython.
| >
| >How does os.setenv() figure into this? 
| 
| I guess you mean os.putenv()?

Umm ... <checks docs> ... yeah, I didn't look at the docs before I
posted -- I always mess up the name one way or another.

| >I imagine that this operation is probably not possible in Java,
| 
| Right.
| 
| >thus the call should either silently
| >ignore it, or raise an exception.
| 
| Either os.putenv() shouldn't be implemented at all or it should be
| implemented as:
| 
| def putenv(varname, value):
|    os.enviroment[varname] = value

This depends on what the semantics of os.environ should be.  In
CPython, the line 
    os.environ[ key ] = value
doesn't work.  At least, it _may_ change theh dict, but it has no
effect on the environment.

| >I was thinking that, perhaps, some environment values can be gotten
| >from Java directly.  For example,
| >
| >    print os.eviron[ "HOME" ]
| >
| >    could be the same as
| >
| >    System.out.println( System.getProperty( "user.home" ) ) ;
| >
| >though on some JVMs, user.home is really messed up (ex, jdk1.1.8 on
| >win).  I think Java ignores the user's preferences (ie setting $HOME
| >in bash or cmd.exe) and using whatever it feels like, so this may not
| >be a good idea.
| 
| The property route should not be mixed with the "sh -c env" route. Using

Ahh, I see, _that's_ how you get ahold of the data!

| properties have been mentioned before, but nobody have picked it up and
| suggested a patch. I guess it is because the defined set of properties
| is too limited to be really usefull as a replacement for environment
| variables.

I am using Moshe's PMS framework with Jython right now for a school
project.  My group has not used python at all, but is familiar with
Java hence the choice to use Jython.  Anyways, in the system as it is
shipped, there is the line

    DIR = os.path.join( os.environ[ "HOME" ] , "something" )

when it threw an exception, I decided to quickly wrap it in a
try-except and use java's system property (this maintains
compatibility with CPython, though I doubt Moshe would like a patch
like that).  It works for now, though I agree that java's system
properties are no replacement for the environment.

-D

Re: [Jython-dev] jythons module os

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

>| 
>| Either os.putenv() shouldn't be implemented at all or it should be
>| implemented as:
>| 
>| def putenv(varname, value):
>|    os.enviroment[varname] = value

[dman]

>This depends on what the semantics of os.environ should be.  In
>CPython, the line 
>    os.environ[ key ] = value
>doesn't work.  At least, it _may_ change theh dict, but it has no
>effect on the environment.

On my win2k box it changes the environment for subsequent os.system()
calls. That is the main thing I would expect it to do:

[d:\]\python\Python211\python.exe
Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['ZZZZ'] = "new value"
>>> os.system("set")
=C:=C:\
=D:=D:\
...
windir=C:\WINNT
ZZZZ=new value
0
>>>

>| >I was thinking that, perhaps, some environment values can be gotten
>| >from Java directly.  For example,
>| >
>| >    print os.eviron[ "HOME" ]
>| >
>| >    could be the same as
>| >
>| >    System.out.println( System.getProperty( "user.home" ) ) ;
>| >
>| >though on some JVMs, user.home is really messed up (ex, jdk1.1.8 on
>| >win).  I think Java ignores the user's preferences (ie setting $HOME
>| >in bash or cmd.exe) and using whatever it feels like, so this may not
>| >be a good idea.
>| 
>| The property route should not be mixed with the "sh -c env" route. Using
>
>Ahh, I see, _that's_ how you get ahold of the data!
>
>| properties have been mentioned before, but nobody have picked it up and
>| suggested a patch. I guess it is because the defined set of properties
>| is too limited to be really usefull as a replacement for environment
>| variables.
>
>I am using Moshe's PMS framework with Jython right now for a school
>project.  My group has not used python at all, but is familiar with
>Java hence the choice to use Jython.  Anyways, in the system as it is
>shipped, there is the line
>
>    DIR = os.path.join( os.environ[ "HOME" ] , "something" )

Yeah, I expect that is a common usage. Maybe we ought to have a way of
supporting it for $HOME and $USER. Maybe $CLASSPATH. Any other common
names?

regards,
finn