From: SourceForge.net <no...@so...> - 2006-09-07 03:46:44
|
Bugs item #1284344, was opened at 2005-09-07 17:47 Message generated for change (Comment added) made by cgroves You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1284344&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Deferred >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: leouser (leouserz) Assigned to: Charles Groves (cgroves) Summary: __file__ compiled into .py.class file Initial Comment: I ran across this in trying to figure out why my jyleo.py startup script was failing. What is happening is that once a jython src file is compiled it has the __file__ attribute permanently written into the compiled file. This makes it impossible to derive correctly the place where the file is being loaded from. Once compiled, you can move a set of jython code to another machine or a different directory and code that needs correct __file__ attributes will mysteriously fail--> that is until you find out that the __file__ attribute is returning a path that only exists on another machine. The requested fix: make the __file__ attribute correctly reflect its location on the filesystem. The severity of this depends upon if your application/script depends upon this information to function properly. In my case it does, so from my perspective it is a *bad* bug. For others it may not even be a bug. ---------------------------------------------------------------------- >Comment By: Charles Groves (cgroves) Date: 2006-09-06 22:46 Message: Logged In: YES user_id=1174327 Fixed in r2925 tested by test392 ---------------------------------------------------------------------- Comment By: James William Pye (jwpye) Date: 2006-05-13 19:51 Message: Logged In: YES user_id=1044177 I have experienced a __file__ related issue as well. It seems that this is one of the subtle features that most Python implementations seem to miss(ironpython seems to be the only one that got it right, but they seem to be missing the os module, so I dunno if they are actually "better") jwp@lit:~/jythonRelease_2_2alpha1 % uname -a FreeBSD lit 6.1-RC FreeBSD 6.1-RC #5: Mon Apr 24 21:21:02 MST 2006 root@lit:/usr/obj/usr/src/sys/void amd64 jwp@lit:~/jythonRelease_2_2alpha1 % cat ../printfile.py print '__file__ =', repr(__file__) jwp@lit:~/jythonRelease_2_2alpha1 % ./jython ../printfile.py __file__ =Traceback (innermost last): File "../printfile.py", line 1, in ? NameError: __file__ Also, interestingly, it appears to have printed the first element in the print statement(printing while iterating over the list?) Oh, and it does the same thing when I try to import the 'printfile' module. If this is not deemed a bug, perhaps it should be mentioned in the FAQ. Similarly, I can't find much of anything on ironpython's lack of an os module for posix systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112867&aid=1284344&group_id=12867 |