Mailman 3 July 1999 - Python-Dev

Perl 5.6 'feature list'
by David Ascher 22 Jul '99

22 Jul '99

Not all that exciting, but good to know what they're doing: http://www.perl.com/cgi-bin/pace/pub/1999/06/perl5-6.html

3 2

Python bugs database started
by Guido van Rossum 16 Jul '99

16 Jul '99

Barry has installed Jitterbug on python.org and now we can use it to track Python bugs. I already like it much better than the todo wizard, because the response time is much better (the CGI program is written in C). Please try it out -- submit bugs, search for bugs, etc. The URL is http://www.python.org/python-bugs/. Some of you already subscribed to the mailing list (python-bugs-list) -- beware that this list receives a message for each bug reported and each followup. The HTML is preliminary -- it is configurable (somewhat) and I would like to make it look nicer, but don't have the time right now. There are certain features (such as moving bugs to different folders) that are only accessible to authorized users. If you have a good reason I might authorize you. --Guido van Rossum (home page: http://www.python.org/~guido/)

6 7

ISPs and Python
by Guido van Rossum 16 Jul '99

16 Jul '99

Remember the days when the big problem was to find an ISP who would install Python? Apparently that problem has gone away... The problem is now to get one that installs a decent set of Python extensions :-) See attached c.l.py post. This is similar to the evolution of Python's name recognition -- used to be, managers would say "what's Python?"; then they said "nobody else uses Python"; now presumably they will have to make up some kind ad-hoc no-Python company policy :-) --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Start of forwarded message ------- From: Sim & Golda Zacks <simngolda(a)voyager.net> Newsgroups: comp.lang.python Subject: Re: htmllib, cgi, HTMLfmt, genCGI, HTMLgen, html, Zope, ... Date: Wed, 14 Jul 1999 00:00:25 -0400 Organization: ExecPC Internet - Milwaukee, WI Message-ID: <7mh1qu$c6m(a)newsops.execpc.com> References: <tot2m7.su.ln(a)final.math.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am in the exact same situation as you are. I am a web programmer and I'm trying to implement the CGI and database stuff with Python. I am using the HTMLFMT module from the INTERNET PROGRAMMING book and the cgi module from the standard library. What the HTMLFMT library does for you is just that you don't have to type in all the tags, basically it's nothing magical, if I didn't have it I would have to make something up and it probably wouldn't be half as good. the standard cgi unit gives you all the fields from the form, and I haven't looked at the cgi modules from the book yet to see if they give me any added benefit. The big problem I came across was my web host, and all of the other ones I talked to, refused to install the mysql interface to Python, and it has to be included in the build (or something like that) So I just installed gadfly, which seems to be working great for me right now. I'm still playing with it not in production yet. I have no idea what ZOPE does, but everyone who talks about it seems to love it. Hope this helps Sim Zacks [...] ------- End of forwarded message -------

3 2

RE: Python on Windows chapter.
by Mark Hammond 15 Jul '99

15 Jul '99

I asked Guido to provide comments on one of the chapters in our book: I was discussing appending the mode ("t" or "b") to the open() call > p.10, bottom: text mode is the default -- I've never seen the 't' > option described! (So even if it exists, better be silent about it.) > You need to append 'b' to get binary mode instead. This brings up an interesting issue. MSVC exposes a global variable that contains the default mode - ie, you can change the default to binary. (_fmode for those with the docs) This has some implications and questions: * Will Guido ever bow to pressure (when it arrives :) to expose this via the "msvcrt" module? I can imagine where it may be useful in a limited context. A reasonable argument would be that, like _setmode and other MS specific stuff, if it exists it should be exposed. * But even if not, due to the shared CRTL, in COM and other worlds we really cant predict what the default is. Although Python does not touch it, that does not stop someone else touching it. A web-server built using MSVC on Windows may use it? Thus, it appears that to be 100% sure what mode you are using, you should not rely on the default, but should _always_ use "b" or "t" on the file mode. Any thoughts or comments? The case for abandoning the CRTL's text mode gets stronger and stronger! Mark.

