🌐 Mailman 3 December 2001 - Pythonmac-SIG - python.org

Newbie-Q: test & applets
by Christian Ebert Dec. 29, 2001

Dec. 29, 2001

Hi there, I am completely new to Python and more or less to programming too. So bear with me or point me in the right direction if this has already been covered somewhere else. 1. After installing 2.2 I ran test.regrtest - everything went fine when I typed the commands directly in the interpreter. However if I run test.regrtest from IDE or if I run import test.autotest I get: [...] test_threaded_import test test_threaded_import skipped -- can't run when import lock is held [...] 1 skip unexpected on mac: test_threaded_import Is this the regular behaviour? 2. If I save a little "Hello world" script as applet and try to run it I get the message: "PythonCore not found". After I run ConfigurePythonClassic (the script imports Tkinter) everything works fine - till I restart my computer, then I have to run ConfigurePythonClassic again to make it work. More or less the same little script, but with import W, can only be run from within IDE. Saved and run as applet it returns: Traceback (most recent call last): File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Scripts:Hello_world.py", line 1, in ? import W File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Mac:Tools:IDE:W.py", line 5, in ? from Wbase import * File "Christians PB HD:Applications (Mac OS 9):Scripting:Python 2.2:Mac:Tools:IDE:Wbase.py", line 698, in ? _cursors = { MacOS.Error: (-192, 'Resource not found') I added $(PYTHON):Mac:Tools and $(PYTHON):Mac:Tools:IDE in preferences. What am I missing? Some QuickDraw module? (Mac OS D1-9.2.2) TIA Christian

1 0

Python 2.2 Framework _REENTRANT
by Adam Eijdenberg Dec. 29, 2001

Dec. 29, 2001

Hi, I'm developing a Mach-O Carbon application that embeds Python and I'm getting a few funny warnings when I try to compile it. I've installed the Unix version of Python with the commands "./configure --enable-framework && make && make framework" install as per documentation and that all seems to work fine. But when I compile my application with: cc *.c -framework Carbon -framework Python I get the following warnings: (widget.h is one of my files, line 6 #includes <Python/Python.h>) widget.h:6: warning: could not use precompiled header '/System/Library/Frameworks/Carbon.framework/Headers/Carbon.p', because: widget.h:6: warning: #ifdef '_REENTRANT' not defined when precompiled, but now defined: widget.h:6: warning: at /Library/Frameworks/Python.framework/Headers/pyconfig.h:208 Lines 207 and 208 in pyconfig.h are: /* Define to force use of thread-safe errno, h_errno, and other functions */ #define _REENTRANT 1 Commenting out this line removes all warnings. Everything seems to work fine, but could commenting this line out cause any problems? Kind regards, Adam Eijdenberg Switched on Software adam(a)switchedonsoftware.com

1 0

Re: url2pathname...pathname2url?
by Jack Jansen Dec. 27, 2001

Dec. 27, 2001

