From ita.mis@euro.apple.com  Thu Dec  4 08:58:36 1997
From: ita.mis@euro.apple.com (Tasselli Marco)
Date: Thu, 04 Dec 1997 09:58:36 +0100
Subject: [PYTHONMAC-SIG] CGI error condition
Message-ID: <348670B8.7C3FFD65@euro.apple.com>

Hi,

I have a problem dealing with CGI crashes.

When the bundled applet used for CGI (compiled with mkapplet) encounter
an error condition (outside a try/except clause), it stop executing
leaving the stdout window open with a <<terminated>> title.
The problem is that there is no way to quit the program, in order to
correct it, other than using a command-option-escape sequence and, of
course, this is not possible at all if you use Timbuktu to control a
remote server.
In the case of an unattended remote server this is very dangerous.

Is there any way to solve this problem?
Or, better yet, any way to directly reload a corrected module in the
running CGI application?

best regards
Tasselli Marco


_______________
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  4 11:27:08 1997
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Thu, 04 Dec 1997 12:27:08 +0100
Subject: [PYTHONMAC-SIG] CGI error condition
In-Reply-To: Message by Tasselli Marco <ita.mis@euro.apple.com> ,
 Thu, 04 Dec 1997 09:58:36 +0100 , <348670B8.7C3FFD65@euro.apple.com>
Message-ID: <UTC199712041127.MAA23803.jack@snelboot.cwi.nl>


Recently, Tasselli Marco <ita.mis@euro.apple.com> said:

> When the bundled applet used for CGI (compiled with mkapplet) encounter
> an error condition (outside a try/except clause), it stop executing
> leaving the stdout window open with a <<terminated>> title.
> The problem is that there is no way to quit the program, in order to
> correct it, other than using a command-option-escape sequence and, of
> course, this is not possible at all if you use Timbuktu to control a
> remote server.

Try clearing the "keep console open on normal/error exit" by dropping
the applet on editpythonprefs.

On a side note: since you seem to be actually *using* the CGI stuff:
do you think you could provide me with some reasonably easy to
understand (and generally useable) example CGI scripts? I created the
framework and did some cursory tests, but never got around to actually
exercising the stuff...
--
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 just@knoware.nl  Thu Dec  4 12:08:08 1997
From: just@knoware.nl (Just van Rossum)
Date: Thu, 4 Dec 1997 13:08:08 +0100
Subject: [PYTHONMAC-SIG] CGI error condition
In-Reply-To: <348670B8.7C3FFD65@euro.apple.com>
Message-ID: <l03102801b0ac4c7b71a9@[193.78.237.46]>

At 9:58 AM +0100 12/4/97, Tasselli Marco wrote:
>I have a problem dealing with CGI crashes.
>
>When the bundled applet used for CGI (compiled with mkapplet) encounter
>an error condition (outside a try/except clause), it stop executing
>leaving the stdout window open with a <<terminated>> title.
>The problem is that there is no way to quit the program, in order to
>correct it, other than using a command-option-escape sequence and, of
>course, this is not possible at all if you use Timbuktu to control a
>remote server.
>In the case of an unattended remote server this is very dangerous.

I think this aspect was left as an excercise for the reader...

>Is there any way to solve this problem?
>Or, better yet, any way to directly reload a corrected module in the
>running CGI application?

I have once modified the cgi demo,  I basically turned it into a Python server:
It would run the requested .py file, and would catch all errors. This
worked fine
with QuidQuoPro, although I have never used it in a real live environment for
longer than half an hour. I could try and dig this thing up (but I might be
that
the correct version in on my friend's computer, who is on holiday now.)

Just



_______________
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  Wed Dec 17 13:50:22 1997
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Wed, 17 Dec 1997 14:50:22 +0100
Subject: [PYTHONMAC-SIG] Organization of toolbox modules and such
Message-ID: <UTC199712171350.OAA27155.jack@snelboot.cwi.nl>

With the new import semantics I am tempted to restructure the toolbox
interfaces, but this will be an incompatible change. I would like some
feedback (and reasonably quickly, because this will have to be in
1.5b2 to be tested before a final 1.5 release).

I have the following three possibilities:
1) Rename Mac:toolbox and Mac:scripting to Mac:lib-toolbox and
   Mac:lib-scripting, modify the initial sys.path and be done with it.
