Re: merits of Lisp vs Python
[EMAIL PROTECTED] schrieb: > I find it amusing that most of the arguments that python-people are > making in this thread are actually the arguments that C++ and Java make > against Python. "Who needs dynamic typing?", "Who needs closures?", > "The idea of using whitespace for syntax is beyond stupid"... Now the > python guys obviouly see that that those arguments are bogus, but they > keep the same reasoning against lisp. Yes, this structure of argument is the same in *any* discussion about language design and feature integration. The solution could be laissez faire but then you have to counteract creating standards for a minimal contract social. In either way you cut down language feature diversity and feature implementation redundancy, something macros strongly encourage. So Lisp is always the right language to start with but what is the right language to end with? The answer is BASIC and although the reference to the historical BASIC language is not accidental, I actually mean all kind of general purpose languages that aim to facilitate programming in the first place. That's why Python = BASIC or more accurately Python = ABC. Of course you can start with BASIC too, instead of Lisp, or Ruby and quote Yukihiro Matsumoto who just wants happy users - from the very beginning and not just after one month, when one starts looking through the jungle of parens ( Ken Tilton ) or perform any other cognitive transformation to ease the pain. While Pythonistas might defend their language with all kind of typical nerdish idiocy, Lispers try to convince Pythonistas to be unhappy, because they lack X, Y and Z and recommend Lisp as the cure. But just like a beautifull woman, Pythonistas stay unimpressed and do respond: no, I don't lack anything, I am complete; stay away from me with your weirdness! -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] wrote: > > Python has to rely more on using the right algorithm... > > This sound familiar: "Macros are dangerous!" Yes. I changed my opinion on advocating Python having macros in one of our long threads on the subject. Maintainance counts. > "Compilers make you lazy." This is new to me. In fact, for the compiled languages available to me. Using them *first* would be the difficult choice. > "Worse is better!" Yep, I think I read that one. To (over), summarise what I read: the author states that waiting for perfect will often give the advantage to a competitor who ships with 'good enough'. The author gives examples. The skill to me resides in knowing what is good enough ;-) > (I have a Russian friend -- a mathematician -- who > jokes that the reason the Soviets were great mathematicians because > their computers sucked, so they had to use extensive formal > manipulation to get things to run fast enough to get anything done. He > was joking (I think); you don't appear to be.) I can't vouch for your Russian friend, but yes I do think that the gumph on exponential time algorithms versus linear time algorithms makes sense. I started using my first scripting language AWK whilst using C and went through only using it for small tasks to using it for more and more because it was fast enough. In my case I'd be finishing some task in a much shoter time giving my customers solutions that might take 10 minutes to run instead of ten seconds, but they were using it in a flow that took maybe overnight to run. Unlike Lisp, Python does not have a ubiquitous compiler. It is therefore made to interface nicely with compiled languages. Other compiled language users see the need for dynamic interpreted languages like Python and maintain links Python such as the Boost Python C++ wrapper. IronPython for .NET, Jython for Java. Lisp is its own interpreter and compiler, which should be a great advantage, but only if you don't make the mistake of ignoring the wealth of code out there that is written in other languages. > > > Talk to these guys: > > http://en.wikipedia.org/wiki/PyPy they have an interesting take on > > No, actually maybe you should talk to them since you seem to think that > making Python run fast is dangerous, or at least unnecessary. > > > Python has this unsung module called doctest that neatly shows some of > > the strengths of python: http://en.wikipedia.org/wiki/Doctest > > Now I'm *certain* that you're just pulling my leg: You guys document > all your random ten-line hacks in Wikipedia?!?! What a brilliant idea! Python is newbie-friendly. Part of that is being accessible. Doctest is about a novel way of using a feature shared by Lisp, that is docstrings. Testing is important, usually not done enough, and doctests are a way to get people to write more tests by making it easier. Does Lisp have similar? > Hey, you even have dead vaporware projects like uuu documented in > Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in > Python, but it'd be about ten lines of Lisp, if that, so I'm just > guessing here.) Does Lisp have a doctest-like module as part of its standard distribution? Or are you saying that If you ever needed it, then it would be trivial to implement in Lisp, and you would 'roll your own'? There are advantages to doctest being one of Pythons standard modules. - Paddy. -- http://mail.python.org/mailman/listinfo/python-list
alternate language
what is a good alternate language to learn? i just want something to expand my mind and hopefully reduce or delay any chance of alzheimer's. i would especially like to hear from those of you who learned python _before_ these languages. haskell, erlang, ocaml, mozart/oz, rebel, etc. i don't require any of these features, but extra browny points for any of the following: interactive interpreter batteries included can integrate with c compiles to native code can use a gui toolkit such as wx doesn't take 60 hour weeks over years to master thanks, bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: > "Kaz Kylheku" <[EMAIL PROTECTED]> writes: > > > Lisp just seems hopelessly old-fashioned to me these days. A > > > modernized version would be cool, but I think the more serious > > > Lisp-like language designers have moved on to newer ideas. > > > > What are some of their names, and what ideas are they working on? > > http://caml.inria.fr > http://www.haskell.org Right. What these have in common with Lisp is that they use manifest typing, whereas Lisp uses latent typing. But after that, they mostly diverge. -- http://mail.python.org/mailman/listinfo/python-list
Re: Automatic debugging of copy by reference errors?
Niels L Ellegaard wrote:
> Marc 'BlackJack' Rintsch wrote:
> > In <[EMAIL PROTECTED]>, Niels L
> > Ellegaard wrote:
> > > I have been using scipy for some time now, but in the beginning I made
> > > a few mistakes with copying by reference.
> > But "copying by reference" is the way Python works. Python never copies
> > objects unless you explicitly ask for it. So what you want is a warning
> > for *every* assignment.
>
> Maybe I am on the wrong track here, but just to clarify myself:
>
> I wanted a each object to know whether or not it was being referred to
> by a living object, and I wanted to warn the user whenever he tried to
> change an object that was being refered to by a living object.
This really wouldn't work, trust us. Objects do not know who
references them, and are not notified when bound to a symbol or added
to a container. However, I do think you're right about one thing: it
would be nice to have a tool that can catch errors of this sort, even
if it's imperfect (as it must be).
ISTM the big catch for Fortran programmers is when a mutable container
is referenced from multiple places; thus a change via one reference
will confusingly show up via the other one. (This, of course, is
something that happens all the time in Python, but it's not something
people writing glue for numerical code need to do a lot.) Instead of
the interpreter doing it automatically, it might be better (read:
possible) to use an explicit check. Here is a simple, untested
example:
class DuplicateReference(Exception):
pass
def _visit_container(var,cset):
if id(var) in cset:
raise DuplicateReference("container referenced twice")
cset.add(id(var))
def assert_no_duplicate_container_refs(datalist,cset=None):
if cset is None:
cset = set()
for var in data:
if isinstance(var,(list,set)):
_visit_container(var,cset)
assert_no_duplicate_container_refs(var,cset)
elif isinstance(var,dict):
_visit_container(var,cset)
assert_no_duplicate_container_refs(var.itervalues(),cset)
Then, at important points along the way, call this function with data
you provide yourself. For example, we might modify your example as
follows:
import os
output=[]
firstlines =[0,0]
for filename in os.listdir('.'):
try:
firstlines[0] = open(filename,"r").readlines()[0]
firstlines[1] = open(filename,"r").readlines()[1]
output.append((filename,firstlines))
except (IOError, IndexError):
# please don't use bare except unless reraising exception
continue
assert_no_duplicate_container_refs([output,firstlines])
print output
We passed the function output and firstlines because those are the two
names you defined yourself. It'll check to see if any containers are
referenced more than once. And it turns out there are--firstlines is
referenced many times. It'll raise DuplicateReference on you.
There's plenty of room for improvement in the recipe, for sure. It'll
catch real basic stuff, but it doesn't account for all containers, and
doesn't show you the loci of the duplicate references.
Now, to be honest, the biggest benefit of this check is it gives
newbies a chance to learn about references some way other than the hard
way. It's not meant to catch a common mistake, so much as a
potentially very confusing one. (It's really not a common mistake for
programmers who are aware of references.) Once the lesson is learned,
this check should be put aside, as it unnecessarily restricts
legitimate use of referencing.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Question - Checkboxes
Leanne wrote: > I have been using Python for only a few months part-time and have > recently had my first encounter with retrieving user input from > checkboxes. I have a problem with the way Python reads the input > values from a set of checkboxes on a webpage. > > The values assigned to the checkboxes are integers. I first of all > check for a key of CHK_CHILDREN to see if any checkboxes have been > checked. That works fine. > > I then use a 'for x in CHK_CHILDREN' loop to get all the values from > the returned list. This works for most cases except one. If the user > only checks 1 checkbox, Python reads a scalar, not a list, and if this > scalar is a double digit integer (eg 11), then the loop goes through > each digit and retrieves these values, eg retrieves 1 and then > retrieves 1 again. > You evidently mean that the scalar you are getting is e.g. "11" and your loop is returning "1" then "1" again. So there are two possibilities: a string (either str or unicode) or a list (or some other sequence). I'd try this: if isinstance(returned_value, basestring): returned_value = [returned_value] for item in returned_value: do_something_with(item) HTH, John -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
[EMAIL PROTECTED] wrote: > Well, having read a lot of this thread, I can see one of the > reasons why the software profession might want to avoid > lispies. With advocacy like this, who needs detractors? And thus your plan for breaking into the software profession is ... to develop Usenet advocacy skills. ``That guy we just interviewed, I don't know. Perfect score on the C++ test, lots of good architectural knowledge, but he seems to care more about being correct than convincing people. He'd be fine for now, but what does that say about his ability when the crunch comes, and he's called upon to ... advocate?'' -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
"Alex Mizrahi" <[EMAIL PROTECTED]> writes: > PR> I don't see how to implement coroutines with CL macros. Maybe I'm > PR> missing something. > > read the book. Which book? > but once you convert it to CPS, you just operate with closures. stack is > just a lexical variables caught into closure. > do you know what does CPS mean at all?? I once understood the basic notion but confess to have never been clear on the fine points. However, I don't see how you can do it with CL closures since CL semantics do not guarantee tail recursion optimization. If you code a loop with closures and CPS, you will blow the stack. -- http://mail.python.org/mailman/listinfo/python-list
Re: Automatic debugging of copy by reference errors?
Russ wrote: > If a debugger could tell you how many references exist to an object, > that would be helpful. import sys sys.getrefcount(a) But I doubt it would be very helpful. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Steven D'Aprano wrote: > I'd love to say it has been fun, but it has been more frustrating than > enjoyable. I don't mind an honest disagreement between people who Honest disagreement requires parties who are reasonably informed, and who are willing not to form opinions about things that they have no experience with. > So now I have an even better understanding for why Lispers have a reputation > for being difficult and > arrogant. Whereas, for instance, lecturing a Lisp newsgroup (of all places) in the following manner isn't arrogant, right? ``Turing Complete. Don't you Lisp developers know anything about computer science? '' If that had been intended to be funny, you should have made that more clear by choosing, say, lambda calculus as the subject. > But I also gained a little more insight into why Lispers love their > language. I've learnt that well-written Lisp code isn't as hard to read as > I remembered, so I'd just like to withdraw a comment I made early in the > piece. You /think/ you learned that, but in reality you only read some /opinions/ that Lisp isn't as hard to read as was maintained by your previously held opinions. Second-hand opinions are only little better than spontaneous opinions. It's, at best, a slightly favorable trade. > I no longer believe that Lisp is especially strange compared to natural > languages. Natural languages are far less completely understood than any programming language. Only your own, and perhaps some others in nearby branches of the language tree do not appear strange to you. -- http://mail.python.org/mailman/listinfo/python-list
Quake 3 and the Python interpreter
So I've recently had a stroke of insanity, deciding that what the open-source Quake III engine *really* needs is a good, healthy dose of Python. Here's the quick version: The Q3 engine is split into the engine (responsible for rendering, sound, networking, input, and collision detection) and the game logic. Currently, the game logic can be loaded as a shared object file (usually for development) or this crazy thing called a QVM: a bytecode file which is either interpreted or JIT-compiled. Using ioquake3 (ioquake3.org) as a base, I added Python to the list. Frankly, I'm not amazed at how much easier it is to code game logic in Python, but some people might be. :D I'm working on the client game, and I'm about 30% done with that part. It looks like it's going to work out very well. It's the coolest thing to be able to pull down the console and type "/py print cg.data.pps.origin" and have it print out your current position. Now that the background is out of the way, I have two questions: 1) Is there a good guide for distributing applications with embedded Python? I'm planning (so far) on putting libpython2.4.so in the executable directory, along with everything from /usr/lib/python2.4 that the interpreter complains about not having. (I'll try to put them in a zip file - sans zipfile.py - if I possibly can.) Is there a nicer way to do this? 2) Is there any way to restrict Python modules from accessing files outside of a sandbox? One of the nice things about Quake 3's QVM files is that they are very, very restricted. They have no concept of a standard C library. This makes some things rather tricky, but also very secure: if the engine doesn't support it, you can't do it. If you download a Quake 3 mod from someone, you can be fairly sure it won't hose your system. In particular, it won't let you access files outside of the game directory. Is there a way I can accomplish something similar in an embedded Python application? I probably only have to make it secure on systems that don't have Python installed. Neil -- http://mail.python.org/mailman/listinfo/python-list
