Mailman 3 May 1999 - Python-Dev

another good motivation
by rushing＠nightmare.com May 18, 1999

May 18, 1999

"Escaping the event loop: an alternative control structure for multi-threaded GUIs" http://cs.nyu.edu/phd_students/fuchs/ http://cs.nyu.edu/phd_students/fuchs/gui.ps -Sam

1 0

Re: [Python-Dev] coroutines vs. continuations vs. threads
by rushing＠nightmare.com May 18, 1999

May 18, 1999

Jeremy Hylton writes: > I have to admit that I'm a bit unclear on the motivation for all > this. As Gordon said, the state machine approach seems like it would > be a good approach. For simple problems, state machines are ideal. Medusa uses state machines that are built out of Python methods. But past a certain level of complexity, they get too hairy to understand. A really good example can be found in /usr/src/linux/net/ipv4. 8^) -Sam

1 0

coroutines vs. continuations vs. threads
by rushing＠nightmare.com May 18, 1999

May 18, 1999

Aaron Watters writes: > Frankly, I think I thought I understood this once but now I know I > don't. 8^) That's what I said when I backed into the idea via medusa a couple of years ago. > How're continuations more powerful than coroutines? And why can't > they be implemented using threads (and semaphores etc)? My understanding of the original 'coroutine' (from Pascal?) was that it allows two procedures to 'resume' each other. The classic coroutine example is the 'samefringe' problem: given two trees of differing structure, are they equal in the sense that a traversal of the leaves results in the same list? Coroutines let you do this efficiently, comparing leaf-by-leaf without storing the whole tree. continuations can do coroutines, but can also be used to implement backtracking, exceptions, threads... probably other stuff I've never heard of or needed. The reason that Scheme and ML are such big fans of continuations is because they can be used to implement all these other features. Look at how much try/except and threads complicate other language implementations. It's like a super-tool-widget - if you make sure it's in your toolbox, you can use it to build your circular saw and lathe from scratch. Unfortunately there aren't many good sites on the web with good explanatory material. The best reference I have is "Essentials of Programming Languages". For those that want to play with some of these ideas using little VM's written in Python: http://www.nightmare.com/software.html#EOPL -Sam

1 0

RE: [Python-Dev] coroutines vs. continuations vs. threads
by Ken Manheimer May 17, 1999

May 17, 1999

Jeremy Hylton: > I have to admit that I'm a bit unclear on the motivation for all > this. As Gordon said, the state machine approach seems like it would > be a good approach. If i understand what you mean by state machine programming, it's pretty inherently uncompartmented, all the combinations of state variables need to be accounted for, so the number of states grows factorially on the number of state vars, in general it's awkward. The advantage of going with what functional folks come up with, like continuations, is that it tends to be well compartmented - functional. (Come to think of it, i suppose that compartmentalization as opposed to state is their mania.) As abstract as i can be (because i hardly know what i'm talking about) (but i have done some specifically finite state machine programming, and did not enjoy it), Ken klm(a)digicool.com

1 0

'stackless' python?
by rushing＠nightmare.com May 15, 1999

May 15, 1999

[list has been quiet, thought I'd liven things up a bit. 8^)] I'm not sure if this has been brought up before in other forums, but has there been discussion of separating the Python and C invocation stacks, (i.e., removing recursive calls to the intepreter) to facilitate coroutines or first-class continuations? One of the biggest barriers to getting others to use asyncore/medusa is the need to program in continuation-passing-style (callbacks, callbacks to callbacks, state machines, etc...). Usually there has to be an overriding requirement for speed/scalability before someone will even look into it. And even when you do 'get' it, there are limits to how inside-out your thinking can go. 8^) If Python had coroutines/continuations, it would be possible to hide asyncore-style select()/poll() machinery 'behind the scenes'. I believe that Concurrent ML does exactly this... Other advantages might be restartable exceptions, different threading models, etc... -Sam rushing(a)nightmare.com rushing(a)eGroups.net

9 18

My (possibly delusional) book project
by David Beazley May 5, 1999

May 5, 1999

Although this is a little off-topic for the developer list, I want to fill people in on a new Python book project. A few months ago, I was approached about doing a new Python reference book and I've since decided to proceed with the project (after all, an increased presence at the bookstore is probably a good thing :-). In any event, my "vision" for this book is to take the material in the Python tutorial, language reference, library reference, and extension guide and squeeze it into a compact book no longer than 300 pages (and hopefully without having to use a 4-point font). Actually, what I'm really trying to do is write something in a style similar to the K&R C Programming book (very terse, straight to the point, and technically accurate). The book's target audience is experienced/expert programmers. With this said, I would really like to get feedback from the developer community about this project in a few areas. First, I want to make sure the language reference is in sync with the latest version of Python, that it is as accurate as possible, and that it doesn't leave out any important topics or recent developments. Second, I would be interested in knowing how to emphasize certain topics (for instance, should I emphasize class-based exceptions over string-based exceptions even though most books only cover the former case?). The other big area is the library reference. Given the size of the library, I'm going to cut a number of modules out. However, the choice of what to cut is not entirely clear (for now, it's a judgment call on my part). All of the work in progress for this project is online at: http://rustler.cs.uchicago.edu/~beazley/essential/reference.html I would love to get constructive feedback about this from other developers. Of course, I'll keep people posted in any case. Cheers, Dave

1 0

Python for Small Systems patch
by Ivan Porres Paltor May 5, 1999

May 5, 1999

Python for Small Systems is a minimal version of the python interpreter, intended to run on small embedded systems with a limited amount of memory. Since there is some interest in the newsgroup, we have decide to release an alpha version of the patch. You can download the patch from the following page: http://www.abo.fi/~iporres/python There is no documentation about the changes, but I guess that it is not so difficult to figure out what Raul has been doing. There are some simple examples in the Demo/hitachi directory. The configure scripts are broken. We plan to modify the configure scripts for cross-compilation. We are still testing, cleaning and trying to reduce the memory requirements of the patched interpreter. We also plan to write some documentation. Please send comments to Raul (rparra(a)abo.fi) or to me (iporres(a)abo.fi), Regards, Ivan -- Ivan Porres Paltor Turku Centre for Computer Science Åbo Akademi, Department of Computer Science Phone: +358-2-2154033 Lemminkäinengatan 14A FIN-20520 Turku - Finland http://www.abo.fi/~iporres

2 3

New mailing list: python-bugs-list
by Barry A. Warsaw May 3, 1999

May 3, 1999

I've been using Jitterbug for a couple of weeks now as my bug database for Mailman and JPython. So it was easy enough for me to set up a database for Python bug reports. Guido is in the process of tailoring the Jitterbug web interface to his liking and will announce it to the appropriate forums when he's ready. In the meantime, I've created YAML that you might be interested in. All bug reports entered into Jitterbug will be forwarded to python-bugs-list(a)python.org. You are invited to subscribe to the list by visiting http://www.python.org/mailman/listinfo/python-bugs-list Enjoy, -Barry

3 2