jython-users — Discussion of and questions about using Jython

Re: [Jython-users] jythonc not working -- solved, but strange

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

On Wed, Nov 28, 2001 at 07:58:47AM +0100, Humbel Otmar wrote:
| [ Finn Bock ]
| 
| > Non-ascii chars in identifiers? I know CPython sometimes 
| > allow that, but
| > that is not a feature I plan on adding.
| 
| please please NEVER even think of allowing that. Avoid special
| characters (as Umlaute) as long as you can - they simply kill developer
| productivity.

Could you give an example?

I would have thought that allowing non-english developers to use their
native language would be nice, but I'm just a "dumb american" (if you
know what I mean) so it really doesn't hurt me either way.

-D

-- 

Windows, hmmm, does it come with a GUI interface that works or just
pretty blue screens?

RE: [Jython-users] jythonc not working -- solved, but strange

[Humbel O. <Otm...@bi...>]

[ Finn Bock ]

> Non-ascii chars in identifiers? I know CPython sometimes=20
> allow that, but
> that is not a feature I plan on adding.

please please NEVER even think of allowing that. Avoid special
characters (as Umlaute) as long as you can - they simply kill developer
productivity.

Thanks !
Oti,

Re: [Jython-users] java->python problems : cause identified, bug in jython[c]

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

[dman]
> On Tue, Nov 27, 2001 at 05:43:48PM -0600, Peter Brinkmann wrote:
> |
> | Hi!
> |
> | On Tue, Nov 27, 2001 at 06:23:08PM -0500, dman wrote:
> | > I have now isolated the exact conditions which cause this problem.  If
> | > the python class name is the same as the module name, and it is in a
> | > python package, then the problem occurs.
> |
> | This sounds awfully familiar. I submitted a similar bug report
> | (jython-Bugs-451746) a while ago, and Samuele Pedroni has since
> | fixed it.
>
> It looks like you are reporting a different manifestation of the same
> bug (it appears that 2.1a3 ends up overwriting the module class with
> the class class or something similar).
>
> Samuele already responded saying he followed my instructions (he didn't have
> my example source) but couldn't reproduce it with the CVS version of
> jython.
>
>
> [in repsonse to my post]
> The report submission was successful, though the example attachment
> wasn't.  I added a comment to my report with a URL to retrieve the
> example source from.
>

After a )renaming package to pkg (package is a Java keyword !)
b) jythonc -deep
...
c) import PythonClass changed in import pkg.PythonClass in Main.java
d) compiling Main.java

;-)

C:\exp\jc3\example>java -Dpython.home=\jython -classpath \jython;jpywork;. Main
hello world
done

So I will close the bug.

regards, Samuele.

Re: [Jython-users] java->python problems : cause identified, bug in jython[c]

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

On Tue, Nov 27, 2001 at 05:43:48PM -0600, Peter Brinkmann wrote:
| 
| Hi!
| 
| On Tue, Nov 27, 2001 at 06:23:08PM -0500, dman wrote:
| > I have now isolated the exact conditions which cause this problem.  If
| > the python class name is the same as the module name, and it is in a
| > python package, then the problem occurs.
| 
| This sounds awfully familiar. I submitted a similar bug report
| (jython-Bugs-451746) a while ago, and Samuele Pedroni has since
| fixed it.

It looks like you are reporting a different manifestation of the same
bug (it appears that 2.1a3 ends up overwriting the module class with
the class class or something similar).

Samuele already responded saying he followed my instructions (he didn't have
my example source) but couldn't reproduce it with the CVS version of
jython.


[in repsonse to my post]
The report submission was successful, though the example attachment
wasn't.  I added a comment to my report with a URL to retrieve the
example source from.


-D

-- 

A)bort, R)etry, D)o it right this time

Re: [Jython-users] java->python problems : cause identified, bug in jython[c]

[Peter B. <bri...@ma...>]

Hi!

On Tue, Nov 27, 2001 at 06:23:08PM -0500, dman wrote:
> I have now isolated the exact conditions which cause this problem.  If
> the python class name is the same as the module name, and it is in a
> python package, then the problem occurs.

This sounds awfully familiar. I submitted a similar bug report
(jython-Bugs-451746) a while ago, and Samuele Pedroni has since
fixed it.
Best,
	Peter

Re: [Jython-users] java->python problems : cause identified, bug in jython[c]

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

On Tue, Nov 13, 2001 at 07:30:38PM +0000, Finn Bock wrote:
| [dman]
| 
| >I have now identified the source of the problem and I think it is a
| >bug in jython/jythonc.
| >
| >...
| >
| >I then took the minimal sample that did work and put 2 of the python
| >...
| 
| Could you please make a bugreport that includes the minimal sample.
| 
| I have lost track of the issue and without a bugreport I can safely
| predict that the bug will never be fixed.

I have now isolated the exact conditions which cause this problem.  If
the python class name is the same as the module name, and it is in a
python package, then the problem occurs.

I tried submitting a bug report (with a file attachment) but got the
following instead of the confirmation page :


Fatal error: Call to a member function on a non-object in common/tracker/ArtifactFile.class on line 106


When I tried going back and pressing submit again, I was told I had
already submitted it and I should try double-submitting.  I haven't
yet gotten the mail from SF telling me that I submitted the report and
I don't see it listed in the browse section yet.  I can open a new
report if you would like me to.

-D

-- 

If we confess our sins, He is faithful and just and will forgive us our
sins and purify us from all unrighteousness.
        I John 1:9

[Jython-users] O'Reilly Jython Essentials book

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

Yup, I should declare myself guilty <wink>.

(Thanks to Noel Rappin. And Laura Lewin who
stands behind this)

----- Original Message ----- 
From: Laura Lewin <LL...@or...>
Newsgroups: comp.lang.python
Sent: Monday, November 26, 2001 2:14 PM
Subject: Re: 11-15 new Python Books on the way! (fwd)


