Re: [9fans] Serving 9p in python - anyone started that?

Re: [9fans] Serving 9p in python - anyone started that?

[Russ Cox]

> What sort of thread support does python have?  It would be great to see
> it with limbo-style concurrency constructs.

Christian Tismer is working on this.
See www.stackless.com -- the mailing list
archives are the best place to look for real
information.

Russ

Re: [9fans] Serving 9p in python - anyone started that?

[Boyd Roberts]

Russ Cox wrote:
 > Christian Tismer is working on this.  See www.stackless.com ...

He is.  It's kinda bizarre.

For 9p servers I guess the people to convince would be:

    http://www.twistedmatrix.com

Re: [9fans] Serving 9p in python - anyone started that?

[matt]

> > I think the python thing is quite cool,
>
> me three, especially if there were a generic framework for making
> fileservers of python objects. so that, say,
> obj.method('arg', 'arg')
> becomes
> echo -n method arg arg > /mnt/python/obj
>
> and variables can be files available for reading.

when I suggested this ages ago I think most people thought I was mad



http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=20011128
1818.fASII3T58143%40devil.lucid&rnum=4&prev=/groups%3Fq%3Dgroup:comp.os.plan
9%2Bpython%2Bmatt%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D20011
1281818.fASII3T58143%2540devil.lucid%26rnum%3D4

but I still think it will fly

Re: [9fans] Serving 9p in python - anyone started that?

[markp]

> I think the python thing is quite cool,

me three, especially if there were a generic framework for making
fileservers of python objects. so that, say,
	obj.method('arg', 'arg')
becomes
	echo -n method arg arg > /mnt/python/obj

and variables can be files available for reading.

Re: [9fans] Serving 9p in python - anyone started that?

[Dan Cross]

Scott writes:
> What sort of thread support does python have?  It would be great to see
> it with limbo-style concurrency constructs.

And Matt responds:
> http://www.python.org/doc/current/lib/module-thread.html
>
> [...]

So it's the standard co-routine style.  I think that Scott is looking
for is something with a more CSP-like feel, like Limbo.  Stackless
python is doing this, which sounds pretty sweet, but I think that
python is getting a little heavy around the waste.  At least, the
standard distribution is; some objects are marked deprecated and such,
and flag errors at runtime when invoked in the interactive environment,
but not when run as a script, etc....  Still, I like the language.
Ruby is another nice language in a similar vein that I like a lot.

	- Dan C.

Re: [9fans] Serving 9p in python - anyone started that?

[William Josephson]

On Thu, Nov 14, 2002 at 01:28:41PM -0500, Scott Schwartz wrote:
> | i like to think of python as a limbo that doesn't require
> | limbo's environment and is thus more widespread.
>
> What sort of thread support does python have?  It would be great to see
> it with limbo-style concurrency constructs.

I think "stackless" Python comes closest.
Should be able to find information via Google.

Re: [9fans] Serving 9p in python - anyone started that?

[matt]

----- Original Message -----
From: "Scott Schwartz" <schwartz@bio.cse.psu.edu>
To: <9fans@cse.psu.edu>
Sent: Thursday, November 14, 2002 6:28 PM
Subject: Re: [9fans] Serving 9p in python - anyone started that?


> | i like to think of python as a limbo that doesn't require
> | limbo's environment and is thus more widespread.
>
> What sort of thread support does python have?  It would be great to see
> it with limbo-style concurrency constructs.

http://www.python.org/doc/current/lib/module-thread.html

7.4 thread -- Multiple threads of control

This module provides low-level primitives for working with multiple threads
(a.k.a. light-weight processes or tasks) -- multiple threads of control
sharing their global data space. For synchronization, simple locks (a.k.a.
mutexes or binary semaphores) are provided.

The module is optional. It is supported on Windows NT and '95, SGI IRIX,
Solaris 2.x, as well as on systems that have a POSIX thread (a.k.a.
``pthread'') implementation.

see also

http://www.python.org/doc/current/lib/module-threading.html
7.5 threading -- Higher-level threading interface

Re: [9fans] Serving 9p in python - anyone started that?

[Scott Schwartz]

| i like to think of python as a limbo that doesn't require
| limbo's environment and is thus more widespread.

What sort of thread support does python have?  It would be great to see
it with limbo-style concurrency constructs.

Re: [9fans] Serving 9p in python - anyone started that?

[Scott Schwartz]

> I think the python thing is quite cool,

