Mailman 3 July 1999 - Python-Dev

RE: [Python-Dev] RE: NT select.select?
by Brian Lloyd July 30, 1999

July 30, 1999

Guido wrote: > > Brian, > > (Also in response to your bug report.) I'm a little worried that > upping the limit to 1024 would cause some performance problems if > you're making a lot of select() calls. The select allocates three > arrays of length FD_SETSIZE+3; each array item is 12 bytes. This is a > total allocation of more than 36K for a meager select() call! > And all > that memory also has to be cleared by the FD_ZERO() call. > > If you actually … [View More]

3 2

RE: NT select.select?
by Brian Lloyd July 30, 1999

July 30, 1999

> Is there some low limit on maximum number of sockets you can > have in the > Python-NT's select call? A program that happens to work > perfectly on Linux > seems to die on NT around 64(?) sockets to the 'too many file > descriptors > in call' error. > > Any portable ways to bypass it? > > -Markus Hi Markus, It turns out that NT has a default 64 fd limit on arguments to select(). The good news is that you can actually bump the limit up to whatever … [View More]

2 1

Re: [Python-Dev] End of the line
by Jack Jansen July 28, 1999

July 28, 1999

> [Jack seems to like an asynch IO model] > > > def foo(): > > obj = stdin.delayed_read() > > obj2 = stdout.delayed_write("data") > > do_lengthy_computation() > > data = obj.get() # Here we wait for the read to complete > > del obj2 # Here we wait for the write to > > complete. > > > > This gives a fairly nice programming model. > > Indeed. Taking this a little further, I come up with something like: > > inlock … [View More]

3 3

Tcl news
by David Ascher July 28, 1999

July 28, 1999

8.2b1 is released: Some surprising news: they now use cygwin tools to do the windows build. Not surprising news: they still haven't incorporated some bug fixes I submitted eons ago =) http://www.scriptics.com/software/relnotes/tcl8.2b1 --david

1 0

Re: [Python-Dev] End of the line
by Jack Jansen July 27, 1999

July 27, 1999

> What Im getting at is that a Python IO model should maybe go a little > further than "tradtional" IO - asynchronous IO and synchronisation > capabilities should also be specified. Of course, these would be optional, > but it would be excellent if a platform could easily slot into pre-defined > Python semantics if possible. What Python could do with reasonable ease is a sort of "promise" model, where an I/O operation returns an object that waits for the I/O to complete upon … [View More]

2 1

continuations for the curious
by Christian Tismer July 27, 1999

July 27, 1999

Howdy, my modules are nearly ready. I will be out of my office for two weeks, but had no time to finalize and publish yet. Stackless Python has reached what I wanted it to reach: A continuation can be saved at every opcode. The continuationmodule has been shrunk heavily. Some extension is still needed, continuations are still frames, but they can be picked like Sam wanted it originally. Sam, I'm pretty sure this is more than enough for coroutines. Just have a look at getpcc(), this is now … [View More]

3 3

I'd like list.pop to accept an optional second argument giving a default value
by Jim Fulton July 27, 1999

July 27, 1999

I like the list pop method because it provides a way to use lists as thread safe queues and stacks (since append and pop are protected by the global interpreter lock). With pop, you can essentially test whether the list is empty and get a value if it isn't in one atomic operation: try: foo=queue.pop(0) except IndexError: ... empty queue case else: ... non-empty case, do something with foo Unfortunately, this incurs exception overhead. I'd rather do something like: … [View More]

9 42

RE: [Python-Dev] End of the line
by Brian Lloyd July 26, 1999

July 26, 1999