> This is a great list!  You can also add Jython Essentials, O'Reilly,
> Samuele Pedroni and Noel Rappin.  The book is due out in March.
> Laura
> LL...@or...
> 
> > Ron Stephens <rd...@ea...> wrote:
> > |Truly a surfeit of books. But, for what it is worth, I have listed all I
> > |could find out about them all at http://www.awaretek.com/plf.html
> >

Re: [Jython-users] stream munging

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

[me]

>Naturally [utf-8 and utf-16-be] are totally useless ways of storing 
>a eurosign on my harddisc. 

[dman]

>Why?  If all (relevant) programs read the data as UTF-8 (or UTF-16-be)
>then they would all see the same character.

True. If that ever happen, we can all reap the benefits.

>| So is latin-1 btw:
>| 
>| >>> u"\u20ac".encode("latin1")
>| Traceback (most recent call last):
>|   File "<stdin>", line 1, in ?
>| UnicodeError: Latin-1 encoding error: ordinal not in range(256)
>
>Latin1 doesn't have a eurosign, does it?

No.

>| The only true and sane encoding to use for windows machines in euroland
>| is cp1252:
>| 
>| >>> u"\u20ac".encode("cp1252")
>| '\x80'
>
>I don't see how that is better than the above values, except that is
>is likely all other windows programs use cp1252 as well, and thus they
>can understand it.

Exactly.

regards,
finn

Re: [Jython-users] jythonc not working -- solved, but strange

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

[dman]

>| As an additional information point, my JDK1.2 and JDK1.3 also throws
>| exceptions, but JDK1.4 silently transform the character into the
>| unicode-undefined character.
>
>I'm not sure that is a good thing (jdk1.4), but maybe you don't have
>to deal with it.  Consider someone who has some source in latin1 (or
>something else) and has
>
>a=F6c =3D "foo"
>a=FCc =3D "bar"

[I find it a little ironic that my mail agent can't deal any of the
newer mail encodings]

>If java uses UTF-8 as the encoding, then those two names 

Non-ascii chars in identifiers? I know CPython sometimes allow that, but
that is not a feature I plan on adding.

>will end up
>being the same if jython will treat the unicode-undefined character as
>a regular character. This would be an additional condition that
>should raise an exception.

If you put the non-ascii chars inside the quotes then I agree with your
example and with your conclusion.

>| Yes. The generated tokenmanager catches all IOExceptions
>| (MalformedInputException is a subclass of IOException) and interprets
>| that as eof.
> [...]
>
>Couldn't you just catch that exception and print out a message then
>exit right before catching IOException?  

There are 43 instances of caught IOException in
PythonGrammerTokenManager such as:

   try { curChar = input_stream.readChar(); }
   catch(java.io.IOException e) {
      jjStopStringLiteralDfa_10(0, 0L, active1);
      return 1;
   }

We probably have to catch the MalformedInputException in the
ReaderCharStream and throw something that will get passed most of the
catch clauses in the parser.

regards,
finn

Re: [Jython-users] stream munging

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

On Mon, Nov 26, 2001 at 07:57:43PM +0000, Finn Bock wrote:
| [dman]
| 
| >|   f.write(u"\u20AC")
| >
| >When viewed as a "unicode string" object, it does contain just one
| >character.  However in memory it consists of 2 bytes, right?
| 
| Sure. At least for java strings. Sometimes it fills 4 bytes on some
| CPython compilations.
| 
| >Wouldn't
| >    f.write( chr( 0x20 ) )
| >    f.write( chr( 0xAC ) )
| >
| >produce the same results, if the above write is done with a utf-8
| >encoding?
| 
| No. An utf-8 encoding gives (using cpython-2.1):
| 
| >>> u"\u20ac".encode("utf-8")
| '\xe2\x82\xac'

Intersting.

| A utf-16-be encoding gives:
| 
| >>>u"\u20ac".encode("utf-16-be")
| ' \xac'
| 
| which is closer to what you seem to expect. 

Yeah, that's what I was thinking of.  (0x20 is the space character
when printed in ASCII)

| Naturally both are totally useless ways of storing a eurosign on my
| harddisc. 

Why?  If all (relevant) programs read the data as UTF-8 (or UTF-16-be)
then they would all see the same character.

| So is latin-1 btw:
| 
| >>> u"\u20ac".encode("latin1")
| Traceback (most recent call last):
|   File "<stdin>", line 1, in ?
| UnicodeError: Latin-1 encoding error: ordinal not in range(256)

Latin1 doesn't have a eurosign, does it?

| The only true and sane encoding to use for windows machines in euroland
| is cp1252:
| 
| >>> u"\u20ac".encode("cp1252")
| '\x80'

I don't see how that is better than the above values, except that is
is likely all other windows programs use cp1252 as well, and thus they
can understand it.

| >| If we did like CPython and refused to pick an encoding, jython would
| >| have a situation where it is *impossible* to write values above 127 to a
| >| file!
| >
| >Yeah, that doesn't sound like a good choice.  Isn't UTF-8 the new
| >standard, once people get around to converting everything?
| 
| UTF-8 is a fine way of representing unicode if you only ever use ascii
| characters <wink>.

Hehe.  I definitely need to learn more about it.

-D

-- 

"...In the UNIX world, people tend to interpret `non-technical user' as
meaning someone who's only ever written one device driver."
    --Daniel Pead

Re: [Jython-users] jythonc not working -- solved, but strange

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

On Mon, Nov 26, 2001 at 07:37:33PM +0000, Finn Bock wrote:
| [dman]
|=20
| >(
| >  Short version :
| >    jython gives no result when running scripts encoded in latin1 with
| >    non-ASCII chars in them.
| >)
|=20
| >| Whatever the encoding used is, it may be unable to handle 0xA9
| >| correctly:
| >
| >Perhaps, and perhaps java is broken?
|=20
| Don't think so. The first byte of a multibyte sequence must be in the
| range 0xC0 to 0xFD. So a file with a latin copyright character is not a
| valid UTF-8 text file.

At least someone here has read the spec :-).

