From: Ype K. <yk...@xs...> - 2001-11-19 20:06:08
|
Finn, Some weeks ago I reported the bug below. I tried to isolate it but this proved to take too much of my time, given the workaround. Since the workaround is not really straightforward it might be worthwhile to somehow make it available until someone else runs into it the bug and is able to isolate it. The workaround is to use a method of an object as the trace function instead of a function defined in module scope. Is a bug report the right way to make the workaround available? Regards, Ype :( > >> >> > >> > >> >def tracer(frame, why, arg): >> > print why, frame.f_lineno, arg >> > return tracer >> > >> >def foo(): >> > for i in range(10): >> > a = "abc" >> > a = "Done" >> > >> >import sys >> >sys.settrace(tracer) >> >foo() >> >> I'll give it a try, >> > >This works fine when called interactively. >However when I use it via execfile() i get a: >NameError: tracer >on the "return tracer" statement. It is not only via execfile(), a lot more is going in between, ao. the dictionary against which the execfile() is executed is the __dict__ of a new.module(). This is used within several try/except and try/finally blocks on the stack frames of several method invocations. > >The following works when called via execfile(), >the interesting difference is probably the fact >that the tracer function is now not in a module >name space when returned for line tracing, >so I think there is a bug related to the new nested >namespaces in execfile(): I looked around in the jython source code for the nested scopes, but could not find anything that might relate to this. > > >class LineInfoCollector: > def __init__(self): > self.lineInfos = {} > > def addLineInfo(self, lineInfo): > self.lineInfos[lineInfo] = 1 > > def getLineInfos(self): > infos = self.lineInfos.keys() > infos.sort() > return infos > > def tracer(self, frame, why, arg): > self.addLineInfo((frame.f_code.co_filename, > frame.f_code.co_name, > frame.f_lineno, > why, arg)) > return self.tracer > >def foo(): > for i in range(2): > a = "abc" > a = "Done" > >if __name__ == '__main__': > import sys > > ltrac = LineInfoCollector() > sys.settrace(ltrac.tracer) > try: foo() > finally: sys.settrace(None) > > print 'Lines covered:' > for lineInfo in map(str, ltrac.getLineInfos()): > print lineInfo > |
From: Samuele P. <ped...@bl...> - 2001-11-19 20:42:11
|
Some notes: - if something goes wrong with Runtime.exec a java exception is thrown, I think this should be somehow wrapped in an os.error. Opinions? - in particular if something goes wrong when populating environ, we should decide whether to throw an exception or gracefully fall back to a NullEnv. - environ populating does not work (as far as my installation is concerned) with win 98: "command.com /c set should be invoked, "command /c set" fails. I think java version is also concerned here regarding to which extensions are tried and which os calls are made. I used jdk 1.3.0. Anyone did try this already with different results? regards, Samuele. |
From: Kevin B. <kev...@bi...> - 2001-11-20 05:52:48
|
Samuele Pedroni wrote: > Some notes: > > - if something goes wrong with Runtime.exec a java exception is thrown, > I think this should be somehow wrapped in an os.error. Opinions? Agreed. > - in particular if something goes wrong when populating environ, we should > decide whether to throw an exception or gracefully fall back to a NullEnv. I'm inclined to throw an OS exception here, too - let the user know that things aren't working as expected, and if the user wants to change configuration to use NullEnv, that's great. Should we be trying to provide some sort of meaningful 'errno' codes? I've just been raising OSError( 0...) like the other javaos functions... > - environ populating does not work (as far as my installation is concerned) > with win 98: > "command.com /c set should be invoked, "command /c set" fails. I get similar behavior on Win95/JDK1.1.8. (had to dig up my Win95 laptop & install a JDK (figured I'd install one I didn't have elsewhere), replace the old jpython installation w/ a new jython version, & get the new javaos.py... Speedy it was not...) > I think java version is also concerned here regarding to which extensions are > tried > and which os calls are made. I used jdk 1.3.0. > Anyone did try this already with different results? As is becoming all too frequent, here's a patch (but this is the last one for a long time... *wink*), and now __test() works on NT and 95 (somehow my Linux jython install is now giving 'AssertionError: SRE module mismatch', and I haven't chased that down yet). kb $ cvs diff -c javaos.py Index: javaos.py =================================================================== RCS file: /cvsroot/jython/jython/Lib/javaos.py,v retrieving revision 2.11 diff -c -r2.11 javaos.py *** javaos.py 2001/11/15 08:17:17 2.11 --- javaos.py 2001/11/20 05:49:10 *************** *** 23,29 **** "defpath", "name"] import java ! from java.io import File, BufferedReader, InputStreamReader import javapath as path from UserDict import UserDict import string --- 23,29 ---- "defpath", "name"] import java ! from java.io import File, BufferedReader, InputStreamReader, IOException import javapath as path from UserDict import UserDict import string *************** *** 35,44 **** error = OSError ! name = 'java' # descriminate based on JDK version? curdir = '.' ! pardir = '..' #This might not be right... ! #curdir, pardir?? sep = java.io.File.separator altsep = None pathsep = java.io.File.pathSeparator --- 35,43 ---- error = OSError ! name = 'java' # discriminate based on JDK version? curdir = '.' ! pardir = '..' sep = java.io.File.separator altsep = None pathsep = java.io.File.pathSeparator *************** *** 234,241 **** env = self._formatEnvironment( self.environment ) else: env = None ! p = java.lang.Runtime.getRuntime().exec( shellCmd, env ) ! return p ########## utility methods def _readLines( self, stream, func=None ): --- 233,243 ---- env = self._formatEnvironment( self.environment ) else: env = None ! try: ! p = java.lang.Runtime.getRuntime().exec( shellCmd, env ) ! return p ! except IOException: ! raise OSError( 0, "Failed to execute command: %s" % shellCmd ) ########## utility methods def _readLines( self, stream, func=None ): *************** *** 269,286 **** This allows multi-line variables as long as subsequent lines do not have '=' signs. """ ! p = self.execute( self.getEnv ) ! env = {} ! key = 'firstLine' # in case first line had no '=' ! for line in self._readLines( p.getInputStream() ): ! try: ! i = line.index( '=' ) ! key = self._keyTransform(line[:i]) ! value = line[i+1:] ! except ValueError: ! # found no '=', so this line is part of previous value ! value = '%s\n%s' % ( value, line ) ! env[ key ] = value return env def _getOsType( os=None ): --- 271,295 ---- This allows multi-line variables as long as subsequent lines do not have '=' signs. """ ! try: ! p = self.execute( self.getEnv ) ! env = {} ! for line in self._readLines( p.getInputStream() ): ! try: ! i = line.index( '=' ) ! key = self._keyTransform(line[:i]) ! value = line[i+1:] ! except ValueError: ! # found no '=', so this line is part of previous value ! value = '%s\n%s' % ( value, line ) ! env[ key ] = value ! except UnboundLocalError: ! # 'value' is unbound because we didn't find '=' on first line ! raise OSError( 0, ! "Command did not print environment.\n" ! "Command=%s\nOutput=%s\n" % ( ! self.getEnv, line ! )) return env def _getOsType( os=None ): *************** *** 312,318 **** if osType == "nt": return _ShellEnv( ["cmd", "/c"], "set", string.upper ) elif osType == "dos": ! return _ShellEnv( ["command", "/c"], "set", string.upper ) elif osType == "mac": return _NullEnv() else: # osType == "unix": --- 321,327 ---- if osType == "nt": return _ShellEnv( ["cmd", "/c"], "set", string.upper ) elif osType == "dos": ! return _ShellEnv( ["command.com", "/c"], "set", string.upper ) elif osType == "mac": return _NullEnv() else: # osType == "unix": *************** *** 348,356 **** # should print PATH (on NT) ("echo PATH=%PATH%", "(PATH=.*;.*)|(PATH=%PATH%)"), # should print 'testKey=%testKey%' on NT before initialization, # and 'testKey=testValue' after ("echo %s=%%%s%%" % (key,key), ! "(%s=%%%s%%)|(%s=%s)" % (key, key, key, value)), # should print PATH (on Unix) ( "echo PATH=$PATH", "PATH=.*" ), # should print 'testKey=testValue' on Unix after initialization --- 357,366 ---- # should print PATH (on NT) ("echo PATH=%PATH%", "(PATH=.*;.*)|(PATH=%PATH%)"), # should print 'testKey=%testKey%' on NT before initialization, + # should print 'testKey=' on 95 before initialization, # and 'testKey=testValue' after ("echo %s=%%%s%%" % (key,key), ! "(%s=)" % (key,)), # should print PATH (on Unix) ( "echo PATH=$PATH", "PATH=.*" ), # should print 'testKey=testValue' on Unix after initialization *************** *** 359,369 **** # should output quotes on NT but not on Unix ( 'echo "hello there"', '"?hello there"?' ), # should print 'why' to stdout. ! ( r'''python -c "import sys;sys.stdout.write( 'why\n' )"''', "why" ), # should print 'why' to stderr, but it won't right now. Have # to add the print to give some output...empty string matches every # thing... ! ( r'''python -c "import sys;sys.stderr.write('why\n');print " ''', "" ) ] assert not environ._populated, \ --- 369,379 ---- # should output quotes on NT but not on Unix ( 'echo "hello there"', '"?hello there"?' ), # should print 'why' to stdout. ! ( r'''jython -c "import sys;sys.stdout.write( 'why\n' )"''', "why" ), # should print 'why' to stderr, but it won't right now. Have # to add the print to give some output...empty string matches every # thing... ! ( r'''jython -c "import sys;sys.stderr.write('why\n');print " ''', "" ) ] assert not environ._populated, \ *************** *** 403,405 **** --- 413,431 ---- "expected environment to have PATH attribute " \ "(this may not apply to all platforms!)" + # attempt to get an environment with a shell that is not startable + try: + print _ShellEnv( ["badshell", "-c"], "set" ).environment + except OSError, val: + assert val.strerror.startswith( "Failed to execute" ) + print "caught correct error for bad shell" + + # attempt to get an environment with a command that does not print an environment + try: + se2 = _getShellEnv() + se2.getEnv="echo This command does not print environment" + print se2.environment + except OSError, val: + assert val.strerror.startswith( "Command did not" ) + print "caught correct error for bad command" + |
From: Kevin B. <kev...@bi...> - 2001-11-20 06:48:32
|
Kevin Butler wrote: > (somehow my Linux jython > install is now giving 'AssertionError: SRE module mismatch', and I haven't chased > that down yet). Looks like the reason is that I've installed python2.2 on this machine, so now jython is using the python2.2 sre, etc. modules, instead of python2.1 which I had been using. This causes a problem because the sre_constants 'MAGIC' number was bumped from 20010320 to 20010701. Seems like jython should probably ship with an sre_constants.py that is compatible with _sre? I assume the right thing to do for now would be to enhance the jython _sre module to be 20010701-compatible. Instead, I just modified my python.path in /usr/share/jython/registry to point to python2.1 instead of letting jython (somehow?) find python2.2... kb |
From: <bc...@wo...> - 2001-11-20 14:02:00
|
[Kevin Butler] > >> (somehow my Linux jython >> install is now giving 'AssertionError: SRE module mismatch', and I haven't chased >> that down yet). > >Looks like the reason is that I've installed python2.2 on this machine, so now jython >is using the python2.2 sre, etc. modules, instead of python2.1 which I had been using. > >This causes a problem because the sre_constants 'MAGIC' number was bumped from 20010320 >to 20010701. > >Seems like jython should probably ship with an sre_constants.py that is compatible with >_sre? It does. Jython-21a3 contains a sre magic of 20010320. The CVS version does not contain copies of CPython modules (except the module that we have had to modify to make them work with jython). >I assume the right thing to do for now would be to enhance the jython _sre module to be >20010701-compatible. Absolutely not. Jython-2.1 work with the modules form CPython-2.1.1. It is not tested or intended to work with CPython-2.2 modules. 20010701-compatibility should be added after the release of jython-2.1 final. >Instead, I just modified my python.path in /usr/share/jython/registry to point to >python2.1 And that is the right way to run the CVS version of jython. I do it by having this in my %HOME%/.jython file: python.path=d:\\python\\Python-2.1.1\\Lib >instead of letting jython (somehow?) find python2.2... How indeed! It should not attempt do that automaticly. Maybe it is done by site.py that is reading .pth files? regards, finn |
From: <bc...@wo...> - 2001-11-20 12:42:12
|
[Samuele Pedroni] > Some notes: > > - if something goes wrong with Runtime.exec a java exception is thrown, > I think this should be somehow wrapped in an os.error. Opinions? [Kevin Butler] >Agreed. Ok, as long as the os.error contain all the information from the java exception. Including information about the type of exception (IOException or SecurityException) and the exception message. The patch below doesn't and it certainly should. >> - in particular if something goes wrong when populating environ, we should >> decide whether to throw an exception or gracefully fall back to a NullEnv. > >I'm inclined to throw an OS exception here, too - let the user know that things >aren't working as expected, and if the user wants to change configuration to use >NullEnv, that's great. I agree. >Should we be trying to provide some sort of meaningful 'errno' codes? I've just >been raising OSError( 0...) like the other javaos functions... Good enough. The IOException thrown from exec() sometimes contain the operating system error code (as text). >> - environ populating does not work (as far as my installation is concerned) >> with win 98: >> "command.com /c set should be invoked, "command /c set" fails. > >I get similar behavior on Win95/JDK1.1.8. (had to dig up my Win95 laptop & install >a JDK (figured I'd install one I didn't have elsewhere), replace the old jpython >installation w/ a new jython version, & get the new javaos.py... Speedy it was >not...) Thats why I haven't touched added this feature myself. It is so easy to get working for oneself but so hard to get it working correctly for all. >As is becoming all too frequent, here's a patch (but this is the last one for a >long time... *wink*), Do you have a SF account? Make one and I'll add you as committer. Then you don't have to make excuses every time. >! pardir = '..' You think that is right on macs and AS/400? Maybe it actually is, but I doubt it. I liked the old defensive comment. >! except UnboundLocalError: >! # 'value' is unbound because we didn't find '=' on first line Maybe it is just my personal preference, but I would prefer an explicit test instead of catching UnboundLocalError. regards, finn |
From: Samuele P. <ped...@bl...> - 2001-11-20 13:11:05
|
> >I'm inclined to throw an OS exception here, too - let the user know that things > >aren't working as expected, and if the user wants to change configuration to use > >NullEnv, that's great. > > I agree. > I'm skeptical about this. You're making a strong point about the user expecting os.environ to work. Given my first experience I would expect nothing :). The defaults are python.enviroment = shell and if unknown then unix. A fragile mixture although it is a good way to get things tested. In particular if I'm writing an application that should run under jython under a potentially unknown os, now I should care about python.enviroment settings. 2nd: an old straightforward application importing os can fail. I imagine a possible compromise would be to issue a warning and not raise an expception in this particular case of execute usage. regards. |
From: <bc...@wo...> - 2001-11-20 14:41:55
|
>> >I'm inclined to throw an OS exception here, too - let the user know that >things >> >aren't working as expected, and if the user wants to change configuration to >use >> >NullEnv, that's great. >> >> I agree. >> [Samuele] >I'm skeptical about this. You're making a strong point about the user expecting >os.environ to work. Given my first experience I would expect nothing :). Hehehe. >The defaults are python.enviroment = shell and if unknown then unix. >A fragile mixture although it is a good way to get things tested. Yeah, it is clearly not any of my programs that is failing <wink>, so I can afford to be aggresive. >In particular if I'm writing an application that should run under >jython under a potentially unknown os, now I should care >about python.enviroment settings. >2nd: an old straightforward application importing os can fail. Just importing os? Surely it must also access os.environ before it fails. >I imagine a possible compromise would be to issue a warning >and not raise an expception in this particular case of execute usage. A warning is certainly better than a silent fallback to NullEnv. Would it be worth making a difference of defensive calls? Letting the 3 argument os.environment.get() and has_key() fail silently but throwing exceptions for (most of?) the rest? Probably not! regards, finn |
From: Samuele P. <ped...@bl...> - 2001-11-20 15:12:06
|
> >The defaults are python.enviroment = shell and if unknown then unix. > >A fragile mixture although it is a good way to get things tested. > > Yeah, it is clearly not any of my programs that is failing <wink>, so I > can afford to be aggresive. > > >In particular if I'm writing an application that should run under > >jython under a potentially unknown os, now I should care > >about python.enviroment settings. > >2nd: an old straightforward application importing os can fail. > > Just importing os? Surely it must also access os.environ before it > fails. > > >I imagine a possible compromise would be to issue a warning > >and not raise an expception in this particular case of execute usage. > > A warning is certainly better than a silent fallback to NullEnv. > Oops I skipped over the important point, the problem is not importing os - environ is lazy and I know- but using a CPython module that uses os.environ which worked fine with the empty environ (e.g. tempfile) and now can fail miserably if os.environ fails miserably. I got this problem running the CPython 2.1 test suite, it uses tempfile and the failing os.environ made some tests fail. So why I would prefer falling back to NullEnv + warning. Samuele. |
From: Kevin B. <kb...@ca...> - 2001-11-20 17:07:52
|
Finn Bock wrote: > > [Samuele Pedroni] > > > Some notes: > > > > - if something goes wrong with Runtime.exec a java exception is thrown, > > I think this should be somehow wrapped in an os.error. Opinions? > > [Kevin Butler] > > >Agreed. > > Ok, as long as the os.error contain all the information from the java > exception. Including information about the type of exception > (IOException or SecurityException) and the exception message. > > The patch below doesn't and it certainly should. In general I agree. The reasons I didn't in this case were: 1- I didn't know if we wanted to have a standard Python module expose Java exception info 2- the errors weren't giving any useful information And given your opinion, #1 becomes a non-issue, and #2 could be a platform-specific thing, so it probably would be good to include it... Is there a way to easily incorporate a Java exception into an OSError? Should I just include the .toString(), or try to incorporate the stack trace info? Should errors.java include a "JavaError" as a subclass of "OSError"? [snip: platform-specifics] > Thats why I haven't touched added this feature myself. It is so easy to > get working for oneself but so hard to get it working correctly for all. Java: Write once, debug everywhere? > >As is becoming all too frequent, here's a patch (but this is the last one for a > >long time... *wink*), > > Do you have a SF account? Make one and I'll add you as committer. Then > you don't have to make excuses every time. I'm 'kevinbutler' I think the peer review is helpful, so I'd like to keep submitting significant changes like this last one to the list... > >! pardir = '..' > > You think that is right on macs and AS/400? Nope. :-) Looks like Python's os.py uses the following for Mac: curdir = ':'; pardir = '::'; sep = ':'; pathsep = '\n' defpath = ':' No idea for other exotic (to me) platforms... > Maybe it actually is, but I > doubt it. I liked the old defensive comment. :-) We can put it back in, but nobody sees it unless they look at the source We could be really defensive with some assertions/warnings about "getParentFile().getCanonicalPath()", etc., but we'd want to have them disable-able... Makes me want an install-time OS-chooser function that enables/disables particular functions & warns about conflicts! Isn't that exactly what Java is supposed to avoid? > >! except UnboundLocalError: > >! # 'value' is unbound because we didn't find '=' on first line > > Maybe it is just my personal preference, but I would prefer an explicit > test instead of catching UnboundLocalError. I prefer an explicit test, but weighed against the cost of executing the check in each iteration... I guess we could structure it like this: lines = self._readLines( p.getInputStream() ) if '=' not in lines[0]: raise OSError( 0, "Command did not print environment.\n" "Command=%s\nOutput=%s\n" % ( self.getEnv, '\n'.join( lines ) )) for line in lines: ... That feels better. :-) [Samuele Pedroni Re: shell os causes failure] > I got this problem running the CPython 2.1 test suite, it uses > tempfile and the failing os.environ made some tests fail. Ouch. Looks like the code was probably: # set up a bunch of default 'attempdirs' # ... # then try to get a couple more from the environment for envname in 'TMPDIR', 'TEMP', 'TMP': if os.environ.has_key(envname): attempdirs.insert(0, os.environ[envname]) Pretty innocuous, especially because it already had various standard and os-specific "attempdirs" in place. Which makes it a good case for your preference: > So why I would prefer falling back to NullEnv + warning. I wouldn't have a problem issuing a warning - well, I'd have to figure out how to use warnings.py ;-) What category would be appropriate? etc? kb |
From: <bc...@wo...> - 2001-11-20 20:54:50
|
[me] > Ok, as long as the os.error contain all the information from the java > exception. Including information about the type of exception > (IOException or SecurityException) and the exception message. > > The patch below doesn't and it certainly should. [kevin] >In general I agree. The reasons I didn't in this case were: > >1- I didn't know if we wanted to have a standard Python module expose Java exception info >2- the errors weren't giving any useful information > >And given your opinion, #1 becomes a non-issue, and #2 could be a >platform-specific thing, so it probably would be good to include it... In win2k the message is sometimes very usefull: Jython 2.1b1 on java1.4.0-beta3 (JIT: null) Type "copyright", "credits" or "license" for more information. >>> import java >>> java.lang.Runtime.getRuntime().exec("foobar") Traceback (innermost last): File "<console>", line 1, in ? java.io.IOException: CreateProcess: foobar error=2 where error #2 means #define ENOFILE 2 /* No such file or directory */ If we get a bugreport, we want to know the actual error number. >Is there a way to easily incorporate a Java exception into an OSError? >Should I just include the .toString(), yes. >or try to incorporate the stack trace info? No. >Should errors.java include a "JavaError" as a subclass of "OSError"? No. >> Do you have a SF account? Make one and I'll add you as committer. Then >> you don't have to make excuses every time. > >I'm 'kevinbutler' Added. Let me know if I missed to check some access-right boxes. >> >! pardir = '..' >> .. >> I liked the old defensive comment. > >:-) We can put it back in, but nobody sees it unless they look at the source True. I just hope that users that find the value wrong, will try and hunt down where the value is defined. Maybe even suggest patches. >We could be really defensive with some assertions/warnings about >"getParentFile().getCanonicalPath()", etc., but we'd want to have them >disable-able... Or more if-statements that test for os.name and python.os. regards, finn |
From: Kevin B. <kb...@ca...> - 2001-11-20 16:44:47
|
Finn Bock wrote: > > [Kevin Butler] > > > >Instead, I just modified my python.path in /usr/share/jython/registry to point to > >python2.1 > >instead of letting jython (somehow?) find python2.2... > > How indeed! It should not attempt do that automaticly. Maybe it is done > by site.py that is reading .pth files? It was finding the python2.2/site.py file, for some reason (python2.2 was in the sys.path, though I had no python.path in the registry). Ahh, it looks like the magic is in /usr/bin/jython, which chooses the highest-numbered CPYTHON_LIB: CPYTHON_LIB= for pydir in /usr/lib/python?.?; do if [ -d "$pydir" ]; then if [ "$CPYTHON_LIB" \< ":$pydir" ]; then CPYTHON_LIB=":$pydir" fi fi done --- I couldn't see this code in Jython CVS - is this created by my Debian jython package? If so, anything else I should tell the Debian jython package maintainer? kb |
From: <bc...@wo...> - 2001-11-20 21:39:30
|
[Kevin Butler] >Ahh, it looks like the magic is in /usr/bin/jython, which chooses the >highest-numbered CPYTHON_LIB: > >CPYTHON_LIB= >for pydir in /usr/lib/python?.?; do > if [ -d "$pydir" ]; then > if [ "$CPYTHON_LIB" \< ":$pydir" ]; then > CPYTHON_LIB=":$pydir" > fi > fi >done WTF? Doesn't the debian package of jython include the CPython modules in its ./Lib directory? Your report about sre_constants.MAGIC indicate that it doesn't. Does anyone have a list of files in the debian jython release? I could only find a .deb file and don't know how to list its content. >I couldn't see this code in Jython CVS - is this created by my Debian >jython package? If so, anything else I should tell the Debian jython >package maintainer? I think Ben is on this list already. Well, - Searching for a different CPython release is wrong. It must be 2.1.1. - Depending completely on modules from CPython is also wrong. One of the problems is the socket modules that gets imported by other modules from Lib. Running the SimpleHTTPServer script f.ex will pick up the socket.py from CPython and that can't work with Jython. It seems the search for CPython was added based on this bugreport. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=118429 and I think dman's suggestion was correct. The CPython modules have to be carefully duplicated as done by installer/mklist.py. Maybe it would be helpful if we improve mklist.py to be platform portable. Right now it is mainly a script that works on my machine. regards, finn |
From: Ben B. <be...@ac...> - 2001-11-20 22:18:52
|
> I think Ben is on this list already. Ben is on this list but is kind of busy and hadn't noticed this thread until just now. :) > - Searching for a different CPython release is wrong. It must be 2.1.1. I'll fix this. > and I think dman's suggestion was correct. The CPython modules have to > be carefully duplicated as done by installer/mklist.py. The procedure currently used by the debian package is: - Have a python path that places jython's Lib/ before the CPython directory; - Only duplicate modules that require jython-specific patches, and place these patches in jython's Lib/ Is this doomed to failure, or have I just missed some jython-specific patches in the debian packaging? You can see the (small) list of duplicated modules in the package contents list that Kevin posted. Ben. -- Ben Burton be...@ac... | ba...@de... http://baasil.humbug.org.au/bab/ Public Key: finger ba...@de... I go into a real vulnerable side of myself. That's where I am finding a lot of hidden stuff, as a woman afraid to be vulnerable, because I think I will be weak, thinking I'll be taken advantage of, thinking I won't know where to draw the line. But I am finding that vulnerability gives me great strength, because you're not hiding anymore! - Tori Amos |
From: <bc...@wo...> - 2001-11-20 23:06:12
|
[Ben Burton] >The procedure currently used by the debian package is: > >- Have a python path that places jython's Lib/ before the CPython directory; >- Only duplicate modules that require jython-specific patches, and place >these patches in jython's Lib/ That is exactly how I run from CVS and how I manage the CPython modules in jython's CVS. Except for the problem with socket.py, it is a good scheme. >Is this doomed to failure, No. A bit too fragile for my taste, but if debian have a good dependency system it may work for you. In 2.1b1 we will also include a sizeable part of the modules from PyXML http://sourceforge.net/projects/pyxml in the installer. A little twist on the PyXML support is that some of the non-supported drivers must *not* be included in order to complete part of the PyXML test suite. regards, finn |
From: Kevin B. <kb...@ca...> - 2001-11-20 21:58:09
Attachments:
jython.list
|
Finn Bock wrote: > > [Kevin Butler] > > WTF? Doesn't the debian package of jython include the CPython modules in > its ./Lib directory? Your report about sre_constants.MAGIC indicate that > it doesn't. I've got jython deb version 2.1-alpha3-5. > Does anyone have a list of files in the debian jython release? I could > only find a .deb file and don't know how to list its content. dpkg -L jython (at least for an installed .deb) output attached. > Maybe it would be helpful if we improve mklist.py to be platform > portable. Right now it is mainly a script that works on my machine. :-) kb |
From: Ben B. <be...@ac...> - 2001-11-20 22:21:46
|
> - Depending completely on modules from CPython is also wrong. One of the > problems is the socket modules that gets imported by other modules from > Lib. Running the SimpleHTTPServer script f.ex will pick up the socket.py > from CPython and that can't work with Jython. I should add that socket.py is one of the modules that *is* included in debian jython's Lib/ directory (see Kevin's list), so AFAIU jython should pick up the correct socket.py. Ben. -- Ben Burton be...@ac... | ba...@de... http://baasil.humbug.org.au/bab/ Public Key: finger ba...@de... A man cannot be too careful in the choice of his enemies. - Oscar Wilde, The Picture of Dorian Gray |
From: <bc...@wo...> - 2001-11-20 22:43:49
|
> - Depending completely on modules from CPython is also wrong. One of the > problems is the socket modules that gets imported by other modules from > Lib. Running the SimpleHTTPServer script f.ex will pick up the socket.py > from CPython and that can't work with Jython. [Ben Burton] >I should add that socket.py is one of the modules that *is* included in >debian jython's Lib/ directory (see Kevin's list), so AFAIU jython should >pick up the correct socket.py. Yes, unless the import is performed when a module in Python-211/Lib is used as a script. SimpleHTTPServer.py is such a module that can also be started as a command line script. Then the Python-211/Lib directory is first in sys.path and an import of socket.py will pick up the socket.py from Python-211/lib. I think there is another example, but I have forgot which. regards, finn |
From: Ben B. <be...@ac...> - 2001-11-21 01:33:38
|
> >I should add that socket.py is one of the modules that *is* included in > >debian jython's Lib/ directory (see Kevin's list), so AFAIU jython should > >pick up the correct socket.py. > > Yes, unless the import is performed when a module in Python-211/Lib is > used as a script. SimpleHTTPServer.py is such a module that can also be > started as a command line script. Then the Python-211/Lib directory is > first in sys.path and an import of socket.py will pick up the socket.py > from Python-211/lib. I think there is another example, but I have forgot > which. Hmm, I see (having just reproduced the error on my debian box). Though wouldn't this error still occur even if the standard jython installation method were used (all files duplicated in jython/Lib, no CPython directories on the python path at all)? I assume the problem is that the directory containing the script is placed first in sys.path, and I don't see how using the standard jython installation method will get around this. Perhaps I'm missing something..? Ben. -- Ben Burton be...@ac... | ba...@de... http://baasil.humbug.org.au/bab/ Public Key: finger ba...@de... A man who does not think for himself does not think at all. - Oscar Wilde |
From: Ben B. <be...@ac...> - 2001-11-21 16:22:34
|
> > Yes, unless the import is performed when a module in Python-211/Lib is > > used as a script. SimpleHTTPServer.py is such a module that can also be > > started as a command line script. Then the Python-211/Lib directory is > > first in sys.path and an import of socket.py will pick up the socket.py > > from Python-211/lib. I think there is another example, but I have forgot > > which. > > Hmm, I see (having just reproduced the error on my debian box). > > Though wouldn't this error still occur even if the standard jython > installation method were used (all files duplicated in jython/Lib, no > CPython directories on the python path at all)? I assume the problem is > that the directory containing the script is placed first in sys.path, and I > don't see how using the standard jython installation method will get around > this. Oh, duh. The SimpleHTTPServer.py script would be called directly from jython/Lib, not from CPython/Lib. Never mind. :) Ben. -- Ben Burton be...@ac... | ba...@de... http://baasil.humbug.org.au/bab/ Public Key: finger ba...@de... A cigarette is the perfect type of a perfect pleasure. It is exquisite, and it leaves one unsatisfied. What more can one want? - Oscar Wilde |