Menu
▾
▴
pythoncard-users
|
From: catonano\@inwind\.it <cat...@in...> - 2005-09-03 07:27:02
|
> >There's a current thread about this in the PythonCard-users group, > = >under the non-clear subject name: > > > > Re: update (was: Re:= [Pythoncard-users] supposed bug in > >PythonCard) > > > > > >Yes I = originated the thread. I found a bug in Pythoncard with python 2.4.1 and = wxPython 2.6.1.0 and > >PythonCard 0.8.1 > > > >It's not "supposed". I= t's a quite clearly a bug. > > > > > > > Adriano - > the only reas= on the subject line says "supposed bug ..." is because > that's the sub= ject line you chose for your initial posting to the > Pythoncard list o= n this topic :-) Yes, Alex, you're right. It was a supposed bug when I= opened the thread, so the subject line was quite good at the moment. =0D = Later it became a bit obscure ;-) > Something appears to have change= d wrt the path that Python's sys.modules > reports for imported files. = >As far as I know, no-one has yet verified > for sure whether it is= a Python bug or merely a platform-specific change > that Pythoncard wi= ll need to adjust for. (Nor do I know how we'll be > able to adjust - b= ut I'm hoping that some of the PythonCard / Mac users > are investigati= ng ....) That python user could be me ! Alex, would you discuss a b= it more about this Python issue ? sys.modules reportings about the imp= orted files has changed ? Since when ? Does this affect the Apple ins= talled python or the "third parties" ones ? Thanks! Bye Adriano =0A= =0A=0A=0A____________________________________________________________=0AL= ibero Flat, sempre a 4 Mega a 19,95 euro al mese! =0AAbbonati subito su h= ttp://www.libero.it=0A=0A |
|
From: Alex T. <al...@tw...> - 2005-09-03 12:38:49
|
No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date: 31/08/2005 |
|
From: Ronald O. <ron...@ma...> - 2005-09-04 09:18:42
Attachments:
smime.p7s
|
On 3-sep-2005, at 14:38, Alex Tweedly wrote: > cat...@in... wrote: >> Yes, Alex, you're right. It was a supposed bug when I opened the >> thread, so the subject line was quite good at the moment. >> Later it became a bit obscure ;-) > OK - as long as you didn't think anyone was doubting that it was a > bug .... >>> Something appears to have changed wrt the path that Python's >>> sys.modules reports for imported files. >>> As far as I know, no-one has yet verified for sure whether it is >>> a Python bug or merely a platform-specific change that Pythoncard >>> will need to adjust for. (Nor do I know how we'll be able to >>> adjust - but I'm hoping that some of the PythonCard / Mac users >>> are investigating ....) >> That python user could be me ! Alex, would you discuss a bit more >> about this Python issue ? > Sure, I'll talk about it some, and maybe try to distill it down to > a simple small program that would be easy to try out. > But first I'll give a few disclaimers. > - I was totally unaware of this part of the code until this topic > came up > - I'm not a Python details kind of guy > - I don't have, or have access to, a Mac > > (So if Kevin has to come along and correct anything I say - don't > be too surprised). >> sys.modules reportings about the imported files has changed ? >> Since when ? Does this affect the Apple installed python or the >> "third parties" ones ? > No real idea since when. First guess would be between Python > 2.3.something and Python 2.4.something. > > I have a vague idea that Apple installed python is 2.3, so it > shouldn't be affected (but that's only a guess). > > The issue is how PythonCard finds the resource files that go along > with a Python source file. By default, they live in the same > directory as the source file, and have an extra ".rsrc" appended to > the base name (before the extension) - thus a source file xyz.py > would have a resource file xyz.rsrc.py > > PythonCard allows for various alternatives (language specific > resource files, platform specific files, no file but an internal > dictionary, etc.) and these make the code somewhat harder to > follow. But if you ignore all those, the essence of what PythonCard > does is > > 1. determine the full path name for the source file > 2. modify it as above > 3. read and eval() the resource file. > > In this case, the source file is not the application itself, but an > imported module. In the resourceEditor (in resourceEditor.py, in > fact), we do > > (before Kevin's suggested modification) > from modules.propertyEditor import PropertyEditor > .... > self.propertyEditorWindow = model.childWindow(self, > PropertyEditor) > > (or, after Kevin's suggested modification) > from modules import propertyEditor > .... > self.propertyEditorWindow = model.childWindow(self, > propertyEditor.PropertyEditor) > > (modules is a subdirectory within resourceEditor, propertyEditor.py > is a source file, PropertyEditor is a class within that file). > > So these two should be equivalent; Kevin suggested the change > because this is the only place within PythonCard that this form of > import is used - every other import is the second form (and there > was some hope that this change would help). > > I'll use the second version in this example below .... and probably > get some of the terminology wrong. > > When you call model.childWindow, you pass in the class you want - > i.e. propertyEditor.PropertyEditor > childWindow() then derives the filename, splits off the extension, > adds in the .rsrc.py and tries to read that file (remember I'm > skipping over the internationalization part ...) > > So it does [ frameClass is the class wanted ] > > filename = sys.modules[frameClass.__module__].__file__ > ..... > base, ext = os.path.splitext(filename) > filename = internationalResourceName(base) > rsrc = resource.ResourceFile(filename).getResource() I haven't followed this discusion upto now, but do you use py2app to build the application bundle on OSX? py2app places all .py/.pyc files into a zip file, resources are outside of the zip file. BTW. do you know about setuptools? It contains a generic API for dealing with resource files. > > > So - that's the background. > > Brad sent the debug output from the first case above (before > Kevin's suggested change), and also reported that the problem > persisted after the change. So it looks likely that it's a Python > bug. The Python docs are very sparse on what sys.modules should do. I'd say it is unlikely to be a bug in Python :-) > > I'd like to see a simple test output which is independent of > PythonCard. > > 1. Create a test directory > mine is called C:/python/projects/modulestest > > 2. create a subdirectory called "mmm" (calling it "modules" was > confusing me) > > 3. create a file within that subdirectory called myFile.py > containing >> class myClass: >> def init(): >> pass > 4. create another tile in that subdirectory (to make it a package) > called __init__.py containing >> # turn modules into a package > (note the name is underscore underscore i n i t underscore > underscore . p y ) > > 5. cd to the main test directory >> cd c:\python\projects\modulestest > 6. run python, and do >> import sys >> from mmm import myFile >> myFile.myClass.__module__ >> sys.modules[myFile.myClass.__module__].__file__ > and see what the output is. For what it's worth: Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> from mmm import myFile >>> myFile.myClass.__module__ 'mmm.myFile' >>> myFile.__file__ 'mmm/myFile.pyc' >>> sys.modules[myFile.myClass.__module__].__file__ 'mmm/myFile.pyc' and: Python 2.4.1 (#1, Aug 23 2005, 21:38:15) [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> from mmm import myFile >>> myFile.myClass.__module__ 'mmm.myFile' >>> myFile.__file__ 'mmm/myFile.py' >>> sys.modules[myFile.myClass.__module__].__file__ 'mmm/myFile.py' > > It *should* be the path name to the file .... > <screen.PNG> > > > > This gives the same result on Python 2.4.1 on Windows. > I'd like to see the equivalent of this on each of Python 2.3 and > 2.4 on Mac. > > Then we'd know what the next step might be ... :-) > > -- Alex Tweedly http://www.tweedly.net > <screen.PNG> > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date: > 31/08/2005 > _______________________________________________ > Pythonmac-SIG maillist - Pyt...@py... > http://mail.python.org/mailman/listinfo/pythonmac-sig > |
|
From: Alex T. <al...@tw...> - 2005-09-04 11:10:01
|
Ronald Oussoren wrote: Thanks Ronald. I hadn't spotted that this was still being cc'ed to pythonmac-sig - so extra thanks for that. > > I haven't followed this discusion upto now, but do you use py2app to > build the application bundle on OSX? py2app places all .py/.pyc files > into a zip file, resources are outside of the zip file. > No, these problems are also being seen within the IDE, so it's not an app/bundle problem. > BTW. do you know about setuptools? It contains a generic API for > dealing with resource files. > Yes, and that looks like a promising way to do this in the future. (though it increases the dependencies). But this code has existed and worked for a couple of years now, it's important we know what's going wrong with it in case there are other (less obvious) things that are going to fail for the same reasons. >> So - that's the background. >> >> Brad sent the debug output from the first case above (before Kevin's >> suggested change), and also reported that the problem persisted >> after the change. So it looks likely that it's a Python bug. The >> Python docs are very sparse on what sys.modules should do. > > > I'd say it is unlikely to be a bug in Python :-) > So would I - but the evidence up till this email all pointed that way - and since this is (perhaps) an unusual use of the sys.modules info, it seems just possible. >> >> I'd like to see a simple test output which is independent of >> PythonCard. >> >> < snip > > > > For what it's worth: > > Python 2.3.5 (#1, Mar 20 2005, 20:38:20) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> from mmm import myFile > >>> myFile.myClass.__module__ > 'mmm.myFile' > >>> myFile.__file__ > 'mmm/myFile.pyc' > >>> sys.modules[myFile.myClass.__module__].__file__ > 'mmm/myFile.pyc' > > and: > Python 2.4.1 (#1, Aug 23 2005, 21:38:15) > [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> from mmm import myFile > >>> myFile.myClass.__module__ > 'mmm.myFile' > >>> myFile.__file__ > 'mmm/myFile.py' > >>> sys.modules[myFile.myClass.__module__].__file__ > 'mmm/myFile.py' > Thanks again for that. (Not quite was I was hoping for :-), but very valuable info). So we now know this simplest case works as expected - and the rather complex case within PythonCard doesn't. It should be straightforward (if somewhat tedious) to narrow down the differences until we find where the difference is. But that's not the kind of debugging we can do via email on a list (or two!!), so I'm hoping a PythonCard / Mac user can take it from there (or will contact me off-list and we can work on narrowing it down). -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date: 31/08/2005 |
|
From: Kevin A. <al...@se...> - 2005-09-04 16:10:14
|
On Sep 4, 2005, at 4:10 AM, Alex Tweedly wrote: > Ronald Oussoren wrote: > Thanks Ronald. I hadn't spotted that this was still being cc'ed to > pythonmac-sig - so extra thanks for that. > >> >> I haven't followed this discusion upto now, but do you use py2app to >> build the application bundle on OSX? py2app places all .py/.pyc files >> into a zip file, resources are outside of the zip file. >> > No, these problems are also being seen within the IDE, so it's not an > app/bundle problem. > >> BTW. do you know about setuptools? It contains a generic API for >> dealing with resource files. >> > Yes, and that looks like a promising way to do this in the future. > (though it increases the dependencies). > But this code has existed and worked for a couple of years now, it's > important we know what's going wrong with it in case there are other > (less obvious) things that are going to fail for the same reasons. > >>> So - that's the background. >>> >>> Brad sent the debug output from the first case above (before >>> Kevin's suggested change), and also reported that the problem >>> persisted after the change. So it looks likely that it's a Python >>> bug. The Python docs are very sparse on what sys.modules should do. >> >> >> I'd say it is unlikely to be a bug in Python :-) >> > So would I - but the evidence up till this email all pointed that way > - and since this is (perhaps) an unusual use of the sys.modules info, > it seems just possible. > >>> >>> I'd like to see a simple test output which is independent of >>> PythonCard. >>> >>> < snip > >> >> >> For what it's worth: >> >> Python 2.3.5 (#1, Mar 20 2005, 20:38:20) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import sys >> >>> from mmm import myFile >> >>> myFile.myClass.__module__ >> 'mmm.myFile' >> >>> myFile.__file__ >> 'mmm/myFile.pyc' >> >>> sys.modules[myFile.myClass.__module__].__file__ >> 'mmm/myFile.pyc' >> >> and: >> Python 2.4.1 (#1, Aug 23 2005, 21:38:15) >> [GCC 4.0.0 (Apple Computer, Inc. build 5026)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import sys >> >>> from mmm import myFile >> >>> myFile.myClass.__module__ >> 'mmm.myFile' >> >>> myFile.__file__ >> 'mmm/myFile.py' >> >>> sys.modules[myFile.myClass.__module__].__file__ >> 'mmm/myFile.py' >> > Thanks again for that. (Not quite was I was hoping for :-), but very > valuable info). > > So we now know this simplest case works as expected - and the rather > complex case within PythonCard doesn't. > > It should be straightforward (if somewhat tedious) to narrow down the > differences until we find where the difference is. But that's not the > kind of debugging we can do via email on a list (or two!!), so I'm > hoping a PythonCard / Mac user can take it from there (or will contact > me off-list and we can work on narrowing it down). > > -- > Alex Tweedly http://www.tweedly.net I expect the problem has to do with relative paths. For some reason Python 2.4.1 is behaving different from 2.3 on the Mac as well as 2.3.x and 2.4.x versions on Windows and Linux. The reason why PythonCard tickles this problem is likely due to one or more lines in model.py. In particular, at the top there is a try/except block with the following line that was added as a fix for relative paths that would show up in earlier versions of Python when the module was imported: sys.path[0] = os.path.abspath(sys.path[0]) There was a discussion on python-dev quite a while ago that led to this line of code being used to prevent relative path ambiguity with the module path regardless of how the application changes its working directory. Here's an example run in the shell on the Mac with Python 2.3 (Panther). >>> import sys >>> sys.path[0] '' >>> import os >>> sys.path[0] = os.path.abspath(sys.path[0]) >>> sys.path[0] '/Users/kea/python/PythonCard' PythonCard does an explicit os.chdir later to the starting script directory to standardize behavior of apps regardless of where they were started from as well as simplify using support files, including modules that are in the application directory or sub-directories. self.applicationDirectory = util.dirname(os.path.abspath(sys.argv[0])) # always run in the app's directory os.chdir(self.applicationDirectory) Both of these bits of code, or equivalent in the case of the chdir above need to be part of a test prior to the path check for __file__. Since this is a relative path bug we're tracking down, it is quite possible that with Python 2.4.1 on the Mac you could get different results depending on whether you are running the script from the same directory you are working from in the shell, that was the reason for the sys.path[0] workaround in the first place. ka |
|
From: Alex T. <al...@tw...> - 2006-05-09 01:03:25
|
[It's not often you get to reply to a thread that's 8 months old ] Kevin Altis wrote: > Alex Tweedlt said: > >> Thanks again for that. (Not quite was I was hoping for :-), but very >> valuable info). >> >> So we now know this simplest case works as expected - and the rather >> complex case within PythonCard doesn't. >> >> It should be straightforward (if somewhat tedious) to narrow down the >> differences until we find where the difference is. But that's not the >> kind of debugging we can do via email on a list (or two!!), so I'm >> hoping a PythonCard / Mac user can take it from there (or will >> contact me off-list and we can work on narrowing it down). > I finally bought my own Mac, but by then I had forgotten this problem (or assumed it had gone away). Today I upgraded to Python 2.4 and ran into the problem myself - and now I'm in a position to track it down. > > I expect the problem has to do with relative paths. For some reason > Python 2.4.1 is behaving different from 2.3 on the Mac as well as > 2.3.x and 2.4.x versions on Windows and Linux. The reason why > PythonCard tickles this problem is likely due to one or more lines in > model.py. In particular, at the top there is a try/except block with > the following line that was added as a fix for relative paths that > would show up in earlier versions of Python when the module was imported: > No, it's not relative paths. We do some hackery to try to determine whether we are running 'normally' or from a standalone built with py2app, py2exe, bundlebuilder, macmillan, etc. (so we can look for resource files in the different places they finish up, rather than in their usual directory alongside the .py file). Part of this is in util.py / main_is_frozen() - where there was an explicit test for a 2.3 based path, specific to the OSX version. Because we wrongly believed we were "frozen". we looked in the wrong place(s). Not sure what the medium term fix is (long term I think it is probably setuptools as Ronald suggested earlier) - but there will be a short term fix in CVS soon, hopefully tonight, so if you have been wanting to move to Python 2.4 but were held back by PythonCard, you should be able to get that soon. Note there may be a delay of up to 24 hours before anonymous cvs access catches any updates. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.5/333 - Release Date: 05/05/2006 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X