| As an additional information point, my JDK1.2 and JDK1.3 also throws
| exceptions, but JDK1.4 silently transform the character into the
| unicode-undefined character.

I'm not sure that is a good thing (jdk1.4), but maybe you don't have
to deal with it.  Consider someone who has some source in latin1 (or
something else) and has

a=F6c =3D "foo"
a=FCc =3D "bar"


If java uses UTF-8 as the encoding, then those two names will end up
being the same if jython will treat the unicode-undefined character as
a regular character.  This would be an additional condition that
should raise an exception.

| >As you can see, CPython (2.2b1) has no problems with the script
| >regardless of environment and file encoding,=20
|=20
| That simplicity will not last. Eventually even CPython will have ways t=
o
| deal with the encoding of python source files.

Ok.

| >$ LANG=3Den_US.UTF-8 jython=20
| >Jython 2.1a1 on java1.3.1 (JIT: null)
| >>>> from java.io import *
| >>>> f =3D InputStreamReader( FileInputStream( "hello_latin1.py" ) )
| >>>> while 1 : print f.read()
| >...=20
| >10
| >35
| >Traceback (innermost last):
| >  File "<console>", line 1, in ?
| >sun.io.MalformedInputException
| >        at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:152)
| >
| >I'll attach the file so you can see it for yourself.  It looks like
| >jython catches this exception, but silently ignores it.
|=20
| Yes. The generated tokenmanager catches all IOExceptions
| (MalformedInputException is a subclass of IOException) and interprets
| that as eof.

EOF would certainly explain why I didn't get any output or error
message.  Jython successfully executed nothing :-).

| >Perhaps it would be a good idea to try and fall back to latin1,=20
|=20
| Nah, no guessing IMO.

Ok.

| >then display an error message if that fails too.
|=20
| That doesn't seem to be as easy as it rightly should have been.

Couldn't you just catch that exception and print out a message then
exit right before catching IOException?  It might be better to convert
the exception into a different (python) exception.  Yeah, for
execfile() the interpreter shouldn't exit because the file is encoded
wrong.

-D


--=20

"...the word HACK is used as a verb to indicate a massive amount
of nerd-like effort."  -Harley Hahn, A Student's Guide to Unix

Re: [Jython-users] stream munging

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

[dman]

>|   f.write(u"\u20AC")
>
>When viewed as a "unicode string" object, it does contain just one
>character.  However in memory it consists of 2 bytes, right?

Sure. At least for java strings. Sometimes it fills 4 bytes on some
CPython compilations.

>Wouldn't
>    f.write( chr( 0x20 ) )
>    f.write( chr( 0xAC ) )
>
>produce the same results, if the above write is done with a utf-8
>encoding?

No. An utf-8 encoding gives (using cpython-2.1):

>>> u"\u20ac".encode("utf-8")
'\xe2\x82\xac'

A utf-16-be encoding gives:

>>>u"\u20ac".encode("utf-16-be")
' \xac'

which is closer to what you seem to expect. Naturally both are totally
useless ways of storing a eurosign on my harddisc. So is latin-1 btw:

>>> u"\u20ac".encode("latin1")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: Latin-1 encoding error: ordinal not in range(256)

The only true and sane encoding to use for windows machines in euroland
is cp1252:

>>> u"\u20ac".encode("cp1252")
'\x80'

>| If we did like CPython and refused to pick an encoding, jython would
>| have a situation where it is *impossible* to write values above 127 to a
>| file!
>
>Yeah, that doesn't sound like a good choice.  Isn't UTF-8 the new
>standard, once people get around to converting everything?

UTF-8 is a fine way of representing unicode if you only ever use ascii
characters <wink>.

regards,
finn

Re: [Jython-users] jythonc not working -- solved, but strange

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

[dman]

>(
>  Short version :
>    jython gives no result when running scripts encoded in latin1 with
>    non-ASCII chars in them.
>)

>| Whatever the encoding used is, it may be unable to handle 0xA9
>| correctly:
>
>Perhaps, and perhaps java is broken?

Don't think so. The first byte of a multibyte sequence must be in the
range 0xC0 to 0xFD. So a file with a latin copyright character is not a
valid UTF-8 text file.

As an additional information point, my JDK1.2 and JDK1.3 also throws
exceptions, but JDK1.4 silently transform the character into the
unicode-undefined character.

>As you can see, CPython (2.2b1) has no problems with the script
>regardless of environment and file encoding, 

That simplicity will not last. Eventually even CPython will have ways to
deal with the encoding of python source files.

>$ LANG=en_US.UTF-8 jython 
>Jython 2.1a1 on java1.3.1 (JIT: null)
>>>> from java.io import *
>>>> f = InputStreamReader( FileInputStream( "hello_latin1.py" ) )
>>>> while 1 : print f.read()
>... 
>10
>35
>Traceback (innermost last):
>  File "<console>", line 1, in ?
>sun.io.MalformedInputException
>        at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:152)
>
>I'll attach the file so you can see it for yourself.  It looks like
>jython catches this exception, but silently ignores it.

Yes. The generated tokenmanager catches all IOExceptions
(MalformedInputException is a subclass of IOException) and interprets
that as eof.

>Perhaps it would be a good idea to try and fall back to latin1, 

Nah, no guessing IMO.

>then display an error message if that fails too.

That doesn't seem to be as easy as it rightly should have been.

regards,
finn

Re: [Jython-users] stream munging

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

