Flatterer!
> 1) I'm addicted to the C syntax of ?:, as in
>
> foo ((a < b) ? c : d);
>
> Is there some equivalent in python?
Not directly. (I guess when designing Python I was copying parts of
the design goals of ABC, which wanted to get rid of C's 13 levels of
operator priorities...) Sometimes you can get away with "a and b"
which returns either the value of a or the value of b, not 0 or 1 as
in C -- Python's "a and b" is like "a ? a : b" except a is evaluated
only once. Given that Python uses keywords 'and' and 'or', the '?:'
construct would probably have to be written with keywords as well --
can't think of any obvious ones though. (Functional notation is out
since built-in functions always evaluate all their arguments.) But I
must say that I've never missed it and in fact you're the first one
who asks for it...
> 2) It would often be useful if there was some way to create function
> objects without binding them to some name. You can do it with
> something like
>
> def makefuncobj ():
> def tmp (x, y, z):
> return (x + y * z)
> return(tmp)
>
> a = makefuncobj()
>
> but you need to define a new makefuncobj for every function you
> wish to dynamically create, which takes some of the dynamism
> out of it :-). I'd like to be able to have some expression whihc
> evaluates to a function object without binding any names, perhaps
> something like
>
> a = def *(x, y, z):
> return x + y * z;
>
> You could almost do it with exec(), I'd think, except that exec()
> doesn't return its value. Are multi-line expressions even allowed?
Multi-line expressions like this would require a major redesign of the
expression syntax. I guess you're stuck with what you've got.
However, I don't see the reason why you don't want to bind any names.
I would personally write your first example like this:
def tmp(x, y, z):
return x + y * z
a = tmp
Note that if you execute this code many times (say in a loop) the
'def' statement will create a new function object each time. (In fact
the semantics of a 'def' statement are assignment to the defined
function name.)
But maybe you can give an example where this isn't sufficient?
> 3) Are exceptions implemented in such a way as to be thread-safe?
> You speak in the EXTENDING document of a global variable that is
> bound...
I don't think they currently are. This is one of the areas that needs
fixing up when more machines get usable thread implementations
(currently the SGI is the only one where this really works). It
shouldn't be too hard to fix though since most of the interface
already uses function, the global variables are static.
> 4) I'd like to extend python to speak ILU, the distributed interface
> system we're developing here. My thought is to add the ILU parser
> and runtime kernel to the interpreter core, and then use it thusly:
>
> A new call, ilu.load(<interface-file-name>), will use the ILU parser
> to read and parse the file describing one or more interfaces; the
> parse tree will then be interpreted in C. In C, a new module will be
> defined for every interface defined in the file; a new object type
> will be defined for every object type defined in every interface; a
> new method object will be generated for every method of every new
> object type; every method will look something like
>
> def m(self, *args)
> return(ilu.call (self, <x>, args))
>
> where <x> is a description of method m's signature. Note that there
> will be no corresponding method in C for these newly defined methods.
>
> OK, so defining new modules at the C level isn't hard. Event objects
> aren't bad. But I don't see how to define new methods or function
> objects without real C functions to bind them to.
This sounds remarkably similar to what the 'amoeba' module does, for
RPC in the (now almost forgotten?) distributed operating system by
that name (most of the code is in files whose name starts with 'sc'
though). There the parsing is done outside python and loading an
interface will read the result of the parsing from a file, but that's
not an essential difference. All methods are bound to the same C
function, the "universal RPC marshalling method", which also gets a
pointer to the result of the parsing. The latter is actually a tiny
program for a virtual machine that does the (un)marshalling of
arguments and results. Since the structure of the C code generated by
RPC generators for marshalling functions is usually pretty regular, it
doesn't require too much work to write such a "generic marshaller",
especially since the arguments are available as a Python tuple and not
in some machine-dependent format on the C stack.
> 5) It's too bad that development on STDWIN is discontinued. We use
> both Macs and UNIX here, and having a portable UI interface is very
> nice. Not to mention that python with Motif is 3 MB, without Motif
> it's 1 MB.
Well, I'm looking for sponsors or other outside help... If someone
would do a MS Windows port, STDWIN might become more popular, and then
I might be convinced that it's worthwile to do some more development;
STDWIN especially needs a better way to handle dialogs with buttons
and text fields etc. Any volunteers? (Personally, I find hacking
Python much more fun than hacking STDWIN :-)
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>