Recently, "Schollnick, Benjamin" <Benjamin.Schollnick(a)usa.xerox.com> said: > Jack & company, > > I just went through the python.org doc's, and the v2.2 changes > docs, and can't find any mention of url2pathname..... (I didn't search bu Hmm, is it undocumented? They're defined in macurl2path (and nturl2path, rourl2path, etc), and I think they're included from there into urllib. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

url2pathname...pathname2url?
by Schollnick, Benjamin Dec. 27, 2001

Dec. 27, 2001

Jack & company, I just went through the python.org doc's, and the v2.2 changes docs, and can't find any mention of url2pathname..... (I didn't search bu Jack, were you suggesting the creation of those functions? Or are they contained in a non-core module, that I'm not aware of? - Benjamin

1 0

RE: [Pythonmac-SIG] Using slash-seperated paths for creating FSSp ecs (was: Mach-O MacPython IDE!!!)
by Schollnick, Benjamin Dec. 27, 2001

Dec. 27, 2001

Jack, > 2. We already have a perfectly well-defined way to specify pathnames > and their conversion between platform syntaxes: URLs. An > url2pathname() followed by basejoin() followed by pathname2url() > should always do the trick. It appears I've missed some feature creap in Python... When was url2pathname / pathname2url added? I'm assuming it's in URLLIB? And while I recognize that file://blah/blah/blah.exe is certainly a path, isn't that forcing us to go through some extra hoops? I'm not sure (especially since v2.1 Docs don't seem to document url2pathname, etc) where the url2pathname is simplier. Don't you still have the same issues? > component, the disk name, is magic. Actually, it's also uncertain > whether it will fly for Mac OS X: the colon-paths start with a disk > name (which is somewhat magic) while the / path is a standard unix > path. If you're not on the system disk a path like > diskname:dirname:filename will become > /Volumes/diskname/dirname/filename. That really really is OS dependant (Win2000) ...Oh.... You mean the *drive letter*. If your constructing from scratch, that might be a issue... But I rarely construct programs that require me to "assign" a drive. What I usually do is something along this line: program_path = os.getcwd() file_handle = os.join(program_path, "working_directory") Plus, I usually use some form of relative path instead of absolute paths. I think I've started to ramble slightly... Let me sum up. 1) I think I may have missed part of your viewpoint... Because #4 is obvious to me.... but... >g< 2) Platform Agnostic good... <g> ... It let's us move our programs without having to customize... (So either way, url2path or using os.join, but I think we need to make note of a working method and do our best to wrap it in a convience function) 3) I'm afraid that if we move away from a obvious os.join, that we will be obscuring our code too much. (KISS principal at work) 4) I honestly don't think that the programs can make the absolute paths, unless they are "custom" programs (or it's in a config file that is read). Yes the code needs to be able to manipulate one, but that doesn't mean it has to validate it. For example: c:\windows\system32\drivers\etc\hosts isn't going to automatically be mapped to: guyver:system:hosts That would require me to examine the code/configuration file, or whatever and manually change it. - Benjamin -----Original Message----- From: Jack Jansen [mailto:jack@oratrix.nl] Sent: Wednesday, December 26, 2001 4:14 PM To: Schollnick, Benjamin Cc: 'Donovan Preston'; pythonmac-sig(a)python.org Subject: Re: [Pythonmac-SIG] Using slash-seperated paths for creating FSSp ecs (was: Mach-O MacPython IDE!!!) Recently, "Schollnick, Benjamin" <Benjamin.Schollnick(a)usa.xerox.com> said: > print "path: ", create_platform_path (None) > print "path: ", create_platform_path ( *["develope"] ) > print "path: ", create_platform_path ( *["develope", "bas_common"] ) > print "path: ", create_platform_path ( *["temp", "delete", "me"] ) > test = ["this", "is", "the", "path"] > print "path: ", create_platform_path (*test) I was going to say that I like it too, and I was going to suggest we drop the idea with the python-dev people for inclusion in all platforms, but then I started thinking about it a little more and I realised two things. 1. Something like this will never fly for Windows, where the first component, the disk name, is magic. Actually, it's also uncertain whether it will fly for Mac OS X: the colon-paths start with a disk name (which is somewhat magic) while the / path is a standard unix path. If you're not on the system disk a path like diskname:dirname:filename will become /Volumes/diskname/dirname/filename. 2. We already have a perfectly well-defined way to specify pathnames and their conversion between platform syntaxes: URLs. An url2pathname() followed by basejoin() followed by pathname2url() should always do the trick. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org http://mail.python.org/mailman/listinfo/pythonmac-sig

1 0

Re: [Pythonmac-SIG] Using slash-seperated paths for creating FSSp ecs (was: Mach-O MacPython IDE!!!)
by Jack Jansen Dec. 26, 2001

Dec. 26, 2001

Recently, "Schollnick, Benjamin" <Benjamin.Schollnick(a)usa.xerox.com> said: > print "path: ", create_platform_path (None) > print "path: ", create_platform_path ( *["develope"] ) > print "path: ", create_platform_path ( *["develope", "bas_common"] ) > print "path: ", create_platform_path ( *["temp", "delete", "me"] ) > test = ["this", "is", "the", "path"] > print "path: ", create_platform_path (*test) I was going to say that I like it too, and I was going to suggest we drop the idea with the python-dev people for inclusion in all platforms, but then I started thinking about it a little more and I realised two things. 1. Something like this will never fly for Windows, where the first component, the disk name, is magic. Actually, it's also uncertain whether it will fly for Mac OS X: the colon-paths start with a disk name (which is somewhat magic) while the / path is a standard unix path. If you're not on the system disk a path like diskname:dirname:filename will become /Volumes/diskname/dirname/filename. 2. We already have a perfectly well-defined way to specify pathnames and their conversion between platform syntaxes: URLs. An url2pathname() followed by basejoin() followed by pathname2url() should always do the trick. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Pythonmac-SIG] Please test the 2.2 installer
by Jack Jansen Dec. 26, 2001

Dec. 26, 2001

Recently, "sandro s." <hiss999(a)dircon.co.uk> said: > After playing with 2.2 for a couple of days, I've found the interpreter much > more "reliable" than IDE on OS 9.04 too. Please send bug reports on this, either send "vague" reports here, so other people can tell whether they have similar problems, or submit firm bug reports to the sourceforge bugreporter and assign them to me or Just (jvr). The only problem I'm aware of with the IDE is that the multicolumn browser with reveal triangles looks absolutely wierd on OSX. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

編集部より、お願い
by fukazawa＠134net.com Dec. 26, 2001

Dec. 26, 2001