On Mon, Nov 26, 2001 at 06:00:23PM +0000, Finn Bock wrote:
| 
| >| Not sure about the reason for the new-line algorithm; it isn't my design
| >| or code. I guess it is partly based on the windows way and partly on the
| >| way java handle line seperator when doing line reading. Maybe JimH have
| >| used a timemachine to implement a sane scheme for dealing with cross
| >| platform text files several years before CPython got around to it.
| >
| >Hehe.  Honestly, though, I really don't understand why text files must
| >be treated specially.  Shouldn't there be a mode for fopen() to
| >return a JPEG file or an MP3 file?  Obviously not, so why should text
| >be any different?
| 
| If you want textfile handling to be crossplatform then some of the
| platforms have to surrender to a common minimum. In that fight, unix
| have won with its line-feed standard.
| 
| Either programmers have to deal with open-modes for files or they have
| to deal with strange line endings.
| 
| >I think that the system-level handling of files
| >should consider a file as nothing more than a series of bytes.
| 
| Sure, but it is a little to late to demand that Microsoft remove the
| open mode from their file support.
| 
| >Their
| >meaning should be left up to the application programmer, who will use
| >routines to properly serialize in-memory data to and from the file.
| >If one programmer wants the files to have CRLF periodically, then it
| >is his job to wrap the file with a filter.  Also, I think that text
| >files should have a uniform format, 
| 
| What! and give up on incompatible ways of doing straightforward things?
| Where is the challenge in that <wink>? You might as well wish for a
| consistent way of separating path names with forward slashes! sheesh.


:-).


| >| >I don't really understand much of Java's java.io package, other than
| >| >it takes some work to figure out which class has the method that does
| >| >what you want.  IMO Python's read() and readline() methods are so much
| >| >simpler and get the job done just as well.
| >| 
| >| No it doesn't. At least not when you try to combine unicode strings and
| >| file I/O. When you don't need unicode then I agree that CPython-1.5.2
| >| was very simple to use.
| >| 
| >| But in jython it is impossible to ignore the unicode problems because
| >| all our strings are always unicode enabled. Image that you have a string
| >| with a non-latin-1 character in it, a euro-sign for example. What should
| >| happen when we try to write that to a file?
| >| 
| >|    f.write(u"\u20AC")
| >
| >Hmm, I think I would have to learn more about unicode in order to
| >answer that.  I would have thought that it should simply write out the
| >bytes 
| 
| That is probably a crucial mistake in your thinking (IMO). The string
| above does not contain bytes at all. It contains just one character
| element. 


When viewed as a "unicode string" object, it does contain just one
character.  However in memory it consists of 2 bytes, right?  Wouldn't
    f.write( chr( 0x20 ) )
    f.write( chr( 0xAC ) )

produce the same results, if the above write is done with a utf-8
encoding?


I do have a lot to learn wrt to unicode, though.


| >as it sees them since the file object isn't supposed to
| >second-guess what the programmer really meant when he said to write
| >that data.
| 
| When you think of it as bytes, it is not unicode anymore but some
| encoding of the unicode string. Every JVM comes with a huge list of
| different codecs.
| 
| > http://java.sun.com/products/jdk/1.2/docs/guide/internat/encoding.doc.html
| 
| If jython have to pick one these codecs it simple have to be the default
| codec for the platform. (As set in the "file.encoding" system property).
| IMHO it does not make any sense at all to pick some other encoding
| randomly from the list. [I know several CPython developers would
| disagree]
| 
| If we did like CPython and refused to pick an encoding, jython would
| have a situation where it is *impossible* to write values above 127 to a
| file!

Yeah, that doesn't sound like a good choice.  Isn't UTF-8 the new
standard, once people get around to converting everything?

-D

(the sig is randomly chosen, rather appropriate for this discussion,
 don't you think?)

-- 

A)bort, R)etry, D)o it right this time

Re: [Jython-users] stream munging : breaks imaplib (patch included)

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

>| Not sure about the reason for the new-line algorithm; it isn't my design
>| or code. I guess it is partly based on the windows way and partly on the
>| way java handle line seperator when doing line reading. Maybe JimH have
>| used a timemachine to implement a sane scheme for dealing with cross
>| platform text files several years before CPython got around to it.
>
>Hehe.  Honestly, though, I really don't understand why text files must
>be treated specially.  Shouldn't there be a mode for fopen() to
>return a JPEG file or an MP3 file?  Obviously not, so why should text
>be any different?

If you want textfile handling to be crossplatform then some of the
platforms have to surrender to a common minimum. In that fight, unix
have won with its line-feed standard.

Either programmers have to deal with open-modes for files or they have
to deal with strange line endings.

>I think that the system-level handling of files
>should consider a file as nothing more than a series of bytes.

Sure, but it is a little to late to demand that Microsoft remove the
open mode from their file support.

>Their
>meaning should be left up to the application programmer, who will use
>routines to properly serialize in-memory data to and from the file.
>If one programmer wants the files to have CRLF periodically, then it
>is his job to wrap the file with a filter.  Also, I think that text
>files should have a uniform format, 

What! and give up on incompatible ways of doing straightforward things?
Where is the challenge in that <wink>? You might as well wish for a
consistent way of separating path names with forward slashes! sheesh.

>| >I don't really understand much of Java's java.io package, other than
>| >it takes some work to figure out which class has the method that does
>| >what you want.  IMO Python's read() and readline() methods are so much
>| >simpler and get the job done just as well.
>| 
>| No it doesn't. At least not when you try to combine unicode strings and
>| file I/O. When you don't need unicode then I agree that CPython-1.5.2
>| was very simple to use.
>| 
>| But in jython it is impossible to ignore the unicode problems because
>| all our strings are always unicode enabled. Image that you have a string
>| with a non-latin-1 character in it, a euro-sign for example. What should
>| happen when we try to write that to a file?
>| 
>|    f.write(u"\u20AC")
>
>Hmm, I think I would have to learn more about unicode in order to
>answer that.  I would have thought that it should simply write out the
>bytes 

That is probably a crucial mistake in your thinking (IMO). The string
above does not contain bytes at all. It contains just one character
element. 

>as it sees them since the file object isn't supposed to
>second-guess what the programmer really meant when he said to write
>that data.

When you think of it as bytes, it is not unicode anymore but some
encoding of the unicode string. Every JVM comes with a huge list of
different codecs.

> http://java.sun.com/products/jdk/1.2/docs/guide/internat/encoding.doc.html

If jython have to pick one these codecs it simple have to be the default
codec for the platform. (As set in the "file.encoding" system property).
IMHO it does not make any sense at all to pick some other encoding
randomly from the list. [I know several CPython developers would
disagree]

