From Jack.Jansen@cwi.nl Tue Dec 3 13:36:38 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 03 Dec 1996 14:36:38 +0100 Subject: [PYTHONMAC-SIG] CFM68K considered harmful Message-ID: <9612031336.AA26502=jack@schelvis.cwi.nl> Folks, apparently Apple has sent out a warning that CFM68K in its current form is not stable. I've appended the note as I saw it, from TidBits . It turns out that if an interrupt routine is called for a CFM68K application this may mess up A5. The CFM68K application isn't bothered by this, but if the interrupt happened while a Classic application was running this application will loose A5 and probably proceed to crash in a glorious way. Since Python uses GUSI which uses I/O completion routines this means that the CFM68K version of python is potentially dangerous too. 68K Python users should decide for themselves whether they want to switch back to the Classic 68K Python version or continue to live dangerously. Here is the TidBITS article: **Disable the CFM-68K Runtime Enabler** -- If you use a Macintosh with a 68K processor, Apple is recommending that you disable the CFM-68K Runtime Enabler either by using an extensions manager or by removing it from your System Folder. Some applications that use the CFM-68K Runtime Enabler can crash your Macintosh, possibly causing data loss and other problems. This problem does _not_ affect Power Macs. The Code Fragment Manager (CFM) was originally developed for Power Macs and lets Power Mac applications use shared code libraries (trust me, they're neat). Later, Apple ported the CFM backwards to 68K machines to make it easier for developers build 68K versions of Power Mac applications. Those 68K applications are just now starting to appear, although plenty more are in development. However, Apple now admits to a problem with the 68K version of CFM, and it can't be used reliably in all cases. Though this bug doesn't impact every program that uses CFM-68K, there's no simple way to know which applications are affected. Programs using CFM- 68K include OpenDoc, Cyberdog, Apple Media Tool, LaserWriter 8.4 and 8.4.1, Microsoft Internet Explorer 3.0b1, and the preview of AOL 3.0. If you use any of these programs, Apple recommends you revert to earlier versions or stop using them. If you disable the CFM-68K enabler and try to use one of these applications, you'll see an error, but no damage will be done. Apple is working on a fix, but there's no public timetable for when a solution might be available. [GD] -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From guzdial@cc.gatech.edu Mon Dec 9 20:02:54 1996 From: guzdial@cc.gatech.edu (Mark Guzdial) Date: Mon, 9 Dec 1996 15:02:54 -0500 (EST) Subject: [PYTHONMAC-SIG] Figuring out macfs Message-ID: I was revisiting some code this morning that used the old StdWin file dialogs and translated it into the new macfs forms (based on Jack's example0.html). Below is the code that I tried to run: fsspec, ok = macfs.PromptGetFile('First log file:', 'TEXT') if ok: startFile = fsspec.as_pathname() pieces = splitfields(startFile,":") dir = joinfields(pieces[:len(pieces)-1],":")+":" return dir This was my very first Python code, so I can't defend the structure or technique. But what I want to ask about is that this dumps me into Macsbug. Macsbug says that it dies in "_HSetStateQ" with a memory mapping error. When I escape to shell, I get dumped back into Macsbug everytime I switch try to click on a window/switch-apps. This is on a 7600 running System 7.5.3 using Python PPC 1.4. Any suggestions? Thanks! Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From Jack.Jansen@cwi.nl Fri Dec 13 15:54:53 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 13 Dec 1996 16:54:53 +0100 Subject: [PYTHONMAC-SIG] Gdbm module for Mac available Message-ID: <9612131554.AA03917=jack@schelvis.cwi.nl> In you can find a distribution of a dynamically-loaded gdbm module for MacPython, both for PPC and for CFM68K. The PPC version has been very lightly tested (shelve appears happy with it), the CFM68K version has not been tested at all due to lack of a cfm68k-capable machine currently, so please let me know whether it works at all. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From tomf59@sgi.net Sun Dec 15 21:33:29 1996 From: tomf59@sgi.net (Tom Fetherston) Date: Sun, 15 Dec 1996 16:33:29 -0500 Subject: [PYTHONMAC-SIG] Requests for next release Message-ID: I'am still working on some more "good stuff" for the next release of the python mode for the Alpha editor, (which I'll go over in another note), however, there are a few things that could be added to the python distribution itself that would make for a better marriage between python and Alpha (or even BBedit, if someone writes the functions to take advantage of what I am proposing). Much of the stuff in the python mode was "lifted" from the Perl mode. The marriage between Perl and Alpha is very close due to the extensive appleEvent suites built into Perl. If we could get the same sort of suites added to the mac-python distriution, then the Alpha-python developement evirionment could be made much nicer. Things that you can do in the Alpha-perl environemnt, send a file, buffer to perl and get back a result window, use perl prgrams as filters/sorter etc. for files/text that you have open in Alpha, get a debug window showing program exectution. Create droplets and cgi program right from alpha. Now I can hear the groans from the mac-python maintainer, but there should be some help available. The perl aete resource must be fully written as the python program that helps you to interface to AE's seems to pick up all the supported events. The Perl code is available so it should be possible to graft on the AE code mac-python, in fact, I believe that the GUSI code by Matthias Neeracher is already part of mac-python. Perhaps the authors of MacPerl could be of assistance. Any thoughts? Tom Fetherston ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From tomf59@sgi.net Mon Dec 16 01:50:19 1996 From: tomf59@sgi.net (Tom Fetherston) Date: Sun, 15 Dec 1996 20:50:19 -0500 Subject: [PYTHONMAC-SIG] Future stuff for the Alpha python mode Message-ID: Hi all, It is taking me a bit longer than I planned to get out another version of the python mode for Alpha, so I thought I would tell you what I have planed and get some feedback. What has eaten up the most time is overhualing the template insertion facilities that are avaliable in Alpha. Included in the alpha distribution is a set of files that support a template facility known as ElectricAlias. This hasn't been touched since '92, and Alpha author has expressed surprise that it still works given all the changes alpha has undergone since then. There is a grad student at Havard that has written a lot of code for alpha, much of which has eventually been incorporated into the distribution over the years, who publishes a set of utilities know as "VincesAdditions". It includes a very nice set of utilities for creating templates, however, some of the things he does make it hard to use with python. I've been working on a version that let's you change things so they are more conducive to working in python. This is just about done and could be released separately (along with some python templates) if anyone is interested. A number of people found the colorizing excessive and/or garrish in the choice of colors. If you have come up with your own set of colors that you like, and/or you have turned off colorizing of certain groups of words, please pass this back to me. I'm working on making this more sanely customizable. I've written routines that parse the include and from...includ... statements in such a way that option-clicking on the titlebar will produce a pop-up of the module names. Selecting one of these will open the associated file. You can also cmd-double click a module name and open its file. (note: Alpha 6.5 has a bug in its pop-up routine, you might have to uses a later beta version --usally pretty stable) Two things on this, one - I had to make a copy of the search paths from the pref app, do people modify this a lot? Can I use an AE to get the current settings. Secondly, some of the modules do not seem to have veiwable source code, (they exist as shared Libraries?) I just inform you that these modules can't be viewed. Are there other such modules in places other than the Plug-ins folder? Can you query python for the interface? (hopefully with a AE so I could open a window with the interface). A couple of people have asked about string colorizing, Alpha's string colorizing is built in, delimited by double quotes and constrained to be on a single line, so I don't think I can correct this, however, as I mentioned in a recent reply; > >> >>...The one thing >>that would be nice to have (I don't know how easy it is to do this in >>Alpha) would be to have strings colored properly. I looks like it only >>handles double quote strings, and not single quotes or triple quotes. >>When I use Emacs Python mode, I find that the syntax coloring of strings >>is probably the most useful part of syntax coloring: you can see right >>away when you've left off a terminating quote. >> >I have not figured out anyway to do this yet, the string hilighting that >Alpha supports is built in and locked to double quotes occuring on a >single line. Perhaps I can come up with a string-delimiter balance >function similar to the paren,brace,baracket balancer that momentarily >hilites the opening delimiter when you type the close. Would that be Okay? To support the commenting of programs, (creating and maintaing), I'am considering the following sheme; A module would be parsed for definitions and any existing comments. A file would be created with only these parts (i.e. definiton heads and existing comments--no bodies). These files would be given the module name and a new extension (say .pyd), perhaps they would all end up in a "Doc" subfolder of the parent module's folder. This new file would be easy to naviagate and add comments to. Things like instant templates for presenting a table of the arguments and explantion would be provided. Using this scheme, long comments could be kept separate from the code. You would only have to merge them when you are distributing the modules. Alpha could support hypertext tags between the two. There are a lot of ways to go with this, any ideas? Any feedback or other ideas welcome, Tom Fetherston Pittsburgh, PA USA ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Mon Dec 16 16:10:26 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 16 Dec 1996 11:10:26 -0500 Subject: [PYTHONMAC-SIG] Future stuff for the Alpha python mode In-Reply-To: Your message of "Sun, 15 Dec 1996 20:50:19 EST." References: Message-ID: <199612161610.LAA08330@monty> > It is taking me a bit longer than I planned to get out another version of > the python mode for Alpha, so I thought I would tell you what I have planed > and get some feedback. OK, you asked for feedback -- here it is. First, I've been using your Python mode for Alpha quite a bit now, so here are some things based on real use. My main gripe is that I don't see an obvious way to change the default indentation the way I want to. I'm not very experienced in using Alpha, so maybe it's there somewhere, but I didn't find anything obvious. I want a feature that Emacs mode has, and which is necessary for compatibility with files originating on Unix: while a tab character is worth 8 spaces, the block indentation is worth 4 spaces. So you will find that the first level is indented with 4 spaces, the 2nd level is indented with a single tab, the 3rd level is indented with a tab plus 4 spaces, the 4th level with 2 tabs, and so on. This style is used extensively by many standard library modules -- in fact it is the default style for Emacs nowadays. Notice that setting the *tab stop* to 4 spaces is the wrong thing to do here: it would make the 1st and 2nd level indistinguishable. Please don't tell me that I have to convert all tabs to spaces. My other gripe is that the coloring is a bit too colorful to my taste. For instance, it colors parentheses -- well, this is okay, I suppose -- but it also colors various plain identifiers in ways that are more confusing than useful. In particular, it seems to know most (but not all!) standard methods and built-in function names, and will color these names even where they occur as local variables or methods of unrelated objects. I'd rather not see identifiers colored at all, except in clearly recognizable syntactical positions (e.g. Emacs colors the name of a function or class definition different). I've also noticed that the coloring is very sensitive to backspacing -- oftentimes, when colors look really weird, typing Control-L will fix them. > What has eaten up the most time is overhualing the template insertion > facilities that are avaliable in Alpha. Included in the alpha distribution > is a set of files that support a template facility known as ElectricAlias. I've seen this in the HTML mode, and personally, don't care for them. I'm so used to typing the full syntax that remembering the key sequences for the templates rarely saves me any time. > This hasn't been touched since '92, and Alpha author has expressed surprise > that it still works given all the changes alpha has undergone since then. > There is a grad student at Havard that has written a lot of code for alpha, > much of which has eventually been incorporated into the distribution over > the years, who publishes a set of utilities know as "VincesAdditions". It > includes a very nice set of utilities for creating templates, however, some > of the things he does make it hard to use with python. I've been working > on a version that let's you change things so they are more conducive to > working in python. This is just about done and could be released > separately (along with some python templates) if anyone is interested. > > A number of people found the colorizing excessive and/or garrish in the > choice of colors. If you have come up with your own set of colors that you > like, and/or you have turned off colorizing of certain groups of words, > please pass this back to me. I'm working on making this more sanely > customizable. Ah thanks. Disabling coloring for the "known functions and methods" by default would go a long way for me... > I've written routines that parse the include and from...includ... > statements in such a way that option-clicking on the titlebar will produce > a pop-up of the module names. Selecting one of these will open the > associated file. You can also cmd-double click a module name and open its > file. (note: Alpha 6.5 has a bug in its pop-up routine, you might have to > uses a later beta version --usally pretty stable) Ah this is cool (except for the Alpha beta). > Two things on this, one - I had to make a copy of the search paths from the > pref app, do people modify this a lot? Can I use an AE to get the current > settings. Secondly, some of the modules do not seem to have veiwable > source code, (they exist as shared Libraries?) I just inform you that > these modules can't be viewed. Are there other such modules in places > other than the Plug-ins folder? Can you query python for the interface? > (hopefully with a AE so I could open a window with the interface). I believe the Python interpreter itself has very little AE support (you can write AE-aware Python scripts, but that's another thing), but Jack should answer this one, really. The modules without viewable source code most likely are extensions written in C. Some will be built in (e.g. sys), others can be available as shared libraries (e.g. _tkinter) -- but on the 68k, unless you want to use CFM68k, all such modules are built in. Python's "imp" module has an interface find_module('name') which gives details about what kind of module it is (without actually importing it). See the library reference manual section describing imp. To find the current module search path, use sys.path. > A couple of people have asked about string colorizing, Alpha's string > colorizing is built in, delimited by double quotes and constrained to be on > a single line, so I don't think I can correct this, however, as I mentioned > in a recent reply; > > > >> > >>...The one thing > >>that would be nice to have (I don't know how easy it is to do this in > >>Alpha) would be to have strings colored properly. I looks like it only > >>handles double quote strings, and not single quotes or triple quotes. > >>When I use Emacs Python mode, I find that the syntax coloring of strings > >>is probably the most useful part of syntax coloring: you can see right > >>away when you've left off a terminating quote. > >> > >I have not figured out anyway to do this yet, the string hilighting that > >Alpha supports is built in and locked to double quotes occuring on a > >single line. Perhaps I can come up with a string-delimiter balance > >function similar to the paren,brace,baracket balancer that momentarily > >hilites the opening delimiter when you type the close. > > Would that be Okay? Seems fine for me. Are you serious that Alpha can't hilite single-quote delimited strings? > To support the commenting of programs, (creating and maintaing), I'am > considering the following sheme; > > A module would be parsed for definitions and any existing comments. A file > would be created with only these parts (i.e. definiton heads and existing > comments--no bodies). These files would be given the module name and a new > extension (say .pyd), perhaps they would all end up in a "Doc" subfolder of > the parent module's folder. This new file would be easy to naviagate and > add comments to. Things like instant templates for presenting a table of > the arguments and explantion would be provided. Except that .pyd is a bad choice because it means "PYTHON DLL" on Windows platforms. Sooner or later someone cross mounting file systems would be confused. Maybe use .pyi for Python interface, or .py-doc. Not sure how this feature would be used, personally -- I'd rather keep all my meta info in comments and doc strings in the source file rather than in a separate file. It also sounds like a scheme that would be cumbersome when you're *not* using Alpha... > Using this scheme, long comments could be kept separate from the code. You > would only have to merge them when you are distributing the modules. Alpha > could support hypertext tags between the two. There are a lot of ways to > go with this, any ideas? > > Any feedback or other ideas welcome, > > Tom Fetherston > Pittsburgh, PA USA --Guido van Rossum (home page: http://www.python.org/~guido/) ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From Jack.Jansen@cwi.nl Mon Dec 16 16:55:04 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 16 Dec 1996 17:55:04 +0100 Subject: [PYTHONMAC-SIG] Future stuff for the Alpha python mode In-Reply-To: Message by Guido van Rossum , Mon, 16 Dec 1996 11:10:26 -0500 , <199612161610.LAA08330@monty> Message-ID: <9612161655.AA08989=jack@schelvis.cwi.nl> The AE support needed for Alpha could be added in a matter of minutes, but for one problem: I don't really have control over the Python event loop, and when you send the event the chances are 99.9% that Python will be waiting for keyboard input at the >>> prompt, somewhere deep inside the C library, and even though we could possibly receive the appleevent it would require longjumping out of the stdio code or something similarly horrible. Replacing the sioux window and/or the current mess of event loops is pretty high on my to-do list, and supporting DoScript and such will then definitely be implemented. Until then Justs BBPy stuff will have to do. But, of course, if anyone has code to contribute to make DoScript work with the current event loop I'll be more than happy to accept it:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From tomf59@sgi.net Mon Dec 16 19:30:38 1996 From: tomf59@sgi.net (Tom Fetherston) Date: Mon, 16 Dec 1996 14:30:38 -0500 Subject: [PYTHONMAC-SIG] Requests for next release Message-ID: (I'am reposting this as I got a "no longer any such person at this address" from TRW enterprises server --I apologizie if this actually got through) I'am still working on some more "good stuff" for the next release of the python mode for the Alpha editor, (which I'll go over in another note), however, there are a few things that could be added to the python distribution itself that would make for a better marriage between python and Alpha (or even BBedit, if someone writes the functions to take advantage of what I am proposing). Much of the stuff in the python mode was "lifted" from the Perl mode. The marriage between Perl and Alpha is very close due to the extensive appleEvent suites built into Perl. If we could get the same sort of suites added to the mac-python distriution, then the Alpha-python developement evirionment could be made much nicer. Things that you can do in the Alpha-perl environemnt, send a file, buffer to perl and get back a result window, use perl prgrams as filters/sorter etc. for files/text that you have open in Alpha, get a debug window showing program exectution. Create droplets and cgi program right from alpha. Now I can hear the groans from the mac-python maintainer, but there should be some help available. The perl aete resource must be fully written as the python program that helps you to interface to AE's seems to pick up all the supported events. The Perl code is available so it should be possible to graft on the AE code mac-python, in fact, I believe that the GUSI code by Matthias Neeracher is already part of mac-python. Perhaps the authors of MacPerl could be of assistance. Any thoughts? Tom Fetherston ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From tomf59@sgi.net Mon Dec 16 20:49:55 1996 From: tomf59@sgi.net (Tom Fetherston) Date: Mon, 16 Dec 1996 15:49:55 -0500 Subject: [PYTHONMAC-SIG] Future stuff for the Alpha python mode Message-ID: >>My main gripe is that I don't see an obvious way to change the default >indentation the way I want to. I'm not very experienced in using >Alpha, so maybe it's there somewhere, but I didn't find anything >obvious. I want a feature that Emacs mode has, and which is necessary >for compatibility with files originating on Unix: while a tab >character is worth 8 spaces, the block indentation is worth 4 spaces. block indentation, does this have its own keybing? If so do you use it to put in the four spaces in a single line, or does it do what it sounds like, ident a (selected?) block? >So you will find that the first level is indented with 4 spaces, the >2nd level is indented with a single tab, the 3rd level is indented >with a tab plus 4 spaces, the 4th level with 2 tabs, and so on. This >style is used extensively by many standard library modules -- in fact >it is the default style for Emacs nowadays. Notice that setting the >*tab stop* to 4 spaces is the wrong thing to do here: it would make >the 1st and 2nd level indistinguishable. Please don't tell me that I >have to convert all tabs to spaces. > No, I'll just have to change some of the key invoked procedures, (the ones for return and tab), and get python mode to change the tab lenght to 8 instead of the default of four while in the python mode. >My other gripe is that the coloring is a bit too colorful to my taste. >For instance, it colors parentheses -- well, this is okay, I suppose >-- but it also colors various plain identifiers in ways that are more >confusing than useful. In particular, it seems to know most (but not >all!) standard methods and built-in function names, and will color >these names even where they occur as local variables or methods of >unrelated objects. I'd rather not see identifiers colored at all, >except in clearly recognizable syntactical positions (e.g. Emacs >colors the name of a function or class definition different). I've >also noticed that the coloring is very sensitive to backspacing -- >oftentimes, when colors look really weird, typing Control-L will fix >them. > Yes, the colorizing routines in alpha only go back a few versions, it seems to be implemented by embeding unprintable "color escapes" in the text. In a mode, the colorXon/colorXoff pairs are done dynamically, i.e. only added to the text buffer. These are added when, a) the text is read into the buffer, and b0 as you are typing. The colorizing follows regular expression pattern matching, no actual parsing of the code is done, (Lisp is better at inteligent parsing than Tcl). The combination of inserting/deleting the escapes and then invoking a redraw seems to miss sometimes, usually the colorizing-redraw gets left out, the control-L you mention seems to invoke such a redrw manually. >> What has eaten up the most time is overhualing the template insertion >> facilities that are avaliable in Alpha. Included in the alpha distribution >> is a set of files that support a template facility known as ElectricAlias. > >I've seen this in the HTML mode, and personally, don't care for them. >I'm so used to typing the full syntax that remembering the key >sequences for the templates rarely saves me any time. > To tell the truth, this won't be as useful in python as it is in other modes, languages with begin/end --block type snytax benefit the most from this. There are a lot of useful feature in this (most trying to assist entry without getting you to memorize weird abbreviations), and, I'm planning to write an app that lets you rough out the logic of an algorithm visually, drag it into alpha and get a "fill-in the blanks" type template of the whole thing. >> A number of people found the colorizing excessive and/or garrish in the >> choice of colors. If you have come up with your own set of colors that you >> like, and/or you have turned off colorizing of certain groups of words, >> please pass this back to me. I'm working on making this more sanely >> customizable. > >Ah thanks. Disabling coloring for the "known functions and methods" >by default would go a long way for me... > >> I've written routines that parse the include and from...includ... >> statements in such a way that option-clicking on the titlebar will produce >> a pop-up of the module names. Selecting one of these will open the >> associated file. You can also cmd-double click a module name and open its >> file. (note: Alpha 6.5 has a bug in its pop-up routine, you might have to >> uses a later beta version --usally pretty stable) > >Ah this is cool (except for the Alpha beta). double-clicking on a module name will work in the current release, the option click method runs into what looks likke an "off by one" type error, the first module name get's dropped from the list of modules and the last name is just random garbage. >Seems fine for me. Are you serious that Alpha can't hilite >single-quote delimited strings? > Haven't found ay way to do it yet, since Alpha only uses pattern matching to do its colorizing, and not the parsing that lisp allows, it is pretty easy for you to write legal combinations that exceed strict pattern matching. >> To support the commenting of programs, (creating and maintaing), I'am >> considering the following sheme; >> >> A module would be parsed for definitions and any existing comments. A file >> would be created with only these parts (i.e. definiton heads and existing >> comments--no bodies). These files would be given the module name and a new >> extension (say .pyd), perhaps they would all end up in a "Doc" subfolder of >> the parent module's folder. This new file would be easy to naviagate and >> add comments to. Things like instant templates for presenting a table of >> the arguments and explantion would be provided. > >Except that .pyd is a bad choice because it means "PYTHON DLL" on >Windows platforms. Sooner or later someone cross mounting file >systems would be confused. Maybe use .pyi for Python interface, or >.py-doc. > >Not sure how this feature would be used, personally -- I'd rather keep >all my meta info in comments and doc strings in the source file rather >than in a separate file. It also sounds like a scheme that would be >cumbersome when you're *not* using Alpha... Actaully , the idea is mostly to be an aid to documentating code, (Let's face it, it --does-- tends to be written last). You can quickly write the documentation in this file, merge it into the source, and still have the .pyi file to turn into html and/or hard copy for reference. > Tom Fetherston Pittsburgh, PA USA ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Mon Dec 16 21:30:36 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 16 Dec 1996 16:30:36 -0500 Subject: [PYTHONMAC-SIG] Future stuff for the Alpha python mode In-Reply-To: Your message of "Mon, 16 Dec 1996 15:49:55 EST." References: Message-ID: <199612162130.QAA09228@monty> > >I want a feature that Emacs mode has, and which is necessary > >for compatibility with files originating on Unix: while a tab > >character is worth 8 spaces, the block indentation is worth 4 spaces. > > block indentation, does this have its own keybing? If so do you use it to > put in the four spaces in a single line, or does it do what it sounds like, > ident a (selected?) block? This is used in a number of places: first, when you type a command like 'if' or 'def', the next line is indented by this much (rather than by a tab character). Next, commands like block shift left (dedent) and block shift right (indent) shift by this amount. Finally, Emacs' Python mode has a way to automatically "re-indent" a line or a block, and it will use this indentation for each level. > No, I'll just have to change some of the key invoked procedures, (the ones > for return and tab), and get python mode to change the tab lenght to 8 > instead of the default of four while in the python mode. OK, this is fine. > Haven't found ay way to do it yet, since Alpha only uses pattern matching > to do its colorizing, and not the parsing that lisp allows, it is pretty > easy for you to write legal combinations that exceed strict pattern > matching. Well, a string literal is easy enough recognizable as a pattern -- if we don't mind that multi-line strings are botched. Try this (using Python's regex syntax -- I don't know Alpha's but it can't be too different): '\([^'\\]\|\\.\)*' (where the quotes are part of the pattern!) Similar for double quotes. --Guido van Rossum (home page: http://www.python.org/~guido/) ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From friedric@rose.rsoc.rockwell.com Mon Dec 16 21:29:44 1996 From: friedric@rose.rsoc.rockwell.com (Robin Friedrich) Date: Mon, 16 Dec 1996 15:29:44 -0600 Subject: [PYTHONMAC-SIG] Future stuff for the Alpha python mode Message-ID: <199612162129.PAA26626@darwin.rsoc.rockwell.com> |>Tom writes: |> >Guido writes: |> >>My main gripe is that I don't see an obvious way to change the default |> >indentation the way I want to. I'm not very experienced in using |> >Alpha, so maybe it's there somewhere, but I didn't find anything |> >obvious. I want a feature that Emacs mode has, and which is necessary |> >for compatibility with files originating on Unix: while a tab |> >character is worth 8 spaces, the block indentation is worth 4 spaces. |> |> block indentation, does this have its own keybing? If so do you use it to |> put in the four spaces in a single line, or does it do what it sounds like, |> ident a (selected?) block? No it just figures the minimal combination of (8space)tabs and 4 space segments needed when you need the next deeper indent (after a :). Personally I don't like this scheme and turn it to just straight spaces in emacs with (setq-default indent-tabs-mode nil). The tabs thing just complicates matters and having a feature in Alpha to always expand tabs to spaces would be fine with me. |> |> >So you will find that the first level is indented with 4 spaces, the |> >2nd level is indented with a single tab, the 3rd level is indented |> >with a tab plus 4 spaces, the 4th level with 2 tabs, and so on. This |> >style is used extensively by many standard library modules -- in fact |> >it is the default style for Emacs nowadays. Notice that setting the |> >*tab stop* to 4 spaces is the wrong thing to do here: it would make |> >the 1st and 2nd level indistinguishable. Please don't tell me that I |> >have to convert all tabs to spaces. |> > |> No, I'll just have to change some of the key invoked procedures, (the ones |> for return and tab), and get python mode to change the tab lenght to 8 |> instead of the default of four while in the python mode. |> >My other gripe is that the coloring is a bit too colorful to my taste. |> >For instance, it colors parentheses -- well, this is okay, I suppose |> >-- but it also colors various plain identifiers in ways that are more |> >confusing than useful. In particular, it seems to know most (but not |> >all!) standard methods and built-in function names, and will color |> >these names even where they occur as local variables or methods of |> >unrelated objects. I'd rather not see identifiers colored at all, |> >except in clearly recognizable syntactical positions (e.g. Emacs |> >colors the name of a function or class definition different). |> I agree with Guido. I prefer just hiliting language keywords and strings. Hopefully the doc string problem can be fixed. [snip - color delimiter discussion] |> |> >> What has eaten up the most time is overhualing the template insertion |> >> facilities that are avaliable in Alpha. Included in the alpha distribution |> >> is a set of files that support a template facility known as ElectricAlias. |> > |> >I've seen this in the HTML mode, and personally, don't care for them. |> >I'm so used to typing the full syntax that remembering the key |> >sequences for the templates rarely saves me any time. |> > |> To tell the truth, this won't be as useful in python as it is in other |> modes, languages with begin/end --block type snytax benefit the most from |> this. There are a lot of useful feature in this (most trying to assist |> entry without getting you to memorize weird abbreviations), and, I'm |> planning to write an app that lets you rough out the logic of an algorithm |> visually, drag it into alpha and get a "fill-in the blanks" type template |> of the whole thing. Although the fill-in-the-blanks idea may be useful, I probably wouldn't find myself using templates in Alpha. Python's just too easy.;-) [snip - snip] |> >> To support the commenting of programs, (creating and maintaing), I'am |> >> considering the following sheme; |> >> |> >> A module would be parsed for definitions and any existing comments. A file |> >> would be created with only these parts (i.e. definiton heads and existing |> >> comments--no bodies). These files would be given the module name and a new |> >> extension (say .pyd), perhaps they would all end up in a "Doc" subfolder of |> >> the parent module's folder. This new file would be easy to naviagate and |> >> add comments to. Things like instant templates for presenting a table of |> >> the arguments and explantion would be provided. |> > |> >Except that .pyd is a bad choice because it means "PYTHON DLL" on |> >Windows platforms. Sooner or later someone cross mounting file |> >systems would be confused. Maybe use .pyi for Python interface, or |> >.py-doc. |> > |> >Not sure how this feature would be used, personally -- I'd rather keep |> >all my meta info in comments and doc strings in the source file rather |> >than in a separate file. It also sounds like a scheme that would be |> >cumbersome when you're *not* using Alpha... |> |> Actaully , the idea is mostly to be an aid to documentating code, (Let's |> face it, it --does-- tends to be written last). You can quickly write the |> documentation in this file, merge it into the source, and still have the |> .pyi file to turn into html and/or hard copy for reference. I would stay away from separate files. You might check out gendoc on the www.python.org site. It can generate documentation from the doc strings and program structure automatically. [http://www.python.org/sigs/doc-sig] -Robin Friedrich ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Mon Dec 16 21:55:12 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 16 Dec 1996 16:55:12 -0500 Subject: [PYTHONMAC-SIG] Future stuff for the Alpha python mode In-Reply-To: Your message of "Mon, 16 Dec 1996 15:29:44 CST." <199612162129.PAA26626@darwin.rsoc.rockwell.com> References: <199612162129.PAA26626@darwin.rsoc.rockwell.com> Message-ID: <199612162155.QAA09392@monty> > No it just figures the minimal combination of (8space)tabs and 4 > space segments needed when you need the next deeper indent (after a > :). Personally I don't like this scheme and turn it to just > straight spaces in emacs with (setq-default indent-tabs-mode > nil). The tabs thing just complicates matters and having a feature > in Alpha to always expand tabs to spaces would be fine with me. Yes. You will at least have to accept files containing a mix of tabs and spaces, and understand that a tab is worth 8 spaces. --Guido van Rossum (home page: http://www.python.org/~guido/) ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From tomf59@sgi.net Tue Dec 17 03:45:36 1996 From: tomf59@sgi.net (Tom Fetherston) Date: Mon, 16 Dec 1996 22:45:36 -0500 Subject: [PYTHONMAC-SIG] Requests for next release Message-ID: Jack, I keep getting this back as undileverable, so I send it to you (and just cc it to the sig). I'am still working on some more "good stuff" for the next release of the python mode for the Alpha editor, (which I'll go over in another note), however, there are a few things that could be added to the python distribution itself that would make for a better marriage between python and Alpha (or even BBedit, if someone writes the functions to take advantage of what I am proposing). Much of the stuff in the python mode was "lifted" from the Perl mode. The marriage between Perl and Alpha is very close due to the extensive appleEvent suites built into Perl. If we could get the same sort of suites added to the mac-python distriution, then the Alpha-python developement evirionment could be made much nicer. Things that you can do in the Alpha-perl environemnt, send a file, buffer to perl and get back a result window, use perl prgrams as filters/sorter etc. for files/text that you have open in Alpha, get a debug window showing program exectution. Create droplets and cgi program right from alpha. Now I can hear the groans from the mac-python maintainer, but there should be some help available. The perl aete resource must be fully written as the python program that helps you to interface to AE's seems to pick up all the supported events. The Perl code is available so it should be possible to graft on the AE code mac-python, in fact, I believe that the GUSI code by Matthias Neeracher is already part of mac-python. Perhaps the authors of MacPerl could be of assistance. Any thoughts? Tom Fetherston ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From Jack.Jansen@cwi.nl Tue Dec 17 14:52:39 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 17 Dec 1996 15:52:39 +0100 Subject: [PYTHONMAC-SIG] PIL 0.2b3 available for MacPython Message-ID: <9612171452.AA18757=jack@schelvis.cwi.nl> I've ported the 0.2b3 distribution of the Python Image Library to the mac, and made it available as . The distribution includes a modified version of the _tkinter plugin module that understands how to paint PIL images in Tk windows. As always, the dynamic extension modules are available for PPC and CFM68K, and all relevant Python modules are included so the distribution is self-contained. The PPC version successfully runs the demo scripts, the CFM68K version has not been tested at all, so please let me know whether it works. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From Jack.Jansen@cwi.nl Tue Dec 17 11:58:47 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 17 Dec 1996 12:58:47 +0100 Subject: [PYTHONMAC-SIG] Numeric Python 1.0a5 for the Mac available Message-ID: <9612171158.AA16973=jack@schelvis.cwi.nl> I've put the Numeric extension modules (both cfm68k and PPC) for MacPython 1.4 in . The distribution has the dynamically loadable modules for both architectures and the python modules, so it should be self-contained. The PPC version has been tested lightly (it passes the selftest and the demo scripts appear to work), the CFM68K version has not been tested at all, due to me lacking a CFM68K-capable machine right now. Please let me know whether things work. Also a question for the matrix-sig people: I've had to make some minor fixes to the sources, whom should I send these to? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Tue Dec 17 23:06:47 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Tue, 17 Dec 1996 18:06:47 -0500 Subject: [PYTHONMAC-SIG] PIL 0.2b3 available for MacPython In-Reply-To: Your message of "Tue, 17 Dec 1996 15:52:39 +0100." <9612171452.AA18757=jack@schelvis.cwi.nl> References: <9612171452.AA18757=jack@schelvis.cwi.nl> Message-ID: <199612172306.SAA13687@monty> Jack wrote: > I've ported the 0.2b3 distribution of the Python Image Library to the > mac, and made it available as > . The > distribution includes a modified version of the _tkinter plugin module > that understands how to paint PIL images in Tk windows. As always, the > dynamic extension modules are available for PPC and CFM68K, and all > relevant Python modules are included so the distribution is > self-contained. > > The PPC version successfully runs the demo scripts, the CFM68K version > has not been tested at all, so please let me know whether it works. Jack's CFM68K version was an almost empty file. I've built a proper one (with JPEG support but without ZLIB support -- not sure what this affects) and placed it (temporarily) on ftp.python.org in /pub/tmp/_imaging.CFM68K.slb.sit.hqx; I presume Jack will rework it into his distribution eventually. --Guido van Rossum (home page: http://www.python.org/~guido/) ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From billpy@mail.demon.net Wed Dec 18 22:52:16 1996 From: billpy@mail.demon.net (Bill Bedford) Date: Wed, 18 Dec 1996 22:52:16 +0000 Subject: [PYTHONMAC-SIG] AE Coercions Message-ID: Can anyone suggest a way of coercing python boolean into a AppleEvent Boolean type? This is needed to be able to script Eudora in particular. ----------------------------------------------------------------------- Bill Bedford Designer of Photo-Etches billb@mousa.demon.co.uk owner Brit_Rail-L --- british railways historical list ----------------------------------------------------------------------- ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From Jack.Jansen@cwi.nl Thu Dec 19 10:09:36 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 19 Dec 1996 11:09:36 +0100 Subject: [PYTHONMAC-SIG] AE Coercions In-Reply-To: Message by Bill Bedford , Wed, 18 Dec 1996 22:52:16 +0000 , Message-ID: <9612191009.AA08974=jack@schelvis.cwi.nl> > Can anyone suggest a way of coercing python boolean into a AppleEvent > Boolean type? Doesn't sending an integer work? From my (limited) understanding of OSA I would guess that the coercion would then be done on the receiving side... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From tomf59@sgi.net Thu Dec 26 04:46:46 1996 From: tomf59@sgi.net (Tom Fetherston) Date: Wed, 25 Dec 1996 23:46:46 -0500 Subject: [PYTHONMAC-SIG] Re: Add default tclsh text resource Message-ID: >Status: U >Date: Wed, 25 Dec 1996 10:22:52 -0800 >Reply-To: mactcl@sunlabs.eng.Sun.COM >Originator: mactcl@eng.sun.com >Sender: mactcl@sunlabs.eng.Sun.COM >Precedence: junk >From: Matthias Ulrich Neeracher >To: tomf59@sgi.net >Subject: Re: Add default tclsh text resource >X-Comment: Macintosh Tcl Mailing List > >rscheen@metrolink.net (rscheen) writes: >>Someone else: >>>Please could you add a default "cshrc" text resource into wish ? >>> >>>I think a default behavior should source the texte file by double >>>clicking on it and report error in console. >>> >>>The user should only have to set the creator of the text file to WIsH. >> >>That sounds like a fabulous idea. But why stop there? I just love how >>MacPerl was ported (by Matthias Neeracher..?) > >Yes, it was me. Thanks. > >>--with a built in text editor, and the ability to load/save/etc, and make >>double clickable and drag-n-droppable apps. I know since the Mac Toolbox >>already has a built-in text-editor "widget", this might be fairly easy to >>do (alas...if I had a recent version of Code Warrior, I might try to tackle >>it myself :). > >Funny like all Mac VHLL porters seem to wrestle with the same issues. A few >days ago, I exchanged mail with the Python Porthers about the same topic. >A few remarks: > > - Using TexEdit is a suboptimal idea. In 1993, alternatives were not readily > available, but in 1996, you should have a good reason not to use WASTE > before considering TextEdit. > - Possibly, just making a restartable, DoScript capable, wish and adapting > the MacPerl support code for Alpha and BEdit would keep people just > as happy with far less effort. > - Droplets are trivial if you have DoScript AppleEvent support. > - The major effort with MacPerl was to make the interpreter restartable. > For Tcl, this should be much less of an issue, since Tcl is designed > for interpreters to be constructed and destructed at will > - Feel free to borrow any code you need from the MacPerl sources > (Apparently my source code is so incomprehensible that de facto > hardly anybody ever takes me up on such offers :-) > >Matthias > >----- >Matthias Neeracher http://www.iis.ee.ethz.ch/~neeri > "Faced with the choice between changing one's own mind and proving that > there is no need to do so, almost everyone gets busy on the proof. " > -- John Kenneth Galbraith > ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From jay@tinkeri.com Sat Dec 28 01:50:16 1996 From: jay@tinkeri.com (Jay Koutavas) Date: Fri, 27 Dec 1996 20:50:16 -0500 Subject: [PYTHONMAC-SIG] Embedding PythonCorePPC, Howto? Message-ID: Hiya. I'm new to Python in general. My current purpose for Python is to embed it into a CodeWarrior PowerPlant-based telnet-like application I have written to give it the ability to interpret and act on certain incoming strings. I have tried to use PythonCorePPC (v1.4) as a shared library, that is, I've added it to a simple CodeWarrior (CW10) test project and then attempted to initialize it using Py_Initialize(). I haven't gotten too far. From the Debugger I'm seeing that the break point I put in immediately after the Py_Initialize() call is never being reached. I assume Python is sitting in its own event loop by this point, not returning from Py_Initialize(). My host application isn't going to give Python a SIOUX console. Python's interface to my host app is via variables being passed in and out. I DON'T want to call the Mac application initilization gear found in macmain.c, for my host application is already nicely setup via PowerPlant by the time Python initialization rolls along. I want to initialize Python and then return control to my host application. Will Python throw a fit without having control of SIOUX? Also, I get lots of warnings, over 380 of them, when I link to PythonCorePPC to my project. Lot's of duplicate library references which can be resolved rather straight forward by removing libraries from either project, yet it indicates again that maybe I'm going about this the wrong way. I get the feeling there is another approach I should be taking, or do you just tolerate all these warnings when you embed? So, am I on the right track here, or should I build my own custom Python shared library from the source kit? If I should do my own shared library, what gotchas do I need to concern myself with (what files should I include/not include)? I would ABSOLUTELY LOVE to see a small example CodeWarrior project that does embedding that uses PythonCorePPC in the means I am. Some guidance please? /Jay ``''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''``` Jay Koutavas mailto:jay@tinkeri.com Tinkeri, Inc. http://www.tinkeri.com Windham, NH, USA ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''````` ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From Ivan.Herman@cwi.nl Mon Dec 30 11:09:53 1996 From: Ivan.Herman@cwi.nl (Ivan Herman) Date: Mon, 30 Dec 1996 12:09:53 +0100 Subject: [PYTHONMAC-SIG] Default Tk attributes? Message-ID: If I use Tk on a UNIX box, the X resource mechanism gives me a way to give default values for various attributes like background colour, font, etc. Tk is (more or less) prepared to follow the Xresource style in this respect. Is there an analoguous mechanism on the Mac? To give a very specific example, the font used by default in, e.g., Button or Label are far too big for my small PowerBook screen. The only way I could do it up to now is to set the font explicitely for each widget I create, but some more general way would be much nicer. If there is no such mechanism in general (on Macs), the question is: should there be? This may be a general mechanism for Tkinter, regardless of the platform at hand. For example, I could say Button.config({'font' : 'Helvetica'}) i.e., use a class level function to set the defaults for each Button instance. Such settings can then be put into a separate module to be loaded by a program, thereby ensuring proper defaults for an environment. Ivan ----- Ivan Herman Centre for Mathematics and Computer Sciences Kruislaan 413 1098 SJ Amsterdam tel: +31-20-592.41.63 fax: +31-20-592.41.99 Email: Ivan.Herman@cwi.nl URL: http://www.cwi.nl/~ivan/ ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Mon Dec 30 15:39:04 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 30 Dec 1996 10:39:04 -0500 Subject: [PYTHONMAC-SIG] Default Tk attributes? In-Reply-To: Your message of "Mon, 30 Dec 1996 12:09:53 +0100." References: Message-ID: <199612301539.KAA21692@monty> > If I use Tk on a UNIX box, the X resource mechanism gives me a way > to give default values for various attributes like background > colour, font, etc. Tk is (more or less) prepared to follow the > Xresource style in this respect. > Is there an analoguous mechanism on the Mac? To give a very specific > example, the font used by default in, e.g., Button or Label are far > too big for my small PowerBook screen. The only way I could do it up > to now is to set the font explicitely for each widget I create, but > some more general way would be much nicer. The Tk "option" command (in Tkinter, the widget methods option_add(), option_clear(), option_get() and option_readline()) can be used to manipulate defaults for widget options, I believe. See the Tk man page for option. It looks like it would be easy to have a file of options in X resource style and read that at the start of your program. --Guido van Rossum (home page: http://www.python.org/~guido/) ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From Ivan.Herman@cwi.nl Tue Dec 31 14:43:28 1996 From: Ivan.Herman@cwi.nl (Ivan Herman) Date: Tue, 31 Dec 1996 15:43:28 +0100 Subject: [PYTHONMAC-SIG] Default Tk attributes? In-Reply-To: Your message of "Mon, 30 Dec 1996 10:39:04 MET." <199612301539.KAA21692@monty> Message-ID: <9612311443.AA07818=ivan@petunia.cwi.nl> ------------------ Your Original Message: -------------------- > > > The Tk "option" command (in Tkinter, the widget methods option_add(), > option_clear(), option_get() and option_readline()) can be used to > manipulate defaults for widget options, I believe. See the Tk man > page for option. It looks like it would be easy to have a file of > options in X resource style and read that at the start of your > program. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > Oops, I was a bit too fast in sending the question to the list... Indeed, the methods are there and they work. Better, there is also an option_readfile() which does exactly what you suggest. The reason why I haven't realized that the functions are there is because I looked at the Tkinter Life Preserver doc only, which does not refer to these methods (they are defined for the class 'Misc'), and I haven't looked at the Tkinter sources... Having said that, there is still a very small difference in the cross-platform behaviours: I guess the file ~/.xdefaults is automatically considered by Tk on UNIX (at least that is what Matt's book says). On the other hand, there is definitely no automatic configuration on the Mac. What it would require is to slightly modify the Tkinter file to read in such a file and interpret it in, say, the __init__ of the class Misc (or Tk). Is it worth bothering? Maybe not... Ivan ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org ================= From guido@CNRI.Reston.Va.US Tue Dec 31 15:50:18 1996 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Tue, 31 Dec 1996 10:50:18 -0500 Subject: [PYTHONMAC-SIG] Default Tk attributes? In-Reply-To: Your message of "Tue, 31 Dec 1996 15:43:28 +0100." <9612311443.AA07818=ivan@petunia.cwi.nl> References: <9612311443.AA07818=ivan@petunia.cwi.nl> Message-ID: <199612311550.KAA25549@monty> > Having said that, there is still a very small difference in the > cross-platform behaviours: I guess the file ~/.xdefaults is > automatically considered by Tk on UNIX (at least that is what Matt's > book says). On the other hand, there is definitely no automatic > configuration on the Mac. What it would require is to slightly modify > the Tkinter file to read in such a file and interpret it in, say, the > __init__ of the class Misc (or Tk). Is it worth bothering? Maybe not... There's already a "user profile" option in Tkinter. The Tk class calls the following method on startup: def readprofile(self, baseName, className): import os if os.environ.has_key('HOME'): home = os.environ['HOME'] else: home = os.curdir class_tcl = os.path.join(home, '.%s.tcl' % className) class_py = os.path.join(home, '.%s.py' % className) base_tcl = os.path.join(home, '.%s.tcl' % baseName) base_py = os.path.join(home, '.%s.py' % baseName) dir = {'self': self} exec 'from Tkinter import *' in dir if os.path.isfile(class_tcl): print 'source', `class_tcl` self.tk.call('source', class_tcl) if os.path.isfile(class_py): print 'execfile', `class_py` execfile(class_py, dir) if os.path.isfile(base_tcl): print 'source', `base_tcl` self.tk.call('source', base_tcl) if os.path.isfile(base_py): print 'execfile', `base_py` execfile(base_py, dir) It seems that on the Mac this will execute a file ``..py'' (note leading dot!) in the current directory, where is the class passed to Tk -- it defaults to 'Tk'. It will also read ``..py'' where basename is the base component of sys.argv[0] -- in other words, the script or program name. --Guido van Rossum (home page: http://www.python.org/~guido/) ================= PYTHONMAC-SIG - SIG on Python for the Apple Macintosh send messages to: pythonmac-sig@python.org administrivia to: pythonmac-sig-request@python.org =================