> [Tim, notes that Perl line-at-a-time text mode input runs 3x > faster than > Python's on his platform] > > And much to my surprise, it turns out Perl reads lines a > character at a time > too! And they do not reimplement stdio. But they do cheat. > > [some notes on the cheating and PerlIO api snipped] > > The usual *implementation* of these guys is as straight macro > substitution > to the corresponding C stdio call. It's possible to > … [View More]

3 2

continuationmodule.c preview
by Christian Tismer July 25, 1999

July 25, 1999

Howdy, please find attached my latest running version of continuationmodule.c which is really able to do continuations. You need stackless Python 0.3 for it, which I just submitted. This module is by no means ready. The central functions are getpcc() and putcc. Call/cc is at the moment to be done like: def callcc(fun, *args, **kw): cont = getpcc() return apply(fun, (cont,)+args, kw) getpcc(level=1) gets a parent's current continuation. putcc(cont, val) throws a continuation. At … [View More]

5 8

Importing extension modules
by M.-A. Lemburg July 22, 1999

July 22, 1999

I'm currently testing a pure Python version of mxDateTime (my date/time package), which uses a contributed Python version of the C extension. Now, to avoid problems with pickled DateTime objects (they include the complete module name), I would like to name *both* the Python and the C extension version mxDateTime. With the current lookup scheme (shared mods are searched before Python modules) this is no problem since the shared mod is found before the Python version and used instead, so getting … [View More]

1 0

Perl 5.6 'feature list'
by David Ascher July 22, 1999

July 22, 1999

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 July 16, 1999

July 16, 1999

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 … [View More]

6 7

ISPs and Python
by Guido van Rossum July 16, 1999

July 16, 1999

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 … [View More]

3 2

RE: Python on Windows chapter.
by Mark Hammond July 15, 1999

July 15, 1999

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 … [View More]

5 8

Re: [Python-Dev] ActiveState & fork & Perl
by Tim Peters July 14, 1999

July 14, 1999

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 … [View More]

11 42

Re: [Python-Dev] Python bugs database started
by Jack Jansen July 14, 1999

July 14, 1999

> 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:-)… [View More]

3 2

RE: [Python-Dev] Interrupting a thread
by David Ascher July 14, 1999

July 14, 1999

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 July 14, 1999

July 14, 1999

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 … [View More]

4 5

Re: [Python-Dev] End of the line
by Jack Jansen July 14, 1999

July 14, 1999