If we did like CPython and refused to pick an encoding, jython would
have a situation where it is *impossible* to write values above 127 to a
file!

regards,
finn

Re: [Jython-users] jythonc not working -- solved, but strange

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

On Mon, Nov 26, 2001 at 03:58:39PM +0000, Finn Bock wrote:
| [dman]

(
  Short version :
    jython gives no result when running scripts encoded in latin1 with
    non-ASCII chars in them.
)

| >What difference does it make to jython whether a (python) source file
| >is saved in latin1 or utf-8?  In any case, I think it is a gross error
| >to simply terminate with no message when encountering a file that it
| >doesn't like.
| 
| Sure. Normally jython doesn't. So what is special about woody?

See below.  I have now figured out the source of this problem.

| >I started the conversion to utf-8 from main.py,
| 
| I have now removed the latin-1 copyright character in the CVS version.

Cool.  That will certainly fix all portability problems since ASCII is
a common subset of all encodings AFAIK (latin1 and utf-8 for sure).

| >...
| >The interesting thing about jythonc's source files is that they all
| >have the copyright symbol in a comment at the top of the file.  In
| >'latin1' this is character 0xa9.  
| 
| The python source files is read as text files with a InputStreamReader
| using the default encoding for the platform. Normally that is a good way
| to read text files but a sideeffect is that python source programs with
| non-ascii characters isn't portable to other platforms with a different
| encoding.
| 
| I don't know what the cause is, but these experiments might help shed
| light on it.
| 
| What file encoding is used in your setup of woody?
| 
| >>> import java
| >>> java.lang.System.getProperty("file.encoding")
| 'Cp1252'
| >>>

The woody machine I have at work had no problems running jythonc, just
my machine at home.  I remembered late last night that I had set $LANG
to en_US.UTF-8 at home.  Now that I am at work, I checked with that
machine and it has $LANG set to the default of "C".  If I tried
"LANG=en_US.UTF-8 jythonc --help" it failed the same as it was doing
at home.

With LANG=C, the enconding used by java is "ISO-8859-1", with
LANG=en_US.UTF-8 the enconding is "UTF-8".

| Whatever the encoding used is, it may be unable to handle 0xA9
| correctly:

Perhaps, and perhaps java is broken?

I created "hello world" with the copyright symbol in a comment.  I did
this with both latin1 and utf-8.

$ LANG=en_US python2.2 hello_latin1.py 
hello world

$ LANG=en_US python2.2 hello_utf-8.py 
hello world

$ LANG=en_US.UTF-8 python2.2 hello_latin1.py 
hello world

$ LANG=en_US.UTF-8 python2.2 hello_utf-8.py 
hello world

$ LANG=en_US jython hello_latin1.py 
hello world

$ LANG=en_US jython hello_utf-8.py 
hello world

$ LANG=en_US.UTF-8 jython hello_latin1.py

$ LANG=en_US.UTF-8 jython hello_utf-8.py 
hello world

$


As you can see, CPython (2.2b1) has no problems with the script
regardless of environment and file encoding, however Java can't handle
a latin1 file with the environment set to UTF-8.

I should do some experiments at the Java level and see what it does in
that situation.  Maybe it causes a problem in Jython's parsing (ie the
comments ends up extending to the end of the file) or maybe there is
some error that is silenty ignored.

| >>> from java import io
| >>> s = io.FileOutputStream("foo")
| >>> s.write("\xA9")
| >>> s.close()
| >>> s = io.FileReader("foo")
| >>> print hex(s.read())
| 0xa9
| >>> s.close()
| >>>

I just did a quick test using jython (interactive coding is very
cool!) :


$ LANG=en_US.UTF-8 jython 
Jython 2.1a1 on java1.3.1 (JIT: null)
>>> from java.io import *
>>> f = InputStreamReader( FileInputStream( "hello_latin1.py" ) )
>>> while 1 : print f.read()
... 
10
35
Traceback (innermost last):
  File "<console>", line 1, in ?
sun.io.MalformedInputException
        at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:152)
        at java.io.InputStreamReader.convertInto(InputStreamReader.java:137)
        at java.io.InputStreamReader.fill(InputStreamReader.java:166)
        at java.io.InputStreamReader.read(InputStreamReader.java:249)
        at java.io.InputStreamReader.read(InputStreamReader.java:222)
        at java.lang.reflect.Method.invoke(Native Method)
        at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:160)
        at org.python.core.PyMethod.__call__(PyMethod.java:96)
        at org.python.core.PyObject.__call__(PyObject.java:262)
        at org.python.core.PyInstance.invoke(PyInstance.java:244)
        at org.python.pycode._pyx3.f$0(<console>:1)
        at org.python.pycode._pyx3.call_function(<console>)
        at org.python.core.PyTableCode.call(PyTableCode.java:198)
        at org.python.core.PyCode.call(PyCode.java:13)
        at org.python.core.Py.runCode(Py.java:1075)
        at org.python.core.Py.exec(Py.java:1096)
        at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:145)
        at org.python.util.InteractiveInterpreter.runcode(InteractiveInterpreter.java:87)
        at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java:68)
        at org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.java:42)
        at org.python.util.InteractiveConsole.push(InteractiveConsole.java:83)
        at org.python.util.InteractiveConsole.interact(InteractiveConsole.java:62)
        at org.python.util.jython.main(jython.java:183)

sun.io.MalformedInputException: sun.io.MalformedInputException
>>> 


I'll attach the file so you can see it for yourself.  It looks like
jython catches this exception, but silently ignores it.  Perhaps it
would be a good idea to try and fall back to latin1, then display an
error message if that fails too.

| >I use (g)vim 6.0 as my editor.  As
| >you may already know it has two variables, 'enc' and 'fenc'.
| 
| You could change the file encoding of the source files. You would then

I did.

| have to change the encoding used by java as well. But I strongly doubt

It was already changed -- changing the encoding of the files caused
them to match the encoding java was using.