2) Remove Mac:toolbox and Mac:scripting from sys.path. Rename the
   dynamically loaded toolbox interfaces to have an _ prepended to
   their names, and create new modules like Mac:toolbox:Win.py which
   import * from _Win and include all the constants that are currently
   in Window.py. (For compatability Window.py could import * from Win).
3) Same as (2), but also rename Mac:toolbox and Mac:scripting
   to Mac:macos and Mac:macscript. Rename the builtin module MacOS to
   macpython (or possibly macsys).

(1) doesn't really change anything (except bring the names in line
with Guido's new scheme). (2) means people will have to modify their
programs, where they have "import Win" currently this will have to
change to "from toolbox import Win". My preference would be *not* to
do the compatability measure of having Window.py mirror Win.py,
because people will have to go into their source to modify it anyway
so they might as well do it all at once, but this is open to
discussion. (3) is the most incompatible solution, but does leave us
with a structure that I find very pleasing. "from macos import Win" is
self-documenting also to non-mac programmers. Also, the name of the
module MacOS has been bothering me for years, being both wrong and
capitalised. Wrong because the functionality is similar to "sys",
python-interpreter settings and such, but mac-specific, and the
capitalised bit speaks for itself. macos.__init__.py would (if
possible) check for being imported as MacOS and scream loudly in that
case.

Solutions 2 and 3 have the added advantage of shortening sys.path,
which is also rather desirable given the already too long import times
on the mac.

Oh yes, the new name for "scripting" is also open to
discussion. "osasuite" or something similar might be a better choice
than "macscripting" (since the folder contains suites only), and the
latter name might lead people to expect that AE can also be found
there. 
--
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 just@knoware.nl  Wed Dec 17 14:27:28 1997
From: just@knoware.nl (Just van Rossum)
Date: Wed, 17 Dec 1997 15:27:28 +0100
Subject: [PYTHONMAC-SIG] Organization of toolbox modules and such
In-Reply-To: <UTC199712171350.OAA27155.jack@snelboot.cwi.nl>
Message-ID: <l03102805b0bd8c938a69@[193.78.237.36]>

At 2:50 PM +0100 12/17/97, Jack Jansen wrote:
>With the new import semantics I am tempted to restructure the toolbox
>interfaces, but this will be an incompatible change. I would like some
>feedback (and reasonably quickly, because this will have to be in
>1.5b2 to be tested before a final 1.5 release).

(Since we skipped 1.5b1 I think we should take our time to get it right.
Perhaps even release a 1.5b3 for the Mac only if neccesary...)

>I have the following three possibilities:
>1) Rename Mac:toolbox and Mac:scripting to Mac:lib-toolbox and
>   Mac:lib-scripting, modify the initial sys.path and be done with it.

Definitely my preferred solution.

>2) Remove Mac:toolbox and Mac:scripting from sys.path. Rename the
>   dynamically loaded toolbox interfaces to have an _ prepended to
>   their names, and create new modules like Mac:toolbox:Win.py which
>   import * from _Win and include all the constants that are currently
>   in Window.py. (For compatability Window.py could import * from Win).

Can't shared libs be part of packages? But...

>3) Same as (2), but also rename Mac:toolbox and Mac:scripting
>   to Mac:macos and Mac:macscript. Rename the builtin module MacOS to
>   macpython (or possibly macsys).

...I feel very uncomfortable with both 2 & 3: it will break almost
everything I have ever written. I also don't really see the need: although
the toolbox stuff could be viewed as a package, it really isn't, in the
sense that you'd never want to install it seperately.

Please don't.

Renaming MacOS to something more appropriate seems not worth the trouble.
It feels almost like the discussion there once was on the main list about
renaming dict.has_key() to dict.haskey() to make it more consistent with
hasattr(). Plus it will break lots of my IDE, preventing it from being used
with 1.4, unless I make a horrible kludge.

>Solutions 2 and 3 have the added advantage of shortening sys.path,
>which is also rather desirable given the already too long import times
>on the mac.

They shorten MacPath, but because of your _Win etc. kludge importing will
be slowed down again for those modules. I have setup with a *very* long
sys.path with lots of files in each folder: it's slow but acceptable.

>Oh yes, the new name for "scripting" is also open to
>discussion. "osasuite" or something similar might be a better choice
>than "macscripting" (since the folder contains suites only), and the
>latter name might lead people to expect that AE can also be found
>there.

