Kay Schluehr <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > > Kay Schluehr <[EMAIL PROTECTED]> wrote: > >> The arrow is a straightforward punctuation for function definitions. > >> Reusing existing keywords for different semantics seems to me as a kind > >> of inbreeding. > > > > That's starting to look like the pseudocode from old algorithms > > textbooks, which is very similar to bad pseudocode from modern CS theory > > papers. Punctuation as a replacement for words does not always win > > (perfect examples being 'and' vs. &&, 'or' vs. ||, 'not' vs. !, ...) > > Writing functions as arrows is very convenient not only in CS but also > in mathematics. Looking like pseudo-code was not one of Guidos Python > regrets if I remember them correctly.
Apparently you weren't reading what I typed. I don't find '->' notation for functions to be readable, either in code, papers, or otherwise. In fact, when I teach my CS courses, I use Python, and in the case where I need to describe mathematical functions, I use a standard mathematical notation for doing so: 'f(x) = ...'. > >> For pushing anymus functions forward I propose to enable explizit > >> partial evaluation as a programming technique: > > > > If I remember correctly, we've got rightcurry and leftcurry for that (or > > rightpartial and leftpartial, or something). > > > Currying usually does not perform a function evaluation in order to > create another more special function. Partial evaluation is a dynamic > programming and optimization technique. Psyco uses specialization and > caching implicitely. I propose to use it explicitely but in a more > restricted context. I never claimed that currying was partial function evaluation. In fact, if I remember correctly (I don't use curried functions), the particular currying that was implemented and shipped for Python 2.4 was a simple function that kept a list of args and kwargs that were already passed to the curried function. When it got enough arguments, it would go ahead and evaluate it. > > I'll assume that you don't actually want it to rewrite the source, or > > actually return the source representation of the anonymous function > > (those are almost non-starters). > > > > Computer algebra systems store expressions in internal tree form, > manipulate them efficiently and pretty-print them in textual or latex > output on demand. There would be much more involved than a tree to tree > translation starting with Pythons internal parse tree and an evaluator > dedicated to it. Right, and Python is not a CAS. You want a CAS? Use Mathematica, Maple, or some CAS addon to Python. Keeping the parse tree around when it is not needed is a waste. In the code that I write, that would be 100% of the time. > > As for all anonymous functions allowing partial evaluation via keywords: > > it would hide errors. Right now, if you forget an argument or add too > > many arguments, you get a TypeError. Your proposal would make > > forgetting an argument in certain ways return a partially evaluated > > function. > > > That's why I like to dump the function in a transparent mode. Personally > I could dispense a little security in favor for cheap metainformation. It's not about security, it's about practicality and backwards compatibility. Here is an example: >>> x = lambda a,b: a+b+1 >>> x(a=1) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: <lambda>() takes exactly 2 non-keyword arguments (1 given) >>> According to you, that should instead produce... lambda b: 1+b+1 New and old users alike have gotten used to the fact that calling a function without complete arguments is an error. You are proposing to make calling a function with less than the required number of arguments not be an error. For the sake of sanity, I have to be -1000 on this. I'm also not aware of an automatic mechanism for code compilation (in Python) that both attaches the parse tree to the compiled function, or allows for the conversion of that parse tree back to a source form, or allows one to replace variable references with constants. If you would care to write the pieces necessary, I'm sure you will find a use for it. - Josiah _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