| that you want to go there. If latin1 is suitable for your country and
| language, stick with that.

I suppose maybe I should.  At least I know what to look for now if it
happens again :-).

-D

-- 

Even youths grow tired and weary,
    and young men stumble and fall;
but those who hope in the Lord 
    will renew their strength.
They will soar on wings like eagles;
    they will run and not grow weary,
    they will walk and not be faint.

        Isaiah 40:31

Re: [Jython-users] Can I use Numeric in Jython

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

[Calvin (Hoi Wai)]

>Greetings,
>    I had written a python class which use Numeric Python module. Now, I 
>wish to write an applet to act as a interface for this class. But I 
>don't know how to put the Python Numeric modules into the applet. Did 
>anyone try it and solve it? Please feel free to discuss the suggestion.

Perhaps this is usefull to you:

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

regards,
finn

[Jython-users] Re: Import strange error

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

>| My guess is that jython.jar exists in jre/lib/ext and that is the reason
>| that jython can only load other code that also reside on the
>| boot-classpath.
>
>Yes it actually is. I put everything I need in the jre/lib/ext dir to=20
>avoid classpath problems. Is there a side effect of putting jython in=20
>this directory? 

It seems like the classloader that is loading extentions does not itself
search the classpath.

I can't find a place in the Java documentation stating that it is the
case, but you can verify that it is by putting your Test.class in a .jar
file and copy the jar file to jre/lib/ext. I predict that the Test
program also fails then.

>I cannot see why putting the jython.jar in this=20
>directory would prevent to load classpath items physically located=20
>elsewhere?

It is the classloader that loaded the jython.jar that decides. When
running with jython.jar in my jre/liv/ext, I get see that it is an
ExtClassLoader that loaded jython.

Jython 2.1b1 on java1.4.0-beta3 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import org
>>> org.python.core.Py.classLoader
sun.misc.Launcher$ExtClassLoader@9fef6f

>>> I get:
>>> *sys-package-mgr*: processing new jar,=3D20
>>> =
>'/Users/spierre/Projects/SPEdit/prototype/build/SPEdit.app/Contents/Resour=
>=3D
>>> ces/Java/SPEdit.jar'
>>
>> Hmm, that output can't be from your little java program.
>
>Well I did not put anything else than the program. The jython.jar seems
>to be automatically loaded and processes the classpath items. 

Yuck.

>I think
>even if the -cp option is specified the jvm goes looking into the=20
>/jre/lib/ext. This is strange but understandable...

That part is documented:

   http://java.sun.com/docs/books/tutorial/ext/basics/load.html

regards,
finn

Re: [Jython-users] jythonc not working -- solved, but strange

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

[dman]

>On one of my Debian woody boxes jythonc stopped working a while ago.
>Jython still worked, but running 'jythonc' would give no output.  I
>have now solved the problem, but I think it involves a bug in jython.
>
>I traced through how jythonc was supposed to be run -- it is pretty
>straightforward : jython is run with
>/usr/share/jython/Tools/jythonc/jythonc.py as the first argument (and
>any other arguments are passed to the script).  I added a print to the
>top of jythonc.py, but it wouldn't get printed.  It was really strange
>because I could create a "hello world" program and it would work.  As
>I took a deeper look, looking at main.py I noticed that there were
>several Form Feed characters in it.  I removed those (from the other
>source files as well) but those had no bearing on my problem.  (I
>don't think there is a reason to have form feeds anyways, unless
>perhaps one intends to "cat <source> > /dev/lp0" with an old printer)
>The solution, as it turned out, was to open each of the source files,
>convert them to utf-8 and save them again.
>
>What difference does it make to jython whether a (python) source file
>is saved in latin1 or utf-8?  In any case, I think it is a gross error
>to simply terminate with no message when encountering a file that it
>doesn't like.

Sure. Normally jython doesn't. So what is special about woody?

>I started the conversion to utf-8 from main.py,

I have now removed the latin-1 copyright character in the CVS version.

>...
>The interesting thing about jythonc's source files is that they all
>have the copyright symbol in a comment at the top of the file.  In
>'latin1' this is character 0xa9.  

The python source files is read as text files with a InputStreamReader
using the default encoding for the platform. Normally that is a good way
to read text files but a sideeffect is that python source programs with
non-ascii characters isn't portable to other platforms with a different
encoding.

I don't know what the cause is, but these experiments might help shed
light on it.

What file encoding is used in your setup of woody?

>>> import java
>>> java.lang.System.getProperty("file.encoding")
'Cp1252'
>>>


Whatever the encoding used is, it may be unable to handle 0xA9
correctly:

>>> from java import io
>>> s = io.FileOutputStream("foo")
>>> s.write("\xA9")
>>> s.close()
>>> s = io.FileReader("foo")
>>> print hex(s.read())
0xa9
>>> s.close()
>>>


>I use (g)vim 6.0 as my editor.  As
>you may already know it has two variables, 'enc' and 'fenc'.

You could change the file encoding of the source files. You would then
have to change the encoding used by java as well. But I strongly doubt
that you want to go there. If latin1 is suitable for your country and
language, stick with that.

regards,
finn

[Jython-users] Re: Import strange error

[<sp...@is...>]

Le lundi 26 novembre 2001, =E0 04:10 PM, Finn Bock a =E9crit :
> How does java find jython.jar with that command line?
>
> Is jython.jar located in the jre/lib/ext directory? It probably
> shouldn't be.
[..]
| My guess is that jython.jar exists in jre/lib/ext and that is the=20
reason
| that jython can only load other code that also reside on the
| boot-classpath.

Yes it actually is. I put everything I need in the jre/lib/ext dir to=20
avoid classpath problems. Is there a side effect of putting jython in=20
this directory? I cannot see why putting the jython.jar in this=20
directory would prevent to load classpath items physically located=20
elsewhere?