Ok.

Just



_______________
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  Wed Dec 17 21:42:13 1997
From: guido@CNRI.Reston.Va.US (Guido van Rossum)
Date: Wed, 17 Dec 1997 16:42:13 -0500
Subject: [PYTHONMAC-SIG] Organization of toolbox modules and such
In-Reply-To: Your message of "Wed, 17 Dec 1997 14:50:22 +0100."
 <UTC199712171350.OAA27155.jack@snelboot.cwi.nl>
References: <UTC199712171350.OAA27155.jack@snelboot.cwi.nl>
Message-ID: <199712172142.QAA05236@eric.CNRI.Reston.Va.US>

> With the new import semantics I am tempted to restructure the toolbox
> interfaces, but this will be an incompatible change. I would like some
> feedback (and reasonably quickly, because this will have to be in
> 1.5b2 to be tested before a final 1.5 release).
> 
> I have the following three possibilities:
> 1) Rename Mac:toolbox and Mac:scripting to Mac:lib-toolbox and
>    Mac:lib-scripting, modify the initial sys.path and be done with it.
> 2) Remove Mac:toolbox and Mac:scripting from sys.path. Rename the
>    dynamically loaded toolbox interfaces to have an _ prepended to
>    their names, and create new modules like Mac:toolbox:Win.py which
>    import * from _Win and include all the constants that are currently
>    in Window.py. (For compatability Window.py could import * from Win).
> 3) Same as (2), but also rename Mac:toolbox and Mac:scripting
>    to Mac:macos and Mac:macscript. Rename the builtin module MacOS to
>    macpython (or possibly macsys).

I have to agree with Just's response (to leave things alone, i.e., do
#1).  Note that with the advent of package import in 1.5, I could have
restructured the standard Python library -- but I didn't.  I'd rather
do it right later, when I have enough time to think about it and get
feedback.  Not breaking code that worked under 1.4 is also a great
beneficial effect from being conservative here.

--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  Tue Dec 23 11:32:03 1997
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Tue, 23 Dec 1997 12:32:03 +0100
Subject: [PYTHONMAC-SIG] Organization of toolbox modules and such
In-Reply-To: Message by Jack Jansen <Jack.Jansen@cwi.nl> ,
 Wed, 17 Dec 1997 14:50:22 +0100 , <UTC199712171350.OAA27155.jack@snelboot.cwi.nl>
Message-ID: <UTC199712231132.MAA04497.jack@snelboot.cwi.nl>


Recently, Jack Jansen <Jack.Jansen@cwi.nl> said:
> With the new import semantics I am tempted to restructure the toolbox
> interfaces, but this will be an incompatible change.

Well, I got two negative replies from Just and Guido, who felt that
the incompatabilities introduced outweigh any positive effects, and
only one positive reply.

I'll assume the whole idea was either stupid or it's time has not yet
come, and 1.5b2 will be distributed with the folder structure as it
was before, only with Mac:Lib:toolbox and scripting renamed to
lib-toolbox and lib-scripting.
--
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 Zachary_Roadhouse@brown.edu  Tue Dec 30 20:50:15 1997
From: Zachary_Roadhouse@brown.edu (Zachary Roadhouse)
Date: Tue, 30 Dec 1997 14:50:15 -0600
Subject: [PYTHONMAC-SIG] Tkinter Menu Problem with 1.5a4
Message-ID: <v02140b03b0cf0e5539c2@[207.208.4.188]>


I have Tcl/Tk 8.0p2 and Python 1.5a4 and am experiencing the following
problem. None of my menu items appear to work.  I opened up the wish
application and tested menus there and everything worked fine.  However,
when I try the new style menu declaration using Tkinter, no menu items
work.  Help!

                        --Zack

/---------------------------------------------------------------------
Zachary F. Roadhouse                               Home: (401)453-9943
Box 220, Brown University, Providence, RI 02912    Work: (401)863-2177
E-MAIL: Zachary_Roadhouse@brown.edu
WWW: http://www.techhouse.brown.edu/~zack/



_______________
PYTHONMAC-SIG  - SIG on Python for the Apple Macintosh

send messages to: pythonmac-sig@python.org
administrivia to: pythonmac-sig-request@python.org
_______________