Me too!

Re: [9fans] Serving 9p in python - anyone started that?

[John E. Barham]

> Just curiosity. Why did you take that way instead of trying to get
> a toolset for doing rc 9p servers?

Familiarity with Python mostly.  It never occurred to me to use rc and I
don't know how one would go about doing it.

    John

Re: [9fans] Serving 9p in python - anyone started that?

[Russ Cox]

porting lib9p to python would actually be very easy.
a lot of the code in lib9p is to handle things like my
own hash tables and various kludges with function
pointers that really make objects.

i like to think of python as a limbo that doesn't require
limbo's environment and is thus more widespread.

Re: [9fans] Serving 9p in python - anyone started that?

[Ronald G. Minnich]

> > Just curiosity. Why did you take that way instead of trying to get
> > a toolset for doing rc 9p servers? I mean, IMHO, rc is the
> > preferred way of scripting.

never complain about work somebody else does for free. You don't like it,
change the channel :=)

I think the python thing is quite cool, and I plan to use it to validate
our forthcoming 4e server for Linux (we're still 3e).

ron

Re: [9fans] Serving 9p in python - anyone started that?

[matt]

nemo wrote :
> For those times when it's not so simple I'd prefer to do that
> in a language like limbo instead, and resort to C just when I need a
> sharpen tool.

Kenji wrote :
>Could we have more complete script language for this purpose?

python is both of these things ( albeit without {} ) with the additional
possible benefit of being able to bring in outside source code without a
need for something like APE

I love scripting languages.

I get the same feeling of beauty from python that I get from plan9

Writing a user level fs in C is not as simple as I'd hoped it would be. I
have managed to get one to fly but I'm sure it's cumbersome (it's
temporarily broken and I don't know what I changed 3 months ago to make it
not work).

It's frustrating to have ideas for file systems but then be bogged down in
an implementation that you know would be easier if it was a bit more
abstract.

m

Re: [9fans] Serving 9p in python - anyone started that?

[Fco.J.Ballesteros]

> or data to an appropreate control or data files.   Yes, I agree.   However,
> rc is the one on which we do all those work?   I don't want to live with
> shell scripts even such rc.  Could we have more complete script
> language for this purpose?

When I wanted to be able to do 9p rc scripting, the tasks at hand were
simple.  For those times when it's not so simple I'd prefer to do that
in a language like limbo instead, and resort to C just when I need a
sharpen tool.

In fact, this summer I did a limbo to C translator, trying to get a
limbo version working natively in Plan 9.  My idea was to write also a
companion that could allow the translated limbo code to work with the
native libraries, so that the Alef history would not repeat (thrown
away because things had to be maintained twice, AFAIK).

Sadly, I was not happy at all with how it worked and I just did throw
it away.  Maybe next summer ;-)

Re: [9fans] Serving 9p in python - anyone started that?

[okamoto]

> Just curiosity. Why did you take that way instead of trying to get
> a toolset for doing rc 9p servers? I mean, IMHO, rc is the
> preferred way of scripting. I've some times wanted to
> be able to plug rc scripts into a generic 9p server skeleton,
> and alto to write an rc script that uses other tools to speak 9p.

Yeah!
Plan 9 uses files as object, and all the applications could be constructed
as a user level file server.   Yes, I agree this is the right way to us.

So, we can write many of user interfaces as scripts to write command
or data to an appropreate control or data files.   Yes, I agree.   However,
rc is the one on which we do all those work?   I don't want to live with
shell scripts even such rc.  Could we have more complete script
language for this purpose?

Kenji   -- yes, I'm not an expert of this field

Re: [9fans] Serving 9p in python - anyone started that?

[Russ Cox]

> Just curiosity. Why did you take that way instead of trying to get
> a toolset for doing rc 9p servers? I mean, IMHO, rc is the
> preferred way of scripting. I've some times wanted to
> be able to plug rc scripts into a generic 9p server skeleton,
> and alto to write an rc script that uses other tools to speak 9p.

i don't know about john, but i did my 9p python code because
i was sick of c getting in my way while trying to write the 9p
tester.  the c version was all details i didn't care about.  the
python version is nice and simple.  i would like to be able to
use rc instead, but it wasn't clear how to do that.  rc is a nice
shell but it's not the best programming environment.
my example is the install scripts.  they push the limit of
what you really want to be doing in an rc script.  (transitive
closure, for instance.)

Re: [9fans] Serving 9p in python - anyone started that?

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