>> I have written the equivalent in Java:
>
> [...]
>
>> When I run it:
>> java -cp SPEdit.jar:. Test
>>
>> I get:
>> *sys-package-mgr*: processing new jar,=3D20
>> =
'/Users/spierre/Projects/SPEdit/prototype/build/SPEdit.app/Contents/Resour=
=3D
>> ces/Java/SPEdit.jar'
>
> Hmm, that output can't be from your little java program.

Well I did not put anything else than the program. The jython.jar seems=20=

to be automatically loaded and processes the classpath items. I think=20
even if the -cp option is specified the jvm goes looking into the=20
/jre/lib/ext. This is strange but understandable...maybe putting=20
everything in the ext directory is not that a good idea... I will try by=20=

moving the jython.jar and see what happens...

Thanks,
   -- S=E9bastien.

Re: [Jython-users] Re: Import strange error

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

[Sebastien Pierre]

>You pointed interesting things with the Java reflection. Here is what I=20=
>
>do:
> > java -Dpython.home=3D"/sw/share/jython" -cp SPEdit.jar=20
>org.python.util.jython -v

How does java find jython.jar with that command line?

Is jython.jar located in the jre/lib/ext directory? It probably
shouldn't be.

>But when I do:
>
> >>> import java
> >>> java.lang.Class.forName("net.sourceforge.spedit.app.Application")
>
>I get:
>Traceback (innermost last):
>   File "<console>", line 1, in ?
>java.lang.ClassNotFoundException: net.sourceforge.spedit.app.Application
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)

Since this doesn't work, there is no way jython can find the Application
class (We are ignoring sys.path loading here).

>Then I do:
> >>> import net
>import: 'net' as java package
> >>> dir(net.sourceforge.spedit.app)
>
>and I get :
>['Application', 'AuthorDisplay', 'DBView', 'NavigationTree', 'Pool',=20
>'__name__']
>
>This is quite strange as I have explicitely specified the SPEdit.jar as=20=
>
>a classpath item...The problem is solved when I put the SPEdit.jar into=20=
>
>the jre/lib/ext MacOS X equivalent.
>
>In this case Jython has managed to index the SPEdit.jar, which is shown=20=
>by the result of the dir function call, but Java itself is then unable=20=
>to locate the SPEdit.jar, as if the classpath has been reset by jython.

Nope, can't blame jython for this.

My guess is that jython.jar exists in jre/lib/ext and that is the reason
that jython can only load other code that also reside on the
boot-classpath.

>I have written the equivalent in Java:

[...]

>When I run it:
>java -cp SPEdit.jar:. Test
>
>I get:
>*sys-package-mgr*: processing new jar,=20
>'/Users/spierre/Projects/SPEdit/prototype/build/SPEdit.app/Contents/Resour=
>ces/Java/SPEdit.jar'

Hmm, that output can't be from your little java program.

>class net.sourceforge.spedit.app.Application
>
>So actually Java find the class. This seems to point that the bug may be=20=
>in Jython overriding in some way the class path, so that URLClassLoader=20=
>is unable to find the classes anymore.

regards,
finn

Re: [Jython-users] Re: Import strange error

[<sp...@is...>]

> So when the "import net.sourceforge.spedit.app" works it means that
> jython have found the SPEdit.jar file and scanned it.
>
> You can verify that the SPEdit classes can be found by the JVM with =
this
> code:
>
>>>> import java
>>>> java.lang.Class.forName("net.sourceforge.spedit.app.Application")
>
> That should take jython out of the equation and if it doesn't work it
> means you have not added SPEdit.jar to your OSX classpath correctly.

You pointed interesting things with the Java reflection. Here is what I=20=

do:
 > java -Dpython.home=3D"/sw/share/jython" -cp SPEdit.jar=20
org.python.util.jython -v

*sys-package-mgr*: processing modified jar,=20
=
'/Users/spierre/Projects/SPEdit/prototype/build/SPEdit.app/Contents/Resour=
ces/
Java/SPEdit.jar'
*sys-package-mgr*: rewriting cachefile for=20
=
'/Users/spierre/Projects/SPEdit/prototype/build/SPEdit.app/Contents/Resour=
ces/
Java/SPEdit.jar'
*sys-package-mgr*: writing modified index file

So here the jar that contains the classes I want is loaded.
But when I do:

 >>> import java
 >>> java.lang.Class.forName("net.sourceforge.spedit.app.Application")

I get:
Traceback (innermost last):
   File "<console>", line 1, in ?
java.lang.ClassNotFoundException: net.sourceforge.spedit.app.Application
         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
         at java.security.AccessController.doPrivileged(Native Method)
         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
         at java.lang.Class.forName0(Native Method)
         at java.lang.Class.forName(Class.java:120)
         at java.lang.reflect.Method.invoke(Native Method)
         at=20
=
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:158)=

         at=20
=
org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:166)=

         at org.python.core.PyObject.__call__(PyObject.java:272)
         at org.python.core.PyObject.invoke(PyObject.java:2105)
         at org.python.pycode._pyx2.f$0(<console>)
         at org.python.pycode._pyx2.call_function(<console>)
         at org.python.core.PyTableCode.call(PyTableCode.java:155)
         at org.python.core.Py.runCode(Py.java:1055)
         at org.python.core.Py.exec(Py.java:1076)
         at=20
org.python.util.PythonInterpreter.exec(PythonInterpreter.java:145)
         at=20
=
org.python.util.InteractiveInterpreter.runcode(InteractiveInterpreter.java=
:
87)
         at=20
=
org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.ja=
va:
68)
         at=20
=
org.python.util.InteractiveInterpreter.runsource(InteractiveInterpreter.ja=
va:
42)
         at=20
org.python.util.InteractiveConsole.push(InteractiveConsole.java:83)
         at=20
org.python.util.InteractiveConsole.interact(InteractiveConsole.java:62)
         at org.python.util.jython.main(jython.java:178)

java.lang.ClassNotFoundException: java.lang.ClassNotFoundException:=20
net.sourceforge.spedit.app.Application

Then I do:
 >>> import net