5 8

Re: [Python-Dev] ActiveState & fork & Perl
by Tim Peters 15 Jul '99

15 Jul '99

Moving back in time ... [GordonM] > Perhaps Christian's stackless Python would enable green threads... [Guido] > This has been suggested before... While this seems possible at first, > all blocking I/O calls would have to be redone to pass control to the > thread scheduler, before this would be useful -- a huge task! I didn't understand this. If I/O calls are left alone, and a green thread hit one, the whole program just sits there waiting for the call to complete, right? But if the same thing happens using "real threads" today, the same thing happens today anyway <wink>. That is, if a thread doesn't release the global lock before a blocking call today, the whole program just sits there etc. Or do you have some other kind of problem in mind here? unconvincedly y'rs - tim

11 42

Re: [Python-Dev] Python bugs database started
by Jack Jansen 14 Jul '99

14 Jul '99

> The Jitterbug software is nice for tracking bugs, but its user > interface *SUCKS*. I wish I had the time to redseign that part -- > unfortunately it's probably totally integrated with the rest of the > code... We looked into bug tracking systems recently, and basically they all suck. We went with gnats in the end, but it has pretty similar problems on the GUI side. But maybe we could convince some people with too much time on their hands to do a Python bug reporting system:-) -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

RE: [Python-Dev] Interrupting a thread
by David Ascher 14 Jul '99

14 Jul '99

On Wed, 14 Jul 1999, Gordon McMillan wrote: a reply to the python-dev thread on python-list. You didn't really intend to do that, did you Gordon? =) --david

1 0

Interrupting a thread
by Mark Hammond 14 Jul '99

14 Jul '99

Ive struck this a number of times, and the simple question is "can we make it possible to interrupt a thread without the thread's knowledge" or otherwise stated "how can we asynchronously raise an exception in another thread?" The specific issue is that quite often, I find it necessary to interrupt one thread from another. One example is Pythonwin - rather than use the debugger hooks as IDLE does, I use a secondary thread. But how can I use that thread to interrupt the code executing in the first? (With magic that only works sometimes is how :-) Another example came up on the newsgroup recently - discussion about making Medusa a true Windows NT Service. A trivial solution would be to have a "service thread", that simply runs Medusa's loop in a seperate thread. When the "service thread" recieves a shut-down request from NT, how can it interrupt Medusa? I probably should not have started with a Medusa example - it may have a solution. Pretend I said "any arbitary script written to run similarly to a Unix daemon". There are one or 2 other cases where I have wanted to execute existing code that assumes it runs stand-alone, and can really only be stopped with a KeyboardInterrupt. I can't see a decent way to do this. [I guess this ties into the "signals and threads" limitations - I believe you cant direct signals at threads either?] Is it desirable? Unfortunately, I can see that it might be hard :-( But-sounds-pretty-easy-under-those-fake-threads<wink>-ly, Mark.

4 5

Re: [Python-Dev] End of the line
by Jack Jansen 14 Jul '99

14 Jul '99

> [Jack Jansen] > > This'll work for Unix and PC conventions, but not for the Mac. > > Mac end of line is \r, so reading a line from a mac file on unix will > > give you the whole file. > [...] > > Maybe you're missing that Python reads lines one character at a time? So > e.g. the behavior of the platform libc fgets is irrelevant. You're absolutely right... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Python-Dev] End of the line
by Jack Jansen 14 Jul '99

14 Jul '99

> The Icon implementation is very simple: they *still* open the file in stdio > text mode. "What's natural for the platform" on writing then comes for > free. On reading, libc usually takes care of what's needed, and what > remains is to check for stray '\r' characters that stdio glossed over. This'll work for Unix and PC conventions, but not for the Mac. Mac end of line is \r, so reading a line from a mac file on unix will give you the whole file. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1