Just curiosity. Why did you take that way instead of trying to get
a toolset for doing rc 9p servers? I mean, IMHO, rc is the
preferred way of scripting. I've some times wanted to
be able to plug rc scripts into a generic 9p server skeleton,
and alto to write an rc script that uses other tools to speak 9p.

[-- Attachment #2: Type: message/rfc822, Size: 2469 bytes --]

From: "John E. Barham" <jbarham@jbarham.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Serving 9p in python - anyone started that?
Date: Wed, 13 Nov 2002 11:33:07 -0800
Message-ID: <012d01c28b4b$7e8aaa20$620da8c0@HPN5415>

I've started writing a generic 9P server in Python.  I'm aiming to have
something comparable to <9p.h> that will handle the 9P invariants but allow
one to override whatever methods are needed for your particular service.
With Python's good win32 extensions it should be relatively simple to let
Plan 9 boxes speak to an SMB network.

Re: [9fans] Serving 9p in python - anyone started that?

[John E. Barham]

I've started writing a generic 9P server in Python.  I'm aiming to have
something comparable to <9p.h> that will handle the 9P invariants but allow
one to override whatever methods are needed for your particular service.
With Python's good win32 extensions it should be relatively simple to let
Plan 9 boxes speak to an SMB network.

Re: [9fans] Serving 9p in python - anyone started that?

[Russ Cox]

yep.  here's a minimal 9p2000 test scaffolding.
it predates the python dial, hence the weird exec of aux/trampoline
in connetwork.

all i wrote was version testing.  but the fcall module
is complete.  and the arg parser is nice.



# To unbundle, run this file
echo 9ptest
sed 's/.//' >9ptest <<'//GO.SYSIN DD 9ptest'
-#!/bin/python
-
-from arg import ArgParser
-from fcall import *
-from plan9 import *
-from plan9 import _exec
-import plan9, sys
-
-t,r = None, None
-fd = None
-Tag = 1
-chatty = 0
-
-def chat(s):
-	if chatty:
-		sys.stderr.write(s+'\n')
-		sys.stderr.flush()
-
-def conservice(name):
-	return plan9.open(name, plan9.ORDWR)
-
-def connetwork(addr):
-	return concommand('aux/trampoline '+addr)
-
-def concommand(cmd):
-	p = pipe()
-	pid = rfork(RFFDG|RFPROC|RFNOWAIT)
-	if pid == 0:
-		try:
-			close(p[0])
-			dup(p[1], 0)
-			dup(p[1], 1)
-			_exec('/bin/rc', ['rc', '-c', cmd])
-		except Exception, msg:
-			sys.stderr.write('cmd exec: '+str(msg)+'\n')
-			sys.stderr.flush()
-			sys.exit(1)
-	else:
-		close(p[1])
-		return p[0]
-
-def tx(_t):
-	global t, r
-	t = _t
-	pkt = t.unload()
-	chat('-> %s' % (t,))
-	n = write(fd, pkt)
-	try:
-		pkt = read9pmsg(fd)
-		r = Fcall()
-		r.load(pkt)
-	except Exception, e:
-		sys.stdout.write('sent: '+str(t)+'\n')
-		sys.stdout.write('error receiving response: '+str(e)+'\n')
-#		sys.exit(1)
-		raise
-	chat('<- %s' % (r,))
-	return r
-
-def note(s):
-	sys.stdout.write('sent: '+str(t)+'\n')
-	sys.stdout.write('recv: '+str(r)+'\n')
-	sys.stdout.write(s+'\n')
-	sys.stdout.flush()
-
-def testversion():
-	r = tx(mkfcall(Tflush, Tag, 42))
-	if r.type != Terror:
-		note('server should reject messages before first Tversion is sent')
-
-	# test various msizes and versions
-	def test(msize, vers, expectvers='9P2000'):
-		r = tx(mkfcall(Tversion, Tag, msize, vers))
-		if r.type != Rversion:
-			note('response to Tversion should always be Rversion')
-			return
-		if r.msize > msize:
-			note('response msize must be <= request msize')
-		if r.version != expectvers:
-			note('response version must be '+expectvers)
-
-	test(8192+IOHDRSZ, '9P2000')	# common case
-	test(512, '9P2000')	# small msize
-	test(8192+IOHDRSZ, '9P2005')	# future protocol
-	test(16384, '9P2000')	# large msize
-	test(8192+IOHDRSZ, '9P2000.1') # subprotocol
-	test(8192+IOHDRSZ, '9P2001.2') # future subprotocol
-	test(8192+IOHDRSZ, '8P2000', 'unknown')
-
-def main():
-	global fd, chatty
-	arg = ArgParser('usage: 9ptest [-c|-n] service\n')
-	con = conservice
-	for o in arg:
-		if o=='-c':
-			con = concommand
-		elif o=='-n':
-			con = connetwork
-		elif o=='-v':
-			chatty += 1
-		else:
-			arg.error('unknown option '+o)
-	if len(arg.argv) != 1:
-		arg.error()
-
-	fd = con(arg.argv[0])
-
-	testversion()
-
-
-if __name__=='__main__':
-	main()
//GO.SYSIN DD 9ptest
echo fcall.py
sed 's/.//' >fcall.py <<'//GO.SYSIN DD fcall.py'
-"""Pack and unpack 9P2000 messages."""
-
-from __future__ import nested_scopes, generators
-import sys, struct
-
-class FcallError(Exception):
-	def __init__(self, msg=None):
-		if msg:
-			self.msg = msg
-
-IOHDRSZ = 24
-
-Tversion, \
-Rversion, \
-Tauth, \
-Rauth, \
-Tattach, \
-Rattach, \
-Terror, \
-Rerror, \
-Tflush, \
-Rflush, \
-Twalk, \
-Rwalk, \
-Topen, \
-Ropen, \
-Tcreate, \
-Rcreate, \
-Tread, \
-Rread, \
-Twrite, \
-Rwrite, \
-Tclunk, \
-Rclunk, \
-Tremove, \
-Rremove, \
-Tstat, \
-Rstat, \
-Twstat, \
-Rwstat = range(100, 128)
-
-fcalls = {
-	Tversion: ('LS', ['msize', 'version']),
-	Rversion: ('LS', ['msize', 'version']),
-
-	Tauth: ('LSS', ['afid', 'uname', 'aname']),
-	Rauth: ('q', ['aqid']),
-
-	Rerror: ('S', ['ename']),
-
-	Tflush: ('H', ['oldtag']),
-	Rflush: ('', []),
-
-	Tattach: ('LLSS', ['fid', 'afid', 'uname', 'aname']),
-	Rattach: ('Q', ['qid']),
-
-	Twalk: ('FF#S', ['fid', 'newfid', 'wname']),
-	Rwalk: ('#Q', ['qid']),
-
-	Topen: ('LB', ['fid', 'mode']),
-	Ropen: ('qL', ['qid', 'iounit']),
-
-	Tcreate: ('LSLB', ['fid', 'name', 'perm', 'mode']),
-	Rcreate: ('qL', ['qid', 'iounit']),
-
-	Tread: ('LQL', ['fid', 'offset', 'count']),
-	Rread: ('D', ['data']),
-
-	Twrite: ('LQD', ['fid', 'offset', 'data']),
-	Rwrite: ('L', ['count']),
-
-	Tclunk: ('L', ['fid']),
-	Rclunk: ('', []),
-
-	Tremove: ('L', ['fid']),
-	Rremove: ('', []),
-
-	Tstat: ('L', ['fid']),
-	Rstat: ('D', ['stat']),
-
-	Twstat: ('LD', ['fid', 'stat']),
-	Rwstat: ('', [])
-}
-
-fcallnames = {
-	Tversion: 'Tversion',
-	Rversion: 'Rversion',
-
-	Tauth: 'Tauth',
-	Rauth: 'Rauth',
-
-	Rerror: 'Rerror',
-
-	Tflush: 'Tflush',
-	Rflush: 'Rflush',
-
-	Tattach: 'Tattach',
-	Rattach: 'Rattach',
-
-	Twalk: 'Twalk',
-	Rwalk: 'Rwalk',
-
-	Topen: 'Topen',
-	Ropen: 'Ropen',
-
-	Tcreate: 'Tcreate',
-	Rcreate: 'Rcreate',
-
-	Tread: 'Tread',
-	Rread: 'Rread',
-
-	Twrite: 'Twrite',
-	Rwrite: 'Rwrite',
-
-	Tclunk: 'Tclunk',
-	Rclunk: 'Rclunk',
-
-	Tremove: 'Tremove',
-	Rremove: 'Rremove',
-
-	Tstat: 'Tstat',
-	Rstat: 'Rstat',
-
-	Twstat: 'Twstat',
-	Rwstat: 'Rwstat',
-}
-
-def pack(fmt, vals):
-	pkt = ''
-	while fmt:
-		c = fmt[0]
-		fmt = fmt[1:]
-		v = vals[0]
-		vals = vals[1:]
-		if c in 'BHLQ':
-			pkt += struct.pack(c, v)
-		elif c == 'S':
-			pkt += pack('H', (len(v),))
-			pkt += v
-		elif c == 'q':
-			pkt += pack('VLB', v.path, v.vers, v.type)
-		elif c == 'D':
-			pkt += pack('L', (len(v),))
-			pkt += v
-		elif c == '#':
-			c = fmt[0]
-			fmt = fmt[1:]
-			pkt += pack(c*len(v), v)
-		else:
-			raise Exception('unknown format character \''+c+'\'')
-	return pkt
-
-def unpack(fmt, pkt):
-	l = []
-	while fmt:
-		c = fmt[0]
-		fmt = fmt[1:]
-		if c == 'B':
-			v, = struct.unpack('<B', pkt[:1])
-			pkt = pkt[1:]
-		elif c == 'H':
-			v, = struct.unpack('<H', pkt[:2])
-			pkt = pkt[2:]
-		elif c == 'L':
-			v, = struct.unpack('<L', pkt[:4])
-			pkt = pkt[4:]
-		elif c == 'Q':
-			v, = struct.unpack('<Q', pkt[:8])
-			pkt = pkt[8:]
-		elif c == 'S':
-			n, = struct.unpack('<H', pkt[:2])
-			v = pkt[2:2+n]
-			pkt = pkt[2+n:]
-		elif c == 'q':
-			q, pkt = unpack('VLB', pkt[:8+4+1])
-			v = plan9.Qid().fromtuple(q)
-		elif c == 'D':
-			n, = struct.unpack('<L', pkt[:4])
-			v = pkt[4:4+n]
-			pkt = pkt[4+n:]
-		elif c == '#':
-			n, = struct.unpack('<H', pkt[:2])
-			c = fmt[0]
-			fmt = fmt[1:]
-			v, pkt = unpack(c*n, pkt[2:])
-		else:
-			raise Exception('unknown format character \''+c+'\'')
-		l.append(v)
-	return l, pkt
-
-def mkfcall(*args):
-	f = Fcall()
-	f.loadtuple(*args)
-	return f
-
-class Fcall:
-	def __init__(self, type=None, args=None):
-		if type==None:
-			return
-		if not fcalls.has_key(type):
-			raise Exception('bad fcall type')
-		self.type = type
-		if args != None:
-			self.fromtuple(args)
-		return
-
-	def loadtuple(self, *args):
-		self.type = args[0]
-		self.tag = args[1]
-		names = fcalls[self.type][1]
-		off = 2
-		for n in names:
-			self.__dict__[n] = args[off]
-			off += 1
-		return self
-
-	def load(self, pkt):
-		(l, self.type, self.tag), npkt = unpack('LBH', pkt)
-		if l != len(pkt):
-			raise Exception('packet length field is a lie')
-		pkt = npkt
-		if not fcalls.has_key(self.type):
-			raise Exception('bad packet type %d' % (self.type,))
-		fmt, names = fcalls[self.type]
-		vals, pkt = unpack(fmt, pkt)
-		if pkt:
-			raise Exception('packet too large')
-		for n,v in zip(names, vals):
-			self.__dict__[n] = v
-		return self
-
-	def unload(self):
-		hdr = pack('BH', (self.type, self.tag))
-		fmt, names = fcalls[self.type]
-		dat = pack(fmt, map(lambda x: self.__dict__[x], names))
-		l = pack('L', (4+len(hdr)+len(dat),))
-		return l+hdr+dat
-
-	def __repr__(self):
-		try:
-			s = fcallnames[self.type]
-			for n in fcalls[self.type][1]:
-				s += ' '+str(self.__dict__[n])
-			return s
-		except Exception:
-			return '<malformed or uninitialized Fcall>'
-
//GO.SYSIN DD fcall.py
echo arg.py
sed 's/.//' >arg.py <<'//GO.SYSIN DD arg.py'
-from __future__ import generators
-import sys, copy
-
-"""Simple command-line argument iterator.
-
-A typical example looks like:
-
-	arg = ArgParser('usage: example [-d] [-r root] database\n')
-	for o in arg:
-		if o=='-d':
-			debug=1
-		elif o=='-r':
-			root = arg.nextarg()
-		else:
-			arg.error('unknown option '+o)
-	if len(arg.argv) != 1:
-		arg.error()
-
-This illustrates all the important points:
-
-	* arg is a generator that returns the next argument.
-	  >>>The behavior of the generator depends on the behavior
-	  of the body of your for loop.<<<  This is why you don't have
-	  to tell the ArgParser about your options a priori.  If an option
-	  has an argument, you call arg.nextarg() to fetch it.  (If you
-	  want an option to have two arguments, call arg.nextarg twice.)
-
-	 * After the loop has finished, arg.argv contains the
-	  remaining command-line arguments.
-
-	 * Calling arg.error prints the optional passed string,
-	  then prints the usage message, then exits.
-
-A few other points:
-
-	* Consistent with typical Unix conventions, option parsing ends
-	  after seeing '--', before seeing '-', or before any command-line argument
-	  not beginning with a - (that wasn't gobbled as an option argument).
-	  Assuming that -c does not take an argument but -f does, the following
-	  set of command lines and parsings illustrates the rules:
-		foo -c -- -a
-			opts: -c
-			args: -a
-		foo -c - -a
-			opts: -c
-			args: - -a
-		foo -c bar baz -a
-			opts: -c
-			args: bar baz -a
-		foo -cfbar baz -a
-			opts: -c -f
-				(-f took bar)
-			args: baz -a
-		foo -cf bar baz -a
-			opts: -c -f
-				(-f took bar)
-			args: baz -a
-		foo -fc bar baz -a
-			opts: -f
-				(-f took c)
-			args: bar baz -a
-
-	* Single character short options begin with - and take arguments from the
-	  rest of the current argument or from the next argument.  For example,
-	  	foo -cbar
-	  	foo -c bar
-	  are equivalent.  There is no support for optional arguments, since that
-	  introduces command-line parsing ambiguities.
-
-	* Long options begin with -- and take arguments from an optional
-	  ``=ARG'' suffix.  For example,
-	  	foo --long=bar
-	  is the only way to specify an argument to the --long option.
-	  If the handler for '--long' does not fetch the argument with arg.nextarg,
-	  the parser will call arg.error automatically.  There is support for optional
-	  arguments to long options, since that does not introduce any ambiguities.
-	  To fetch an optional argument call arg.nextarg(allownone=1).  If there
-	  is no argument, None will be returned.
-
-"""
-
-class ArgError(Exception):
-	def __init__(self, msg=None):
-		if msg:
-			self.msg = msg
-
-class ArgParser:
-	def __init__(self, usage, argv=sys.argv):
-		self.argv0 = argv[0]
-		self.argv = argv[1:]
-		self.usage = usage
-		self.waitingarg = ''
-
-	def __iter__(self):
-		# this assumes the "
-		while self.argv:
-			if self.argv[0]=='-' or self.argv[0][0]!='-':
-				break
-			a = self.argv.pop(0)
-			if a=='--':
-				break
-			if a[0:2]=='--':
-				i = a.find('=')
-				if i==-1:
-					self.waitingarg=None
-					self.option = a
-					yield self.option
-					self.option = None
-				else:
-					self.waitingarg = a[i+1:]
-					self.option = a[0:i]
-					yield self.option
-					if self.waitingarg:		# wasn't fetched using optarg
-						self.error(self.option+' does not take an argument')
-					self.option = None
-				continue
-			self.waitingarg = a[1:]
-			while self.waitingarg:
-				a = self.waitingarg[0:1]
-				self.waitingarg = self.waitingarg[1:]
-				self.option = '-'+a
-				yield self.option
-				self.option = None
-
-	def nextarg(self, allownone=0):
-		if self.waitingarg==None:
-			if allownone:
-				return None
-			self.error(self.option+' requires an argument')
-		elif self.waitingarg:
-			ret = self.waitingarg
-			self.waitingarg=''
-		else:
-			try:
-				ret = self.argv.pop(0)
-			except IndexError:
-				self.error(self.option+' requires an argument')
-		return ret
-
-	def error(self, msg=None):
-		if msg:
-			sys.stderr.write('argument error: '+msg+'\n')
-		sys.stderr.write(self.usage)
-		sys.stderr.flush()
-		sys.exit(1)
-
//GO.SYSIN DD arg.py

[9fans] Serving 9p in python - anyone started that?

[matt]

just wondering

8)