お忙しいところ申し訳ございません。「湘南パラダイスマガジン」編集部深沢と言います。このメールは、風俗、アダルトサイト、ナイト情報を運営している管理者様へ、送信させて頂いております。７万部発行のナイト情報誌を発行していますが、この度、「人気ＷＥＢサイト紹介」などの編集記事を企画しております。アダルトサイト含そこで今回、情報収集も含めまして、相互リンク形式のランキングシステムを導入しましたので、登録をよろしくお願いいたします。登録して頂いた情報を元に、本紙面で紹介させていただく場合は、改めて、こちらから御連絡させていただきます。登録は http://www.134net.com/ra/html/regist.html 上記より、アカウントを発行しておりますので、ご登録くださいませ。お時間がありましたら、拝見していただければと思います。 http://www.134net.com ------------------------- 湘南パラダイスマガジン編集部　深沢 0463-51-5722 fukazawa(a)134net.com http://www.134net.com/ -------------------------

1 0

RE: [Pythonmac-SIG] Using slash-seperated paths for creating FSSp ecs (was: Mach-O MacPython IDE!!!)
by Schollnick, Benjamin Dec. 26, 2001

Dec. 26, 2001

Donovan, I like the idea....(personally).... It's a interesting use of the overloaded parameters.... I think, this is similiar to what you intend... (In a more formalized, function), and suggestions for improvement? import os def create_platform_path ( list_of_directories, *overflow): """ """ if (list_of_directories <> None): return os.path.join ( list_of_directories, *overflow ) else: return "" print "path: ", create_platform_path (None) print "path: ", create_platform_path ( *["develope"] ) print "path: ", create_platform_path ( *["develope", "bas_common"] ) print "path: ", create_platform_path ( *["temp", "delete", "me"] ) test = ["this", "is", "the", "path"] print "path: ", create_platform_path (*test) - Benjamin -----Original Message----- From: Donovan Preston [mailto:dp@ulaluma.com] Sent: Friday, December 21, 2001 8:57 PM To: pythonmac-sig(a)python.org Subject: [Pythonmac-SIG] Using slash-seperated paths for creating FSSpecs (was: Mach-O MacPython IDE!!!) On Friday, December 21, 2001, at 01:44 PM, Jack Jansen wrote: > > Recently, Donovan Preston <dp(a)ulaluma.com> said: >> Hmm. Well, I suppose the only way to get around this is to explicitly >> state which type of path is being used as Jack suggested, or to always >> assume slash-delimited paths on X and colon-delimited paths on 9. > > I assume you mean "MacPython" where you say 9 and "MachoPython" where > you say X, right? Pathname interpretation is more a function of the > runtime library than of the OS, in the case of Python. Yes, correct, sorry. So I should have said "Always assume slash-delimited paths on Mach-O Python and colon-delimited paths on CFM MacPython." >> Since os.path.join creates slash-delimited strings on X, all of the >> places in the IDE where there is code that looks like >> os.path.join(rootdir, 'my:subdir:etc') are going to have to be replaced >> anyway. I suggest replacing them with os.path.join(*[rootdir, 'my', >> 'subdir', 'etc']) which works no matter what OS you are running under. > > Or, alternatively, use macpath. Os.path is great to get rid of > platform dependencies, but only if you add single components. If > you're using my:subdir:etc you have a Mac dependency anyway, so > there's little to be gained from using os.path. Ah. I wasn't aware there was a macpath module which would do colon-delimiting even on X. Hmm. At first glance I thought that might work, but upon further inspection I recall why sticking to colon-delimited paths won't work on Mach-O MacPython: There are constructions throughout the IDE that look like this: widgetresfile = os.path.join(sys.exec_prefix, ":Mac:Tools:IDE:Widgets.rsrc") Since sys.exec_prefix is specified as a slash-delimited string, even macpath won't help here. And I am strongly opposed to making sys.exec_prefix return a colon-delimited string :-) And rather than convert any slash-delimited string such as sys.exec_prefix to a colon-delimited string prior to using macpath.join, I still contest that it's better to use os.path.join and construct your path segments in a platform agnostic way. Maybe this syntax will be a little more to your (non-obfuscated) liking ;-) pathsegments = [sys.exec_prefix, 'Mac', 'Tools', 'IDE'] path = os.path.join(*pathsegments) Then, the resulting path can be passed to the new FSSpec_New, after it's been updated to conform to your pseudocode, no matter what runtime you are running under and it will work. Donovan _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org http://mail.python.org/mailman/listinfo/pythonmac-sig

1 0

MPW
by sandro s. Dec. 25, 2001

Dec. 25, 2001

Hi bunch Is anyone building Python Modules successfully with MPW? Any documentation apart from the useful link on Jack's page? Ta -- LUThER <hiss999(a)dircon.co.uk> <sandrosonika(a)hotmail.com> (I use this when I'm travelling)

1 0