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, your mindset and what you're accustomed to. br, S -- [EMAIL PROTECTED] -- Today is the car of the cdr of your life. -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for lambda - 'def' as an expression?
Paul Rubin http://[EMAIL PROTECTED] 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 mean persistent name. You could write the above as: def generate_randomizer (n, m): def randomizer(x): return pow(x, n, m) return randomizer But if you could do anonymous blocks, you could just write something like: def generate_randomizer (n, m): return def (x): return pow (x, n, m) Personally, I don't mind naming local functions in practice (and Python syntax doesn't lend itself very well to anonymous blocks) but rather, the nuisance is that I feel there's just plain something wrong with it. It's less beautiful than it could be. Luckily, the last time I followed the discussion on this topic in c.l.p, some bright mind whose name escapes me now pointed out the craziness of _having to_ name functions by comparing it to the situation where you'd have to bind any literal objects to symbols before you could use them. Like: def return_fixed_number (): res = 42 return res or: arg1 = foo arg2 = 42 arg3 = baz () myfunction (arg1, arg2, arg3.xyzzy ()) Sure, you don't lose any expressiveness in that: if you had to name any object before using it, you could write all the same programs that you can in the current Python. But it's the expressiveness of your mind that gets harpooned: you'll have to keep part of your focus on these extraneous local variables instead of thinking only in terms of values where only values matter. -- [EMAIL PROTECTED] -- Today is the car of the cdr of your life. -- http://mail.python.org/mailman/listinfo/python-list
Python + Lisp integration - Part II
I'm posting a self-followup to my post in last December about Python and Lisp integration: URL:http://groups-beta.google.com/group/comp.lang.python/msg/ff6345845045fb47?hl=en Now, just yesterday I just stumbled upon Lython: URL:http://www.caddr.com/code/lython/ It's a bit edgy but it can be made to work :-). It does do simple macros and compiles to Python bytecode (via AST generation). So, effectively you could be writing your code in Lisp and then running it in the vast environment of Python standard library and modules. This was FYI, if interested. cheers, S -- [EMAIL PROTECTED] -- Today is the car of the cdr of your life. -- http://mail.python.org/mailman/listinfo/python-list
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 will run also on a simple ksh, could please confirm that? That depends on the unix flavor you're using -- my example was for GNU utilities which are heavily used on (probably all) Linux systems. BSDs, Solaris and other unixen have slightly different 'find' syntax. Use man find to find out more about how 'find' works on your system. On all systems I know, it goes like: find directory [-switches ...] where the switches vary depending on the system. In my example, I used -type f (f as in file) to only list files (otherwise 'find' will include directories too in the output) and -printf to include desired data -- in this case, owner, last modified time, size, path -- in the output (otherwise 'find' will only print the path). You should at least go through the -printf formatting codes to see what information you're able to include in the output (= man find). I used %T@ to print the last modified time in Unix time because it's as simple as it can be: an integer, counting the number of seconds since Jan 1 1970. Python's time module groks Unix time just like that. Moreover, I could run this script in a while loop, like: Except that, I'd imagine, constantly traversing the filesystem will seriously degrade the performance of the file server. You want to run your script periodically over a day, maybe at times when the server is inactive. Or hourly between 8am-4pm and then once at night. In Unix, there's a facility called cron to do just that, it runs scripts and commands over and over again hourly, daily, weekly, or just whenever you want it. Consult your unix flavor's manual or newsgroup on that. copy /yourserverroot/files.txt /yourserverroot/filesbackup.txt always have the filesbackup.txt up-to-date, as a function of the find speed on the server. Yes, creating a temporary file is a good approach. I'd suggest moving the new list over the old one (mv tmpfile filelist.txt) instead of copying, since usually move is merely a rename operation on the filesystem and doesn't involve actually copying of any data. br, S -- [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
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 unused/old files, this is a way for one of us to fast scan all the directories and identify which files belong to him. Having them in an organized, size-sorted wxPython list, the user can decide if he want to delete some files (that almost surely he forgot even that they exist...) or not. It is easy as a button click (retrieve the data--delete the files). Correct me if I'm wrong but since it _seems_ that the listing doesn't need to be up-to-date each minute/hour as the users will be looking primarily for old/unused files, why not have a daily cronjob on the Unix server to produce an appropriate file list on e.g. the root directory of your file server? Your Python client would then load that (possibly compressed) text file from the network share and find the needed bits in there. Note that if some old/unneeded files are missing today, they'll show right up the following day. For example, running the GNU find command like this: $ find . -type f -printf %T@ %u %s %p\n /yourserverroot/files.txt produces a file where each line contains the last modified time, username, size and path for one file. Dead easy to parse with Python, and you'll only have to set up the cronjob _once_ on the Unix server. (If the file becomes too big, grep can be additionally used to split the file e.g. per each user.) br, S -- [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
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, for a moment I wondered if dict.keys() was already of type set in 2.4, because it could have made sense. Which sets you need depends on each case, so a generic set-ified extension would be both limited and potentially confusing. For example, a set of (key,value) tuples is the simplest and unambiguous. On the other hand, if the values differ you really just need a set of keys and then you can do the value lookup and collision handling yourself using the result set as keys to both of your dictionaries. You could subclass dict to provide aliases such as: dict.itemset () dict.keyset () dict.valueset () for the following if these look overly bloated to you: set (dict.iteritems ()) set (dict.iterkeys ()) set (dict.itervalues ()) For example: py for k,v in set (d1.iteritems ()) - set (d2.iteritems ()): py print k, v looks quite concise and self-explanatory to me already. A _notable_ performance gain would probably justify native set-ifying getters, especially if there indeed were implementation-level data structures to share. br, S -- http://mail.python.org/mailman/listinfo/python-list
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 capture/redirect debugging information in existing code that has unwisely just printed error and warning messages, instead of using sys.stderr or error logging modules. py def with_output_to_string (func): ... try: ... sys.stdout = StringIO.StringIO () ... func () ... return sys.stdout.getvalue () ... finally: ... sys.stdout = sys.__stdout__ ... py def printing_code (): ... print Foobar ... py with_output_to_string (printing_code) 'Foobar\n' py br, S -- http://mail.python.org/mailman/listinfo/python-list
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'T use sys.__stdout__. Ever. It probably does the right thing, if someone is copypasting code off the Usenet and tries it out at the Python prompt (and possibly gets stuck in getting nothing printed on his tty). If we're talking about real code it might be advisable to start by first introducing the import statements omitted from the above snippet, then worry about someone copypasting code into a serious program instead of copythinkpasting it. :) br, S -- http://mail.python.org/mailman/listinfo/python-list
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 other things make this difficult for a parser to
handle correctly. Other people have already come up with working
It is difficult since in Python we don't enjoy the ugly luxury of
stuffing statements inside {}s. But as Bengt pointed out, parentheses
don't actually look bad at all in this case.
Then the multi-line way. I had to add an overload of map to support
reversing the order of parameters (list first, then the closure):
newlist = map([1,2,3,4,5,6]) def (x as int):
return x*x*x
That doesn't seem to scale if you want to pass more than one anonymous
function arguments to the function or call an arbitrary function with
parameters in arbitrary order.
br,
S
--
http://mail.python.org/mailman/listinfo/python-list
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 outside the local scope. This limitation most often kicks in in closed-over code in function objects, although it's a more general issue in Python's scoping. As we know, you can't write to variables that are both non-local and non-global (globals you can declare global). Now that effectively makes free variables read-only (although, the objects they point to can _still_ be mutated). Allowing write access to variables in a closed-over lexical scope outside the innermost scope wouldn't hurt because: 1) if you need it, you can already do it -- just practice some cumbersome tricks make suitable arrangements (e.g. the classical accumulator example uses an array to hold the counter value instead of binding it directly to the free variable; 2) if you don't need or understand it, you don't have to use it; 3) and at least in function instances: if you accidentally do, it'll change the bindings within your closure only which is definitely less dangerous than mutating objects that are bound inside the closure. It must be noted, however, that such behaviour would change the way of hiding nested variable names: Now it's safe (though maybe lexically confusing) to use the same variable names in inner functions. This could happen with common names for temporary variables like i, x, y. On the other hand, one could introduce a way to declare variables from global scope or from local scope, with default from lexical scope. (If you want to explicitly hide an outer binding, you'd declare local foo, for example. You can already do global foo.) I see what you are saying (I think), but I think I'd still like a full anonymous def, whatever adapter you come up with. And I prefer to be persuaded ;-) I elaborated on this one in a post a few days ago. Indeed, it is mostly a minor issue that _can_ be worked around(1). The problem is that it eventually becomes irritating, when repeated all the time, to name functions even if the name isn't used elsewhere. It also creates an implicit dependency from the function call (one of whose arguments points to the once-named function) to the once-named function. That is, when you refactor some of your code, you must keep two things paired all the time in your cut+paste maneuvers. br, S (1) Everything can be worked around. In contrast: you can work around the lack of a syntactic language by typing in machine code manually. Sound stupid? Yes, it was done decades ago. How about using C to write a shell script equivalent that you need, as a workaround to the problem of lacking a shell? Stupid? Yes, but less -- it's been done. How about writing callbacks by passing in a function pointer and a data pointer, if you don't want to use a language like Python that automates that task for you? Stupid? Yes, but not much -- it's been done all the time. How about implementing an _anonymous_ function by naming it, if you can't do it otherwise? -- http://mail.python.org/mailman/listinfo/python-list
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 unaesthetic hundred-line Python functions, if you want to. Python's syntax doesn't yet impose a restriction on the number of sequential statements :-) It sounds artificial to impose such restrictions on these hypothetical inline blocks, even if by only allowing them to be plain expressions. IMHO, the most pythonic way to write an inline-block is by reusing existing keywords, using Python-like start-of-blocks and ending it by indentation rules: map (def x: if foo (x): return baz_1 (x) elif bar (x): return baz_2 (x) else: global hab hab.append (x) return baz_3 (hab), [1,2,3,4,5,6]) and for one-liners: map (def x: return x**2, [1,2,3,4,5,6]) As a side-effect, we also - got rid of the lambda keyword; - strenghtened the semantics of def: a def already defines a function so it's only logical to use it to define anonymous functions, too; - unified the semantics: function is always a function, and functions return values by using return. When learning Python, I learned the hard way that lambdas are expressions, not functions. I'd pay the burden of writing return more often in exchange for better consistency. my two cents, br, S -- http://mail.python.org/mailman/listinfo/python-list
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: global hab hab.append (x) return baz_3 (hab), [1,2,3,4,5,6]) I think this would probably have to be written as: ... return baz_3(hab) , [1,2,3,4,5,6]) or: ... return baz_3(hab) , [1,2,3,4,5,6]) Note the placement of the comma. As it is, return baz_3(hab), returns the tuple containing the result of calling baz_3(hab): That one didn't occur to me; creating a one-item tuple with (foo,) has been odd enough for me: only few times I've seen also the parentheses omitted. I did ponder the unambiguousness of the last line, though. One could suggest a new keyword like end, but keyword bloat is bad. (Of course, if we trade the lambda keyword for another, new keyword we're not exactly _adding_ keywords... :)) It's not horrible to have to put the comma on the next line, but it isn't as pretty as your version that doesn't. Unfortunately, I don't think anyone's gonna want to revise the return statement syntax just to introduce anonymous functions. There might not be a return statement: the anonymous function might conditionally return earlier and have side-effects at the end of the block (to implicitly return None). So the block-ending would need to fit after any statement and be strictly unambiguous. br, S -- http://mail.python.org/mailman/listinfo/python-list
Re: Python + Lisp integration?
Erno Kuusela [EMAIL PROTECTED] writes: you might want to look at http://logix.livelogix.com/ . 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 something to hack on. br, S -- http://mail.python.org/mailman/listinfo/python-list
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 Python programming (and/or conversely: have access to the wealth of Python libraries and Python code from a lispy language), which yields at least the following requirements: - the type and runtime environment system would need to be quite transparently integrated, e.g. being able to use (pass, call, set/get attr) Python objects in Lisp and vice versa with minimum hassle - the performance should match at least that of Python's. That probably requires a native interpreter, although the ability to compile Lisp to Python bytecode could do (if the lispy language could be efficiently implemented in the Python bytecode) There are many Scheme/Lisp interpreters written in Python, but those I've found and looked at I consider to be more of proof of concepts. Nesting different interpreters costs probably an order of magnitude in speed. -- http://mail.python.org/mailman/listinfo/python-list
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 hide it from your own mind (e.g. naming it _my_local_func or something as ugly as the leading underscores in it). use something short, like f. hopefully, a single character won't overload your brain. I've heard some brain can tackle even Java's overly verbose syntax, it just depends on one's mind set how the verbosity is perceived: some find it a disrupting must, some like spending time writing things for which another programmer would've written a code generator by now. Elaborating more: Yes, naming functions that are only used once is minor nuisance (but still something I hope to get rid of eventually). In a level, it's probably similar to how whitespace at the end of the lines bogs some people -- that stuff just doesn't need to be there, so the text feels cluttered. (For _that_, Emacs luckily has its whitespace mode.. :)) *** Like someone pointed, using _ is a good convention for throwaways. The fact that such a convention exist just emphasizes that it _is_ an issue from which people try to sway away. And I think that it does, in fact, touch the innermost symbol table yes, but the overhead of keeping a local slot updated is very small, Sure; though I considered it more of a conceptual issue rather than a performance one. br, S -- http://mail.python.org/mailman/listinfo/python-list
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 name, you have name polluting your namespace. The whole program becomes harder to understand because you can't ignore name anywhere, even if it was only ever intended to be used in one place. Ahem. If you name the function, you can reuse the name (or just forget about it) as soon as you've used the function object. 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 hide it from your own mind (e.g. naming it _my_local_func or something as ugly as the leading underscores in it). And I think that it does, in fact, touch the innermost symbol table too, even if the case is optimized out by the compiler -- is it? Why do something for the sake of not actually having to do it? *** Anyway, personally, this namespace cluttering most often happens because lambda is only a single expression. If one could write a true function block into a lambda, there would be less cases where lambda doesn't suffice, really. Now, if lambda was more than an expr, dumping lambda keyword would be a convenient idea -- unnecessary keywords can make the language less clear in some cases. One could do with Python's plain and simple def, like this: filter (def (x): x*2, myseq) (Disclaimer: Without thinking further I'm not sure whether the above syntax would be unique enough, Python grammar-wise.) br, S -- http://mail.python.org/mailman/listinfo/python-list
