Re: Any advantage in LISPs having simpler grammars than Python?

Grant Edwards <[EMAIL PROTECTED]> writes: > Yes. Grammars like LISP's make it easy for programs to > generate and read code. Grammars like Python's make it easy for > humans to generate and read code. The above statement sounds too generalized to me. IMHO it's more of a matter of preference, you

Re: Replacement for lambda - 'def' as an expression?

Paul Rubin writes: > Sybren Stuvel <[EMAIL PROTECTED]> writes: > > An example: > > > > def generate_randomizer(n, m): > > randomizer = def(x): > > return x ** n % m > > > > return randomizer > > You're a little bit confused; "name" doesn't necessarily

Python + Lisp integration - Part II

I'm posting a self-followup to my post in last December about Python and Lisp integration: http://groups-beta.google.com/group/comp.lang.python/msg/ff6345845045fb47?hl=en> Now, just yesterday I just stumbled upon Lython: http://www.caddr.com/code/lython/> It's a bit edgy but it can be made to

Re: How To Do It Faster?!?

[EMAIL PROTECTED] writes: > >$ find . -type f -printf "%T@ %u %s %p\n" > /yourserverroot/files.txt > That is a nice idea. I don't know very much about Unix, but I suppose that > on a ksh I can run this command (or a similar one) in order to obtain the > list I need. If anyone knows if that command

Re: How To Do It Faster?!?

[EMAIL PROTECTED] writes: > Every user of thsi big directory works on big studies regarding oil > fields. Knowing the amount of data (and number of files) we have to > deal with (produced by simulators, visualization tools, and so on) > and knowing that users are usually lazy in doing clean up of

Re: Python's idiom for function overloads

Philippe Fremy <[EMAIL PROTECTED]> writes: > You can not reproduce the C++ overload idiom but you can get something > close with manual type testing. > > > To in a > > function do an if statement with the type() function? > > I am not aware of any other method. > > def a( arg1 ): > if t

Re: set, dict and other structures

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > Just today I was writing some code where I wanted to use sets for > the abstraction (intersection, etc.), but also carry some values > with them to process. So, yes, I believe that having set-like > abstraction for dictionaries would be great. In fact,

Re: python and macros (again) [Was: python3: 'where' keyword]

[EMAIL PROTECTED] writes: > This is a bizarre idea if you want to make Python run faster. It is > not so bizarre if what you want is to have access to Python from > Lisp/Scheme in the same sense Jython has access to Java. And it sounds very nice if you prefer writing Lisp code (or resort to it if

Re: Writing huge Sets() to disk

"John Lenton" <[EMAIL PROTECTED]> writes: > you probably want to look into building set-like objects ontop of > tries, given the homogeneity of your language. You should see > imrpovements both in size and speed. Ternary search trees give _much_ better space-efficiency compared to tries, at the e

Re: Rebinding stdout (was: Re: Python! Is! Truly! Amazing!)

Just <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]>, > Simo Melenius <[EMAIL PROTECTED]> wrote: > > ... sys.stdout = sys.__stdout__ > Aargh, I can't believe how widespread this idiom is :-(. See my other > reply in this thread: DON

Re: Rebinding stdout (was: Re: Python! Is! Truly! Amazing!)

Ron Garret <[EMAIL PROTECTED]> writes: > (with-output-to-string (s) > (let ( (*standard-output* s) ) > (call-html-generating-code) > s)) > > Is there an equivalent Python trick to capture a function call's output > as a string? I've sometimes replaced sys.stdout (and/or sys.stderr) to

Re: Securing a future for anonymous functions in Python

Doug Holton <[EMAIL PROTECTED]> writes: > Steven Bethard wrote: > > Simo Melenius wrote: > >> map (def x: Oops, I found a typo alreay. I meant to write "def (x):" -- no name for anonymous functions but just the argument list, please :) > Right the comma plus

Re: Securing a future for anonymous functions in Python

[EMAIL PROTECTED] (Bengt Richter) writes: > ISTM you don't need "end" -- just put the def expression in parens, > and let the closing paren end it, e.g.: I first rejected any parens as not being native to how classes/toplevel functions/control blocks are written in Python. However, this looks qui

Re: Securing a future for anonymous functions in Python

Steven Bethard <[EMAIL PROTECTED]> writes: > Simo Melenius wrote: > > map (def x: > > if foo (x): > > return baz_1 (x) > > elif bar (x): > > return baz_2 (x) > > else: > >

Re: Securing a future for anonymous functions in Python

Ian Bicking <[EMAIL PROTECTED]> writes: > But I do think there's other ways to approach this. Function > expressions could get really out of hand, IMHO, and could easily lead > to twenty-line "expressions". That's aesthetically incompatible with > Python source, IMHO. You can already write unae

Of closures and expressing anonymous functions [Was: Re: Securing a future for anonymous functions in Python]

[EMAIL PROTECTED] (Bengt Richter) writes: > Closure is the name for the whole thing, apparently, not just the > environment the procedure body needs, which was the aspect that I > (mis)attached the name to. Which brings me to the point where I'd welcome more flexibility in writing to variables ou

Re: Python + Lisp integration?

Erno Kuusela <[EMAIL PROTECTED]> writes: > you might want to look at . Thanks, this was a good link! Logix looks like an interesting project, really, and I think I'll at least study its internals myself to shed light to how it uses the Python compiler. Looks like som

Re: Python + Lisp integration?

Arthur <[EMAIL PROTECTED]> writes: > but Lush - Lisp Universal Shell - is mature and has bindings to the > Python C API. Lush looks like a very interesting project on its own, too, and seems to have a load of bindings to other libraries too÷÷. (Even better if it was to support Python 2.3/2.4 once

Python + Lisp integration?

Hi, I'm wondering (after a bit of googling) whether there exists a Python binding to any open source Lisp environment (like librep or some Scheme or Common Lisp implementation) that could be recommended for non-toy use? My intention would be to use the Lisp environment to augment and help my Pyt

Re: Is this a good use for lambda

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Simo Melenius wrote: > > Sure, but mental pollution counts too IMO. What you write and what you > > read must go through your brain, including dummy variables. And next > > you start thinking how to "h

Re: Is this a good use for lambda

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Walter S. Leipold wrote: > > I think that Charlie's point is that, when you use "def ", > > you have polluting your namespace. The whole program > > becomes harder to understand because you can't ignore > > anywhere, even if it was only ever intended