> [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 … [View More]

1 0

Re: [Python-Dev] End of the line
by Jack Jansen July 14, 1999

July 14, 1999

> 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 | +… [View More]

2 1

Fancy control flow
by Tim Peters July 12, 1999

July 12, 1999

Responding to a msg of Guido's that shows up in the archives but didn't come across the mail link (the proper authorities have been notified, and I'm sure appropriate heads will roll at the appropriate pace <wink> ...). > From guido(a)CNRI.Reston.VA.US Mon, 05 Jul 1999 08:06:03 -0400 > Date: Mon, 05 Jul 1999 08:06:03 -0400 > From: Guido van Rossum guido(a)CNRI.Reston.VA.US > Subject: Fake threads (was [Python-Dev] ActiveState & fork & Perl) [generators, coroutines, … [View More]continuations] > I still don't understand all of this (I have not much of an idea of > what Christian's search for hidden registers is about and what kind of > analysis he needs) but I think of continuations as requiring > (theoretically) coping the current stack (to and from), while > generators and coroutines just need their own piece of stack set aside. A generator needs one frame, period (its own!). "Modern" coroutines can get more involved, mixing regular calls with coroutine transfers in arbitrary ways. About Christian's mysterious quest, we've been pursuing it offline. By "hidden registers" I think he means stuff on the eval stack that should *not* be saved/restored as part of a continuation's state. It's not clear to me that this isn't the empty set. The most debatable case I've seen is the Python "for" loop, which hides an anonymous loop counter on the stack. for i in seq: if func1(i): func2(i) This is more elaborate than necessary <wink>, but since it's the one we've discussed offline I'll just stick with it. Suppose func1 saves a continuation on the first iteration, and func2 invokes that continuation on the fifth. Does the resumed continuation "see" the loop as being on its first iteration or as being on its fifth? In favor of the latter is that the loop above "should be" equivalent to this: hidden = 0 while 1: try: temp = seq[hidden] except IndexError: break hidden = hidden + 1 i = temp if func1(i): func2(i) since that's what "for" *does* in Python. With the latter spelling, it's clear that the continuation should see the loop as being on its fifth iteration (continuations see changes in bindings, and making the loop counter a named local exposes it to that rule). But if the entire eval stack is (conceptually) saved/restored, the loop counter is part of it, so the continuation will see the loop counter at its old value. I think it's arguable either way, and argued in favor of "fifth" initially. Now I'm uncertain, but leaning toward "first". > The difference between any of these and threads (fake or real) is that > they pass control explicitly, while threads (typically) presume > pre-emptive scheduling, i.e. they make independent parallel progress > without explicit synchronization. Yes. > (Hmm, how do you do this with fake threads? Or are these only required > to switch whenever you touch a mutex?) I'd say they're only *required* to switch when one tries to acquire a mutex that's already locked. It would be nicer to switch them as ceval already switches "real threads", that is give another one a shot every N bytecodes. > I'm not sure if there's much of a difference between generators and > coroutines -- it seems just the termination convention. A generator is a semi-coroutine, but is the easier half <wink>. > (Hmm... would/should a generator be able to raise an exception in its > caller? Definitely. This is all perfectly clear for a generator -- it has a unique & guaranteed still-active place to return *to*. Years ago I tried to rename them "resumable functions" to get across what a trivial variation of plain functions they really are ... > A coroutine?) This one is muddier. A (at line A1) transfers to B (at line B1), which transfers at line B2 to A (at line A2), which at line A3 transfers to B (at line B3), and B raises an exception at line B4. The obvious thing to do is to pass it on to line A3+1, but what if that doesn't catch it either? We got to A3 from A2 from B2 from B1, but B1 is long gone. That's a real difference with generators: resuming a generator is stack-like, while a co-transfer is just moving control around a flat graph, like pushing a pawn around a chessboard. The coroutine implementation I posted 5 years ago almost punted on this one: if any coroutine suffered an unhandled exception, all coroutines were killed and an EarlyExit exception was raised in "the main coroutine" (the name given to the thread of your code that created the coroutine objects to begin with). Deserves more thought than that, though. or-maybe-it-doesn't<wink>-ly y'rs - tim [View Less]

4 12

Win32 Extensions Registered Users
by Mark Hammond July 10, 1999

July 10, 1999

Hi all, As you may or may not have noticed, I have recently begun offering a Registered Users" program where people who use my Windows extensions can pay $50.00 per 2 years, and get a range of benefits. The primary benefits are: * Early access to binary versions. * Registered Users only mailing list (very low volume to date) * Better support from me. The last benefit really isnt to this list - anyone here will obviously get (and hopefully does get) a pretty good response should they need to … [View More]

1 0

RE: Fake threads (was [Python-Dev] ActiveState & fork & Perl)
by Ken Manheimer July 8, 1999

July 8, 1999

Christian wrote: > Really, no concern necessary. The state is not saved at all > (despite one frame), it is just not dropped. :-) I have to say, that's not completely reassuring.-) While little or nothing additional is created, stuff that normally would be quite transient remains around. > To shorten this: The whole story is nothing more than a tree, > where exactly one leaf is active at any time, and its view > of the call chain is always linear. That's wonderful - i … [View More]

2 1

Welcome to Chris Petrilli
by Guido van Rossum July 6, 1999

July 6, 1999

Chris, would you mind posting a few bits about yourself? Most of the people on this list have met each other at one point or another (with the big exception of the elusive Tim Peters :-); it's nice to know more than a name... --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: Welcome Jean-Claude Wippler
by Jean-Claude Wippler July 6, 1999

July 6, 1999

Thank you Guido, for admitting this newbie to Python-dev :) [Guido: ... you are mostly interested in lurking ... digest mode ...] Fear of being flooded by email, a little shy (who, me?), and yes, a bit of curiosity. Gosh, I got to watch my steps, you figured it all out :) Thanks again. I went through the last month or so of discussion, and am fascinated by the topics and issues you guys are dealing with. And now, seeing Tim's generator/coroutine/continuations description is fantastic. … [View More]

1 0