import: 'net' as java package
 >>> dir(net.sourceforge.spedit.app)

and I get :
['Application', 'AuthorDisplay', 'DBView', 'NavigationTree', 'Pool',=20
'__name__']

This is quite strange as I have explicitely specified the SPEdit.jar as=20=

a classpath item...The problem is solved when I put the SPEdit.jar into=20=

the jre/lib/ext MacOS X equivalent.

In this case Jython has managed to index the SPEdit.jar, which is shown=20=

by the result of the dir function call, but Java itself is then unable=20=

to locate the SPEdit.jar, as if the classpath has been reset by jython.

I have written the equivalent in Java:

class Test
{

         public static void main (String[] args)
         {
                 try
                 {
                        =20
=
System.out.println(Class.forName("net.sourceforge.spedit.app.Application")=

);
                 }
                 catch ( Exception e )
                 {
                         System.out.println("Class not=20
found.\n\t"+e.toString());
                         e.printStackTrace();
                 }
         }
}

When I run it:
java -cp SPEdit.jar:. Test

I get:
*sys-package-mgr*: processing new jar,=20
=
'/Users/spierre/Projects/SPEdit/prototype/build/SPEdit.app/Contents/Resour=
ces/
Java/SPEdit.jar'
class net.sourceforge.spedit.app.Application

So actually Java find the class. This seems to point that the bug may be=20=

in Jython overriding in some way the class path, so that URLClassLoader=20=

is unable to find the classes anymore.

Cheers,
   -- S=E9bastien.

Re: [Jython-users] Threads:-java.lang.ExceptionInInitializationError:java.lang.NullPointerException

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

[rohit seth]

>I am getting
>"java.lang.ExceptionInInitializationError:
>java.lang.NullPointerException
>at
>org.Python.core.PySystemState.<init>(PySystemState.java:158)
>at
>org.Python.util.PythonInterpreter.<init>(PythonInterpreter.java:67)
>at
>org.Python.util.PythonInterpreter.<init>(PythonInterpreter.java:45)
>at PyFactory.initialize(PyFactory.java 9)
>at A.run(A.java 9)
>
>The classes I am using are as follows(I have included
>only the required portion of the code):-

[A very good example snipped. This kind of bugs can be hell to track
down, but with your example it was very easy. Thanks]

>Pl explain the cause of the error. When I am creating
>and running only one thread then it works fine. But
>with more than one threads, it gives this exception.

As you have probably guessed, it is a synchronization bug in jython and
we will ofcourse add a fix to jython. Meanwhile you can change the
definition of your own PyFactory.initialize() to:

  public static synchronized void initialize() 
         throws ClassNotFoundException{
    pyInterp=new PythonInterpreter();
  }

as a workaround.

regards,
finn

Re: [Jython-users] Re: Import strange error

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

[Sebastien Pierre]

>I have made tests on a linux machine jdk-1.3.1/jython-2.1a3, I went fine
>with both SPEdit.jar in jre/lib/ext and in local dir with -cp option. So
>I can only conclude this is a MacOS X issue, but to submit a bug I have
>to understand why. I do not know how Jython does to get access classes
>in packages, but the think is that it is actually able to list the
>content of the package but cannot access it. What are the difference
>between the mechanims behind dir() and those involved in attributes
>resolution?

The difference is between package-loading and class-loading. The java
environment have no usefull way of detecting which classes exists in a
java package so Jython fake it by scanning all the .jar files and
directories it can find. Jython looks for the properties of:

>>> import java
>>> java.lang.System.getProperty("java.class.path")
'd:\\java\\jdk1.4\\jre\\lib\\rt.jar;.....'
>>> java.lang.System.getProperty("sun.boot.class.path")
'D:\\JAVA\\JDK1.4\\jre\\lib\\rt.jar;D:\\JAVA\\JDK1.4\\....'
>>> java.lang.System.getProperty("java.ext.dirs")
'D:\\JAVA\\JDK1.4\\jre\\lib\\ext'

So when the "import net.sourceforge.spedit.app" works it means that
jython have found the SPEdit.jar file and scanned it.

You can verify that the SPEdit classes can be found by the JVM with this
code:

>>>import java
>>>java.lang.Class.forName("net.sourceforge.spedit.app.Application")

That should take jython out of the equation and if it doesn't work it
means you have not added SPEdit.jar to your OSX classpath correctly.

regards,
finn

Re: [Jython-users] RE: newbie questions

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

[Dave]
>
>Any classes used by the client that won't be on the client's own
>classpath (typically anything outside of the java.something packages)
>has to be downloaded in this way, so if I'm using jython classes, I
>need to put the jython classes at http://mysite/codebase/org/python/
>and so on for various packages in the jython set. (Some browser
>clients will allow jar files to be spec'd in the codebase too, 

That is what the applet demos are using. From the applets/index.html
page:

<APPLET CODE="HelloWorld" WIDTH="160" HEIGHT="50"
        ARCHIVE="appletdemo.jar"
        NAME="HelloWorld"
        ALIGN="BOTTOM"
        alt="This browser doesn't support JDK 1.1 applets.">
 <PARAM NAME="cabbase0" VALUE="appletdemo.cab">
 <H3>Something has gone wrong loading this applet.</H3>
</APPLET>

>this varies fromimplementation to implementation: some allow zip 
>files, cab files, etc.. It's one part of browser compatibility hell, 
>I'm afraid - no easy answers here.)

Right. The appletdemos work for a large section of users, but we know it
does not work for all.

>As I see it, you could introduce jython via two routes:
>1] precompile the jython applets with jythonc and place them on server
>as above - making suire all jython classes are available too.

jythonc will do that with the --core option.

>2] Write an applet (in java or jython) that embeds a PythonInterpreter
>which can pull python code down off the network and execute it on the
>fly. How you deploy the python code is then up to you! From a quick
>look at the demos on the site, it looks like this is what the 
>JythonLoader applet does.

No.

It is possible to do that, but it will require classloader access rights
for the applet and it will only work for java2 VMs.

regards,
finn