Re: Subprocess with a Python Session?

[Hendrik van Rooyen]

 "Paul Boddie" <[EMAIL PROTECTED]> wrote:


> Fredrik Lundh wrote:
> > Paul Boddie wrote:
> >
> > > This is one of the more reliable methods since upon receiving a packet
> > > "delimiter" the receiver knows that the data is complete.
> >
> > and for people who want RELIABLE and not just "at least
> > not entirely unreliable", there's always:
> >
> >  http://cr.yp.to/proto/netstrings.txt
>
> That's why I hedged my bets and put "one of the more" rather than "the
> most" in that sentence. ;-) I've been using netstrings myself, although
> I didn't know that they had that particular name.
>
> > (if you control both ends, there's hardly ever any reason not to use
> > netstrings.  they're trivial to generate from Python, and pretty simple
> > to parse.).
>
> Indeed.

I was not aware that putting the length in front of a data packet had been
blessed with the name "netstring".
It is almost obligatory to do something like this if you are using raw sockets
as otherwise you never know where you are.

What I tend to do is more complex and probably also has a name that I am unaware
of - I "frame" packets between tildes - 0x7e - the SDLC/HDLC flag character -
this requires me to escape tildes, and my "escape" char, to prevent them
occurring in the message - I use the ordinary forward slash as the escape char,
and alter the poison chars by exclusive oring them with 0xff to invert - after
adding at least a bcc formed by the xor of all the chars in the package, (before
the escaping), and where its important, I use message numbers too... - but
then - I am paranoid...  And yes I once wrote some x25 type stuff in z80
assembler...   :-)

- Hendrik

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote:
> 
> 
>>André Thieme wrote:
>>
>>
>>>On the other hand can I see difficulties in adding macros to Python,
>>>or inventing a new object system, or adding new keywords without
>>>changing the sources of Python itself.
>>
>>Actually, an even bigger difficulty is the rejection of programmable
>>syntax by Guido, both for the near and distant future:
> 
> 
> Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.
> 
> 
>>"Programmable syntax is not in Python's future -- or at least it's not
>>for Python 3000. The problem IMO is that everybody will abuse it to
>>define their own language. And the problem with that is that it will
>>fracture the Python community because nobody can read each other's code
>>any more."
>>
>>http://mail.python.org/pipermail/python-3000/2006-April/000286.html.
> 
> 
> I couldn't have said it better myself.

No, but you could have quoted it more completely :

> But please save your breath. Programmable syntax is not in Python's
> future -- or at least it's not for Python 3000. The problem IMO is
> that everybody will abuse it to define their own language. And the
> problem with that is that it will fracture the Python community
> because nobody can read each other's code any more.

The last time c.l.l and c.l.p went to friendly war over macros we kept 
wondering why macros were any less comprehensible than functions or 
classes. Here it is!:

> 
> It's one thing to read code that calls an external function whose
> meaning you have to guess from its name. It's quite another thing to
> realize that you can't even know for sure where the function calls
> are. Let's not go there.

GvR seems to be thinking of something like the loop macro, which in its 
most commonly used syntax (it has two!) constitutes a distinct and 
unlispy language. If that is how macros were normally used (LOOP is 
quite abnormal) then, yikes, every macro could introduce a new language 
to be mastered.

U, that is not how macros are used normally. And it is a helluva lot 
of work to erect a new syntax as LOOP does, so it is not exactly 
tempting. So... is GvR being scared off by a straw man?

The other possibility is that he is just trying to justify not doing it 
because it would be so hard without the regular syntax of Lisp, 
including parens, and with the JIT module resolution problem discussed 
earlier in his remarks. Understandable.

A final good reason is, hey, we already /have/ Lisp, Python needs to be 
different in order not to get absorbed into the mother of all languages.

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[hankhero]

I was the one mentioning triple-quotes because it was one of the few
Python features i could think of that was better than Lisps.

> For me python is 'strong OOP' scripting language in first place.
> Inheritance, generalization and every kind of abstractions togeteher
> with clean and simple syntax make python perfect language for medium
> size "scripting" projects (ie just explore the code and add your
> features, no messing with compilers).
The Common-Lisp object systems has all and more OO-features, some which
you never probably have thought of before. Here's one:
Inheritance lets you specialise a method so a rectangle and a circle
can have a different Draw method. If you wouldn't have OO you would
need a function with if statements to dispatch on thing, if
thing=rectange then drawRectangle if thing=circle then drawCircle.
What if you want a draw method that takes a thing and a backend, then
you need if statements again, draw(self,backend): if backend ==
postscript do one thing else do another.
Maybe you can solve this with multiple inheritance, creating
RectangePostscript and CirclePostscript objects. Lisp supports multiple
inheritance too, but also multimethods which allow a looser coupling
between objects and dispatching on all parameters, not only the first
parameter (self in python speak). Just define one method
draw(rectange,postscript) and another draw(rectangle, pdf)

>  Exceptions, finally/except blocks,
Lisp has a unique exception system. Say ReadHtmlTag throws an exception
deep down in your system, UnexpectedChar. In Lisp you can define
recovery strategies all over your system. the IgnoreAttribute recovery
strategy can be in the same method as ReadHtmlTag. You can have another
ways to recover, IgnoreFile, or ReparseFile higher up in your program.
When you catch the error at the highest point in you main function, you
can choose which recovery you want to use. Either IgnoreAttribute and
continue in the ReadHtmlTag method or ReparseFile in the ParseFile
method. The stack and variables will be there right as when the error
occurred. If I write a library I don't have to guess if the users of my
library wan't me to show a nice GUI error message, ignore the error or
whatever. I provide all options and let they choose.

> automatic reference counts and destructors make it easy to
> write "robust" code.
No, Lisp doesn't have anything like that. There is a thing called the
garbage collector however, I think it exists in other languages.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[tmh]

This is from the perspective of an aerospace engineer who passed
through python several years ago on the way to lisp. Futhermore, this
is a 2 glass of wine response.

Nota Bene: All references to lisp in this response imply common lisp.

Mark Tarver wrote:
> How do you compare Python to Lisp?  What specific advantages do you
> think that one has over the other?

Way back, my initial motivation for learning python was the desire for
something to post-process data files with a cleaner syntax than perl.
It did that in spades. Despite having taken a C++ course in college, it
wasn't until I started using python that I grokked concepts of object
orientation. The aforementioned course spent too much time on basic
concepts. I also envisioned being able to rapidly prototype things in
python, then migrate them to C for performance. Long term, that was
going to be the value of python, rapid prototype->C for performance.

After writing a C interface for python to an engineering analysis code,
I realized that there was nothing rapid about prototyping in python
then migrating to C. This was also a period of time where there was
some schizophrenia concerning numpy versus numeric python. I know this
has been hashed out now, but at the time it was a distraction from the
development of the library and I lost patience.

So, I began searching for alternatives. Spent a couple years with a
language that requires everything to be an object. Can someone hand me
a hammer, I have a round peg here and a square hole there. Didn't have
good numeric support, but based on other perceived advantages, I had
hashed out an object system that would have provided numeric support.
As I'm implementing the numeric stuff, I'm getting very annoyed with
changes in the language that are requiring redesign of my objects.
Plus, performance, while not bad, is not the best. The work required
starts to outway the benefits, so here I go again, searching for the
one language to rule them all. That's when I seriously consider lisp.
At this point, if lisp doesn't work out, I'm giving up and going back
to fortran, never to look at another language again. Ever.

So, six months ago, I start digging into lisp. Hmm, lisp promotes
functional programming, but you can do imperative if you really want
to, or objective, or aspect, or your own.

What about types? Well, to quote Yogi Berra, "In lisp, types are not
required until they are required." This is great, I can quickly thrash
out some code, profile, correct the algorithm, profile, add types, bam!
Good performance. Looking over CMUCL/SBCL, really good numeric
performance.

Playing with code that is 30 years old, still runs, nice.

Forced to learn emacs, why was I using vi again? In the correct
settings, slime can be fun. Emacs+SBCL is one setting, I'll let you
think of the other.

What the hell are closures? Oh, yeah, now I get it, functions with
state, I can use that in simulations with state vectors, very
intuitive.

And macros? Well, I don't need a domain specific language, yet, but
using macros to build closures with multiple functions and shoving as
much computation into the compilation stage as possible makes for very
fast iteration over ODE's. Now I'm simultaneously iterating over 3
variations of an ODE in less time than iterating over 1 ODE in the
previous one size fits all language.

Code is data is code. I know, a tired old cliche. But for an engineer
who wastes too much time data processing and not enough time
analyzing/understanding said data, this is very powerful and provides a
warm fuzzy feeling. Yet again, that could be the wine.

> Note I'm not a Python person and I have no axes to grind here.  This is
> just a question for my general education.

I've been writing code for engineering solutions for 15 years in
various languages. I've gained more insight into coding in the last 6
months then in the previous 15 years. Since lisp allows you to employ
any and every programming technique, it actually requires you to
understand the techniques well enough to apply them when appropriate. I
still respect python if for no other reason than I learned concepts of
object orientation with it, but I don't consider for my coding.

You should study lisp for at least a year, use it for some decent size
projects. At the end of the day, even if you decide not to continue
using it, you will be a much better coder. My bet, though, is that if
you use it for a year, you won't want to use anything else. Don't be
deterred by the parens or the prefix notation. You will have to rewire
your brain to read lisp code, but the effort is worth it. The parens
disappear and there is an elegance and simplicity to prefix notation
that can't be matched by infix.

Time for some more wine.

Cheers,

Tom

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 14:52:33 -0500, Ken Tilton wrote:
> 
> 
>>
>>Aahz wrote:
>>
>>>In article <[EMAIL PROTECTED]>,
>>>Mark Tarver <[EMAIL PROTECTED]> wrote:
>>>
>>>
I'm looking at Python and I see that the syntax would appeal to a
newbie.  Its clearer than ML which is a mess syntactically.  But I
don't see where the action is in Python.   Not yet anyway.  Lisp syntax
is easy to learn.  And giving up an order of magnitude is a high price
to pay for using it over Lisp.
>>>
>>>
>>>Speaking as someone who had been programming for more than twenty years
>>>before learning Python (including a brief gander at Lisp), and also
>>>referring to many years of observations of newcomers to Python: Python's
>>>syntax also appeals to experienced programmers.
>>>
>>>I would say that your statement about Lisp syntax is wrong.  Not that it
>>>is technically inaccurate, but that it completely misses the point, so
>>>much so that it is wrong to say it.  One of the key goals of Python is
>>>readability, and while it is indeed easy to learn the rules for Lisp
>>>syntax, observational experience indicates that many people (perhaps even
>>>the vast majority of people) find it difficult to learn to read Lisp
>>>programs.
>>
>>No programming language is easy to read, 
> 
> 
> Well, you've just blown your credibility out the water with that nonsense. 

I am delighted to learn I had any to begin with.

Perhaps you are thinking of individual lines of code being easy to read. 
Sure.  I am talking about algorithms. Code cannot be read as if it were 
the Sunday comics. At any interesting level of complexity, one has to 
slow down and effectively hand-execute code in one's mind, not just read 
it as one reads natural language (and some of that makes one slow down 
to, no matter how well known are the individual words and grammar).

> 
> 
> 
>>and no Lisp programmer stopped 
>>using Lisp because they had been using it for a month and just could not 
>>get used to reading it.
> 
> 
> Or, to put it another way:
> 
> "No programmer who learned Lisp ever gave up before he learned Lisp."

That would be the obvious retort, but my observation was empirical, so I 
am afraid you need numbers, not word games.

You seem awfully hostile, by the way. Won't that make it harder to 
conduct an intelligent exchange of value to lurkers?

> I wonder, how many people gave up trying to learn Lisp because the
> language was too hard for them to read? Anyone like to bet that the number
> was more than zero?

Sorry, no one ever discovered Lisp, decided it would be great for 
programming, started learning it and then gave up because they could not 
handle the syntax. The syntax is actually easier to master because of 
its regularity, and lisp-aware editors handle the parentheses such that 
they disappear in a month.

Your position is untenable. It relies on this idea that all these Lisp 
programmers not only handle Lisp syntax effortlessly but also praise it 
as a significant advantage, they have all mastered several non-Lispy 
languages, but...what? They are mutants? Who just happen to have no 
problem with C and Java and Prolog and COBOL and Basic? Probably not.

If you are saying someone will glance at a Lisp book and say they cannot 
understand it, well, that is not very interesting is it?

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Steven D'Aprano]

On Fri, 08 Dec 2006 16:14:44 -0800, [EMAIL PROTECTED] wrote:

>> There is (IMO) some truth to that, but the flavor of Python
>> programming is not that much like Lisp any more.  Especially with
>> recent Python releases (postdating that Norvig article) using iterator
>> and generator objects (basically delayed evaluation streams) more
>> heavily, Python is getting harder to describe in Lisp terms.  It's
>> moving more in the direction of Haskell.
> 
> Sorry, I missed something here. Why do you need a release to have these
> sorts of things? Can't you just expand the language via macros to
> create whatever facility of this sort you need... Oh, sorry. You CAN'T
> expand the language Too bad.

No no, the phrase you want is "too good". 

> I guess waiting for Guido to figure
> out what Fits Your Mind is part of The Python Way.

For the benefit of anyone who thinks that the troll has a point, consider
this.

In the real world, programmers aren't lone wolves stalking the programming
landscape doing their own thing. Whether we're talking open
source projects maintained by volunteers, or commercial software teams,
standardized languages are a good thing. It is a good thing that not every
hare-brained idea that some random programmer comes up with can be
implemented as part of the core language. 

It is a good thing that when Fred decides to stop contributing to an
open source project (or leave the company), other people can read his code
without having to learn his Uber-Special Custom Macro Extended Language.
Even if Fred's USCMEL ran 35% faster (and thus saved an entire four
seconds on an average run with typical data!) the five or six weeks of
reduced programmer productivity when somebody else has to maintain his
code outweighs that.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

tmh wrote:


> Time for some more wine.

...and then just cut and paste the snipped bit into:

http://wiki.alu.org/The_Road_to_Lisp_Survey

...if you are not there already. The survey questions are optional and 
what you wrote is perfect as is. Tough call on what goes in:

http://wiki.alu.org/RtL_Highlight_Film

Candidates:

  "If you use it for a year, you won't want to use anything else."
  "I've gained more insight into coding in the last 6 months then in the 
previous 15 years."

I'd go with:

"Yet again, that could be the wine."

:)

kt

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Ken Tilton <[EMAIL PROTECTED]> writes:
> Not sure I understand why, unless you mean folks were raving about
> Lisp in the 60s. Today's raving is about a much different language,
> though the core elegance remains, and is as much about the contrast
> with other languages as it is about the pleasure of Lisp itself. Those
> raving about Lisp are quite accomplished at all those other languages,
> and know about what they are talking. I doubt the Pythonistas weighing
> in on this thread ever got far at all with Lisp, so... should they
> really be offering comparative analysis?

I've used and implemented Lisp but am not a real expert.  Some other
Python newsgroup regulars are very knowledgeable (more than me) about
it.  Peter Norvig (author of that comparison page) wrote a Lisp book,
if I remember correctly.

> >  Personally, I never like Lisp syntax; Clearly some people, some
> > fanatic judging by this thread :) think easily in prefix.  I am not
> > one of them.

The syntax is a pretty superficial thing.  The reaction from outsiders
to Lisp's parentheses and Python's indentation-based structure is
about the same.  You get used to it either way.

> The typical Pythonista values clean code but trembles in the face of
> macros, which exist to hide boilerplate. That means the only thing
> showing in any given block of code is exactly the interesting variable
> and function names. Talk about readability.

There is just not that much boilerplate in Python code, so there's
not so much need to hide it.

> Much of Lisp's power would be lost on a non-programmer, but Lisp might
> make a programmer out of a non-programmer if they had it in them. You
> might have the right language for you because what Python does have is
> lotsa libraries, and if you are just hacking scripts to glue together
> libraries the expressiveness of Lisp is more than offset by the better
> library support in Python.

Python is more expressive than Lisp in the sense that its built-in
datatypes and simple syntax for using them has to be done through
kludgy macros and libraries with Lisp.  I would say Lisp's facilities
for developing very large programs are better, and (for now) Lisp has
much more serious compilers.  See the PyPy project for what's
happening in that direction with Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

"Wolfram Fenske" <[EMAIL PROTECTED]> writes:
> with a couple of macros.  I. e. if Common Lisp didn't have CLOS, its
> object system, I could write my own as a library and it would be just
> as powerful and just as easy to use as the system Common Lisp already
> provides.  Stuff like this is impossible in other languages.

If Common Lisp didn't have lexically scoped variables (most Lisp
dialects before Scheme didn't have them) then it would be very
difficult to add that with macros.

Do you seriously think lexical scoping is the last word in language
features and that there's now nothing left in other languages that
can't straightforwardly be done in CL?  Hint:
call-with-current-continuation (also known as call/cc).

I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.

Take a look sometime at Hughes' paper on "Why Functional Programming
Matters":

   http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[tayssir . john]

Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 08:50:41 -0800, George Sakkis wrote:
> Why is that a difficulty? Like Guido, I think that's an ADVANTAGE.
>
> > "Programmable syntax is not in Python's future -- or at least it's not
> > for Python 3000. The problem IMO is that everybody will abuse it to
> > define their own language. And the problem with that is that it will
> > fracture the Python community because nobody can read each other's code
> > any more."
> >
> > http://mail.python.org/pipermail/python-3000/2006-April/000286.html.
>
> I couldn't have said it better myself.

This is sort of the top-down philosophy, where you have a "benevolent
dictator" rather than more of a democracy. (People actually call them
benevolent dictators.) Like any other top-down society, the benevolent
dictator tells you that he and his lieutenants are merely protecting
you against anarchism; terrible things will happen if you have too much
freedom.

However, I am paid to write Common Lisp, I've recently seen a terribly
unreadable codebase, and the problem wasn't macros -- merely overuse of
global vars. Nothing exotic.

Do we ban loops and recursion because we face infinite looping? Or, as
"power users," do we do the obvious, which is to learn how to use power
correctly?

How do Lisp users deal with a powerful weapon like macros? Well first,
many people don't define new ones. Instead, they use someone else's
time-tested macros, from some library. However, when they do use
macros, it's to make less readable code more readable.

Is all Python code readable? I somehow doubt it. Is the pressure from
experienced Python users stretching Python away from a clean design? I
suspect it is. (Though I could be wrong, as I don't pay close attention
to Python at the moment.)

I'm not trying to convince anyone that Lisp's radical flexibility here
is "better", just there's a different perspective to consider than what
Guido says. Many in the Lisp community have noticed the frequency of
sentences starting with "Guido said" from the Python world, and maybe
that sounds as disturbing to heavy Lisp users as macros sound to heavy
Python users.


Tayssir

--
"Patriotism is usually the refuge of the scoundrel. He is the man who
talks the loudest."
-- Mark Twain, 1908

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

"tmh" <[EMAIL PROTECTED]> writes:
> I've been writing code for engineering solutions for 15 years in
> various languages. I've gained more insight into coding in the last 6
> months then in the previous 15 years. Since lisp allows you to employ
> any and every programming technique, it actually requires you to
> understand the techniques well enough to apply them when appropriate.

You might try Mozart, .

> You should study lisp for at least a year, use it for some decent size
> projects. At the end of the day, even if you decide not to continue
> using it, you will be a much better coder. My bet, though, is that if
> you use it for a year, you won't want to use anything else. 

I've used Lisp for a long time and I've implemented it from scratch
(small dialects, not full CL) more than once.  There's something
primordial about it that is very satisfying to the inner urges.  But
there are higher forms of life out there these days too.

Do you know the Paul Graham piece "Beating the Averages"?  It's at:

   http://www.paulgraham.com/avg.html

The error in it is that Lisp is really just another Blub.

  http://weblog.raganwald.com/2006/10/are-we-blub-programmers.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Steven D'Aprano]

On Sat, 09 Dec 2006 02:29:56 -0500, Ken Tilton wrote:

> 
> 
> David Lees wrote:

> Those raving about 
> Lisp are quite accomplished at all those other languages, and know about 
>   what they are talking. 

Such a sweeping generalization. Every person who raves about Lisp is also
accomplished with other languages. Yeah, right. I believe you, even if
millions wouldn't.


> I doubt the Pythonistas weighing in on this 
> thread ever got far at all with Lisp, so... should they really be 
> offering comparative analysis?

I hit my hand with a hammer once. I didn't keep going until I was an
expert in hitting-own-hand-with-hammer before deciding that hitting my
hand with a hammer was not for me. Did I do the wrong thing? Should I have
kept going until I was an expect at it?

(Of course, writing Lisp isn't precisely like hitting one's hand with a
hammer. With the hammer, the endorphins kick in eventually, and it can
become quite pleasant...)


>>  Personally, I never like Lisp syntax; 
>> Clearly some people, some fanatic judging by this thread :) think easily 
>> in prefix.  I am not one of them. 
> 
> Yeah, you are, you just did not use it heads down for a month.

The sheer arrogance of this claim is astounding.

Actually, this is comp.lang.lisp. It isn't astounding at all.

I don't know, maybe lisp coders actually are more intelligent than
ordinary mortals, but it has been my experience that they have absolutely
no grasp whatsoever of the way most (many? some?) people think. And I'm
not talking about can't-walk-and-think-at-the-same-time people either, I'm
talking about bright, intelligent people who, nevertheless, don't agree
with lisp coders.


> The way 
> to tell if you spent enough time on Lisp is to look at Lisp code. If you 
> see any parentheses, you have not spent enough time. They disappear in a 
> month.

If the parentheses are that meaningless, why do you need them?


> The typical Pythonista values clean code but trembles in the face of 
> macros, which exist to hide boilerplate. 

Funny, when I write code, I try to remove boilerplate, not hide it.


> That means the only thing 
> showing in any given block of code is exactly the interesting variable 
> and function names. Talk about readability.

Yes. And your point is?


>> Computer languages are tools and 
>> everyone should pick the ones that they are most comfortable and 
>> productive with.
> 
> No, languages are not interchangeable.

Perhaps you should consider what the term "Turing complete" implies.


> Python is a fine language, but 
> Lisp is much more expressive/powerful.

Maybe so. A bulldozer is a lot more powerful than a tack-hammer, but if
somebody suggested using a bulldozer to lay carpet, I'd politely show them
to the door. Sometimes more power isn't better.


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Paul Rubin  writes:
>http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
> 
> The examples in it are pretty easy to do in Python or Scheme, but I
> think not so easy in CL.

Hmm, well I guess they can be done in CL too, about the same way as in
Scheme, but I'd say you have to be more careful.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Alex Mizrahi]

(message (Hello 'Kay)
(you :wrote  :on '(8 Dec 2006 12:25:09 -0800))
(

 KS> O.K. I agree with what you said about the generic function vs per
 KS> object dictionary dispatch.
 KS> But do the performance differences vanish when only builtin types and
 KS> functions are used to express Python algorithms?

no.
language semantics require python to do dict lookup on each access to some 
global function (or builtin) or variable.
i don't have enough time for in-depth analysis, but here's what's it.
suppose we have

def Fib(n):
   if n < 2:
  return 1
   else:
 return Fib(n -2) + Fib(n-1)

import dis
dis.dis(Fib)

you will see this:
...
21 LOAD_GLOBAL  1 (Fib)
24 LOAD_FAST0 (n)
27 LOAD_CONST   2 (1)
30 BINARY_SUBTRACT
31 CALL_FUNCTION1
34 LOAD_GLOBAL  1 (Fib)
37 LOAD_FAST0 (n)
40 LOAD_CONST   1 (2)
43 BINARY_SUBTRACT
44 CALL_FUNCTION1
47 BINARY_ADD
48 RETURN_VALUE

now let's check what is LOAD_GLOBAL in ceval.c (i have Python 2.4.1 
sources):

  case LOAD_GLOBAL:
   w = GETITEM(names, oparg);
   if (PyString_CheckExact(w)) {
/* Inline the PyDict_GetItem() calls.
   WARNING: this is an extreme speed hack.
   Do not try this at home. */
long hash = ((PyStringObject *)w)->ob_shash;
if (hash != -1) {
 PyDictObject *d;
 d = (PyDictObject *)(f->f_globals);
 x = d->ma_lookup(d, w, hash)->me_value;
 if (x != NULL) {
  Py_INCREF(x);
  PUSH(x);
  continue;
 }
 d = (PyDictObject *)(f->f_builtins);
 x = d->ma_lookup(d, w, hash)->me_value;
 if (x != NULL) {
  Py_INCREF(x);
  PUSH(x);
  continue;
 }
 goto load_global_error;
}
   }
   /* This is the un-inlined version of the code above */
   x = PyDict_GetItem(f->f_globals, w);
   if (x == NULL) {
x = PyDict_GetItem(f->f_builtins, w);
if (x == NULL) {
  load_global_error:
 format_exc_check_arg(
  PyExc_NameError,
  GLOBAL_NAME_ERROR_MSG, w);
 break;
}
   }
   Py_INCREF(x);
   PUSH(x);
   continue;

so we can see PyDict access. moreover, it's inlined, since it's very 
performance-critical function.
but even inlined PyDict access is not fast at all. ma_lookup is a long and 
hairy function containing the loop.
moreover, we can see that there are two dict lookups -- into globals and 
builins.
lookup into a global hash should about order of magnitude slower than simple 
table fetch, so here's the root of python's slowness.

how lisp can be faster here? lisp has SYMBOLs and well-defined semantics of 
source code parsing.
first source code is processed by reader, that outputs trees of code. each 
variable or function name becomes a SYMBOL object. symbols are typically 
interned into packages, but they don't need to be looked-up in the packages 
in runtime -- in fact, it's not possible at all.
i can read a piece of code and then unintern some symbol from package --  
that will not make that code invalid. packages are used mostly by reader. 
(also, i can have many symbols with same name, if they are not interned --  
and they will be all different objects)
in runtime, lisp has to lookup symbol's function -- but symbol can be 
implemented as a structure, and symbol-function can be just it's field 
access.

one more thing -- you can see lookup into builins, so they are in dict too! 
and you can see that builtins dict is checked only if name is not found in 
globals, so builtins are even slower than globals. that's a reason for 
performance slowdowns too.
one can say that it's the only way to change builtins in runtime. yes, but 
dict lookup is a big price for it (well, if python use symbols, it would be 
faster).
in fact, Common Lisp also allows to redefine "built-in" function -- you can 
define a symbol with a same name as builtin in some package and use it, it 
will "shadow" symbol in the common-lisp package (common-lisp:+). you can 
change symbol-function of this symbol in runtime and do whatever you want. 
but symbols in common-lisp package are immutable. that makes it possible to 
optimize code.

and there's inlining. for example, in fib definition:

(defun fib (n)
(if (< n 2)
1
 (+ (fib (- n 2))
 (fib (- n 1)

CLISP does not even use symbol FIB in function bytecodes -- it notes that 
it's a recursive function calls, so instead of normal function call it does 
a local jump.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity") 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Snake references just as ok as Monty Python jokes/references inpython community? :)

[Hendrik van Rooyen]

<[EMAIL PROTECTED]> wrote:


> Problem is I don't know that anyone born after Elvis died gets any of
> these Monty Python jokes.

But hey - Elvis is not dead! - that is just a conspiracy theory that was 
originated by the Cliff Richard's fan club...

- Hendrik


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Steven D'Aprano]

On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:

> if Common Lisp didn't have CLOS, its object system, I could write my own
> as a library and it would be just as powerful and just as easy to use as
> the system Common Lisp already provides.  Stuff like this is impossible
> in other languages.

Dude. Turing Complete. Don't you Lisp developers know anything about
computer science?

Anything any language can do is possible in any other language, if you are
willing to write your own libraries. And debug them. Let's not forget the
debugging and testing, unless you'd like us to believe that Lisp code
never contains bugs. Lisp developers so often gloss over that: "Oh,
feature X is *easy*, I could write it in a couple of macros. Two or three.
Maybe thirty. Or forty, max. And they would work the right way first time.
No, I haven't actually done it myself. But I'm sure I could do it, easy."



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:
> It is a good thing that not every
> hare-brained idea that some random programmer comes up with can be
> implemented as part of the core language. 

Well, that's the FUD/strawman, but nothing more. Just a hobgoblin to 
keep the Pythonistas from straying. But you have an excuse: Lispniks 
always /talk/ about macros giving us the ability to create a DSL. But no 
one does. :) Macros mostly hide implementation -- always a good thing -- 
where functions cannot.

This, btw, is why Norvig brushing off macros with the ability to use 
regex to parse a DSL was so disappointing.

I guess your other excuse is that your BDFL says the same thing.

All in all, this is getting pretty funny. I am starting to picture you 
all (including GvR) running around with your hands over your ears going 
woo-woo so you cannot hear what we are saying.

:)

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Paul Rubin wrote:

> 
> Do you know the Paul Graham piece "Beating the Averages"?  It's at:
> 
>http://www.paulgraham.com/avg.html
> 
> The error in it is that Lisp is really just another Blub.
> 
>   http://weblog.raganwald.com/2006/10/are-we-blub-programmers.html
> 

There we find: "But when our hypothetical Blub programmer looks in the 
other direction, up the power continuum, he doesn't realize he's looking 
up. What he sees are merely weird languages... Blub is good enough for 
him, because he thinks in Blub."

What is up the power continuum from Lisp?

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote  :on '(08 Dec 2006 17:15:32 -0800))
(

 PR> Huh?  Are you saying Lisp systems never release new versions?  And you
 PR> can't implement Python generators as Lisp macros in any reasonable
 PR> way.  You could do them in Scheme using call-with-current-continuation
 PR> but Lisp doesn't have that.

we can implement Scheme's call-with-current-continuation first :)
it's relatively easy -- just a code walker that coverts everyting into CPS.
i've used one for a web application development.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity") 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ramon Diaz-Uriarte]

On 08 Dec 2006 19:56:42 -0800, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:

(...)

> 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.

Paul, I find most of your comments well thought. But I don't follow
these. Could you elaborate?

a) "old-fashioned"? Is that supposed to be an argument? I guess
addition and multiplication are old-fashioned, and so is calculus;so?
I think "old-fashioned" should only carry a negative connotation in
the fashion world, not in programming.


b) "the more serious Lisp-like language designers have moved on to
newer ideas." Can you elaborate? I am not an expert but by looking at,
say, lambda the ultimate, I'd say this statement is just not true. And
which are these "newer ideas"; what programming languages are
incorporating them? (Scala, Mozart/Oz, Alice-ML, ...).


R.


> --
> http://mail.python.org/mailman/listinfo/python-list
>


-- 
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Andrea Griffini]

Alex Mizrahi wrote:

...

> so we can see PyDict access. moreover, it's inlined, since it's very 
> performance-critical function.
> but even inlined PyDict access is not fast at all. ma_lookup is a long and 
> hairy function containing the loop.

I once had a crazy idea about the lookup speed problem;
can't the lookup result be cached in the bytecode ?
I am thinking to something like saving a naked pointer
to the value together with a timestamp of the dictionary.
With timestamp I mean an integer (may be 64 bit) that is
incremented and stamped in the dictionary every time
the dictionary is modified; this counter can be
shared among all dictionaries. The use of a naked pointer
would be IMO safe because to invalidate the object you
would also need to touch the dictionary.

Using this approach the lookup for a constant
string could be

if (bytecode_timestamp == dict->timestamp)
 {
   // just use the stored result
 }
 else
 {
// do standard lookup and store
// result and dict->timestamp
 }

I'd expect that this would be a big win for a lot of
lookup as the problem with python speed is the *potential*
dynamism... hopefully people don't keep changing what
math.sin is during the execution so the vast majority of
lookups at module level will find the timestamp being valid.
This invalidation is not "optimal" as changing math.sin
would also invalidate any lookup on math, but IMO a lot
of lookups happen in *fixed* dictionaries and the the
overhead of checking the cached result first should be
small. What it would break is code that actually
dynamically changes the string being looked up in the
dictionary in the bytecode, but I hope those places
are few if the exist at all.

Is this worth investigation or it has already
been suggested/tried ?

Andrea
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Steven D'Aprano]

On Fri, 08 Dec 2006 22:02:59 +0200, Alex Mizrahi wrote:

> you have an expression 3 + 4 which yields 7.
> you have an expression 4 * 1 which yields 4.
> if you paste 3 + 4 in place of 1, you'll have 4 * 3 + 4 = 16. as we know, * 
> is commutative, but 3 + 4 * 4 = 19.
> so result depends on implicit operator precendence rules.
> 
> in lisp, if you paste (+ 3 4) in (* 4 1), you'll have (* 4 (+ 3 4)), and it 
> does not depend on order of operands, (* (+ 3 4) 4) yields same results. you 
> do not have to remember precendence rules 

Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more of a
pain in the rear end than it is worth, even if it saves you a tiny bit of
thought when pasting code.

Except, of course, it doesn't really save you any thought. You can't just
expect to paste an expression randomly into another expression and have it
do the right thing. Oh, it will compile all right. But it won't do the
right thing! Since you -- not the compiler -- have to understand the
semantics of what you are pasting where, and paste the right expression
into the right place, the effort saved by not using infix notation is less
than the effort needed to mentally translate between prefix and infix.

If you are one of those people who actually think in prefix notation, then
I raise my hat to you while backing away slowly.

(And actually, I'll give you one point: I've been hitting my head against
a brick wall over a particular problem, and I think your email just gave
me a clue how to solve it. Sometimes prefix/postfix notation is the right
tool for the job. See, I can learn from Lisp.)



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jon Harrop]

Steven D'Aprano wrote:
> Anything any language can do is possible in any other language

Not true. Concurrency, for example.

> Lisp developers so often gloss over that: "Oh, 
> feature X is *easy*, I could write it in a couple of macros. Two or three.
> Maybe thirty. Or forty, max. And they would work the right way first time.
> No, I haven't actually done it myself. But I'm sure I could do it, easy."

True.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Alex Mizrahi]

(message (Hello 'Steven)
(you :wrote  :on '(Sat, 09 Dec 2006 20:02:06 +1100))
(

 SD> It is a good thing that when Fred decides to stop contributing to an
 SD> open source project (or leave the company), other people can read his
 SD> code without having to learn his Uber-Special Custom Macro Extended
 SD> Language. Even if Fred's USCMEL ran 35% faster (and thus saved an
 SD> entire four seconds on an average run with typical data!) the five or
 SD> six weeks of reduced programmer productivity when somebody else has to
 SD> maintain his code outweighs that.

have you ever faced this problem?
it's not a problem at all.

and it's possible to write unmaintanable code in any langauge. for example, 
Bram Cohen's BitTorrent (written in Python)
has a constructors with 21 positional parameters

class Rerequester:
def __init__(self, url, interval, sched, howmany, minpeers,
connect, externalsched, amount_left, up, down,
port, ip, myid, infohash, timeout, errorfunc, maxpeers, 
doneflag,
upratefunc, downratefunc, ever_got_incoming):

and here's how it called:

rerequest = Rerequester(response['announce'], 
config['rerequest_interval'],
rawserver.add_task, connecter.how_many_connections,
config['min_peers'], encoder.start_connection,
rawserver.add_task, storagewrapper.get_amount_left,
upmeasure.get_total, downmeasure.get_total, listen_port,
config['ip'], myid, infohash, config['http_timeout'], errorfunc,
config['max_initiate'], doneflag, upmeasure.get_rate, 
downmeasure.get_rate,
encoder.ever_got_incoming)

i think it might be a bit hard to non-autist to remember order of parameters 
in such constructor. (and it's not the only one such place in BitTorrent)
and that guy teaches us how to write maintanable code! 
http://advogato.org/article/258.html

thus, you don't need macros to write unmaintanable code -- functions are 
enough for this. and with macros you can make it more maintanable, actually


)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity") 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Alex Mizrahi]

(message (Hello 'Ken)
(you :wrote  :on '(Sat, 09 Dec 2006 04:26:02 -0500))
(

 KT> keep the Pythonistas from straying. But you have an excuse: Lispniks
 KT> always /talk/ about macros giving us the ability to create a DSL. But
 KT> no one does. :)

certainly there's no reason to make a new DSL each day, but sometimes they 
are good.
i've recently posted an example of DSL to do queries to RDF data base -- i 
find it's very helpful.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity") 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Ken Tilton <[EMAIL PROTECTED]> writes:
> What is up the power continuum from Lisp?

These days I've been fooling with Haskell.  Mozart/Oz is also
interesting.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jon Harrop]

Mark Tarver wrote:
> How do you compare Python to Lisp?  What specific advantages do you
> think that one has over the other?
> 
> Note I'm not a Python person and I have no axes to grind here.  This is
> just a question for my general education.

>From my point of view as neither a Lisp nor Python user:

Lisp has some interesting features that separate it from many other
programming languages. In contrast, there is nothing interesting about the
Python language, AFAIK.

Lisp is fairly elegant in the way that it facilitates different programming
paradigms. Python is inelegant.

Lisp is likely to be faster.

Lisp is more mature but Python is (currently) more popular.

I think that people who know more languages and more about programming will
be much more inclined to use Lisp than Python. Look at the contents of the
newsgroups for example, c.l.l has a thread on memoization whereas c.l.p has
a thread about wrestling oiled pigs.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Ken Tilton wrote:

> What is up the power continuum from Lisp?

3-Lisp. ;)


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Paul Rubin wrote:
> "Alex Mizrahi" <[EMAIL PROTECTED]> writes:
>> we can implement Scheme's call-with-current-continuation first :)
>> it's relatively easy -- just a code walker that coverts everyting into CPS.
> 
> It's not enough to convert to CPS, you have to be able to actually
> save the continuation when you switch to another one, so you can go
> back to the first one later.  

You get this for free once your program is in CPS. (This is true for any 
language, btw. It's just that it's easier to abstract away from the 
details of CPS in Lisp.)


Pascal

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Alex Mizrahi]

(message (Hello 'Andrea)
(you :wrote  :on '(Sat, 09 Dec 2006 11:08:34 +0100))
(

??>> so we can see PyDict access. moreover, it's inlined, since it's very
??>> performance-critical function.
??>> but even inlined PyDict access is not fast at all. ma_lookup is a long
??>> and hairy function containing the loop.

AG> I once had a crazy idea about the lookup speed problem;
AG> can't the lookup result be cached in the bytecode ?

actually i don't see any reason why lookup is needed at all.
i think you can use approach similar to Lisp Symbols in Python, so it's
implementation slow, not the language.
there are some subtle differences -- for example, if you del global binding,
function gets undefined, but in Lisp uninterning does not invalidate code
that uses that symbols. but you can easily override this invalidating the
symbol bindings.

i think symbols can be implemented just as cache you suggest, but without
need of timestamp, but with additional indirection.
you should associate a SYMBOL with each entry in the globals dict, however
those SYMBOL lifetime should be managed independently (lifetime management
is one of difficulties, but i think not non-solvable). once you need to
cache lookup, you cache a SYMBOL pointer.
then you just get symbol's value on firther lookups. if dict gets update, it
should update all symbols associated with it. if entry (or whole dict) is
deleted, it should invalidate all symbols, so accessing them will produce
error, but it should not delete symbols.
you can resolve symbols not on first access, but during the read operation
(when bytecode is produced), as it's done in Lisp.

however, it's only applicable to LOAD_GLOBAL and STORE_GLOBAL, i think it
won't be possible to optimize STORE_ATTR that way without changing
semantics.

by the way, maybe some optimizations are already implemented in Psyco?
it's Python JIT with profile-guided type optimization, but i don't know how 
it deals with lookups..

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

"Ramon Diaz-Uriarte" <[EMAIL PROTECTED]> writes:
> a) "old-fashioned"? Is that supposed to be an argument? I guess
> addition and multiplication are old-fashioned, and so is calculus;so?
> I think "old-fashioned" should only carry a negative connotation in
> the fashion world, not in programming.

If someone handed you a calculus book written in Latin, you'd probably
find it undesirably old-fashioned too.  

> b) "the more serious Lisp-like language designers have moved on to
> newer ideas." Can you elaborate? I am not an expert but by looking at,
> say, lambda the ultimate, I'd say this statement is just not true. And
> which are these "newer ideas"; what programming languages are
> incorporating them? (Scala, Mozart/Oz, Alice-ML, ...).

I don't know about Scala.  I'd add Haskell to that list.  I'm not
enough of a languages buff to know what's happening at the bleeding
edge.  

Lispers sometimes get confused into thinking you can't make a language
less powerful by adding stuff to it.  For example, part of the power
of Lisp comes from reliable garbage collection, which follows from the
language not having naked pointers.  No more buffer overflow bugs
clobbering the return stack and injecting hostile code, no more
double-free errors, etc.  As long as your program is written purely in
Lisp, there are certain classes of bugs that you simply don't have to
worry about.  But if you add C++ style pointers to Lisp, your programs
are once again susceptable to all those bugs, and so you've made Lisp
in a sense less powerful.  And if you can make Lisp less powerful by
adding stuff, you logically have to ask whether you can make it more
powerful by subtracting stuff.

Haskell is pretty neat in that it basically removes things like setq.
That makes possible (for example) very cool simplifications to
concurrent programming.  See the paper "Composable memory transactions":

  http://research.microsoft.com/~simonpj/papers/stm/index.htm

Yeah you could do that with Lisp by writing in a restricted style,
just like you could avoid pointer errors in C++ by writing in a
restricted style.  But it's hard for the compiler to guarantee that
your program obeys the restrictions.  You could write a language like
Ada or Java that makes a lot of guarantees, but is unexpressive and a
huge pain to program in.  You can write a language like Lisp that's
expressive but doesn't make as many guarantees.  Interesting problems
in language design arise in writing languages that are expressive AND
make guarantees.
-- 
http://mail.python.org/mailman/listinfo/python-list

Shed Skin 0.0.15

[Mark Dufour]

Hi all,

After getting bogged down with work for a few months, I'm finally back
to Shed Skin development. I have just released 0.0.15, with the
following changes:

-python2.5 support/compatibility
-any, all, conditional expression support
-moved libs to 'lib' dir; made it easier to add modules (see README)
-os.stat, os.path.{split, splitext, isfile, isdir, islink, exists}
compiled from PyPy source
-os.{chdir, rename, stat, lstat} added
-fnmatch module added
-random.{sample, seed} added
-several important bugfixes (e.g. except getopt.GetoptError)

There's more information about this release and the current state of
Shed Skin on my blog:

http://shed-skin.blogspot.com/

I also started a page on Wikipedia. Maybe a text like this should
replace the one on the Shed Skin website:

http://en.wikipedia.org/wiki/Shed_Skin

Projects for the near future are getting 'shuffle-db' working (a
600-line program to rebuild the database on an ipod shuffle; see my
blog), and converting the 're' module from the PyPy implementation to
C++ using Shed Skin.

Please try out the new release, and let me know about any
problems/wishes/successes. As always, I am very happy with minimized
pieces of code that fail to compile or should produce a (better) error
or warning message.

http://mark.dufour.googlepages.com


Mark.
-- 
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

"Alex Mizrahi" <[EMAIL PROTECTED]> writes:
> we can implement Scheme's call-with-current-continuation first :)
> it's relatively easy -- just a code walker that coverts everyting into CPS.

It's not enough to convert to CPS, you have to be able to actually
save the continuation when you switch to another one, so you can go
back to the first one later.  Maybe I'm missing something but I just
don't see how to do that in the Lisp execution model.  I guess you
could write an interpreter in Lisp that simulates it all, but it might
as well be a Python interpreter ;-).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bjoern Schliessmann]

samantha wrote:

> What are you? A pointy haired boss?

What are you? A 12 year old that has just learned to use Google
Groups? 8)

Regards,


Björn

Xpost cll,clp
Fup2 poster

-- 
BOFH excuse #211:

Lightning strikes.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Logging output from python

[Leonhard Vogt]

Cameron Walsh schrieb:
> 
> If it's on linux you can just redirect the screen output to a file:
> 
> python initialfile.py 1>stdout.txt 2>stderr.txt


> As for windows, I'll test it now...
> 
> It turns out you can at least redirect the output to a file, I'm not
> sure what it does with standard error or even if it exists or not.
> 
> python initialfile.py > output.txt
> 
> should work.

 >cmd
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

 >type output.py
import sys

print 'This is print.'
sys.stdout.write('This is stdout.write()\n')
sys.stderr.write('This is stderr.write()\n')

 >python output.py 1>stdout.txt 2>stderr.txt

 >type stdout.txt
This is print.
This is stdout.write()

 >type stderr.txt
This is stderr.write()

Seems on XP it works too.

Leonhard
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bjoern Schliessmann]

Ken Tilton wrote:

> Note also that after any amount of dicing I simply hit a magic key
> combo and the editor reindents everything. In a sense, Lisp is the
> language that handles indentation best.

Erm ... because there's an editor for it that indents automatically?
Or did I miss the point?

Regards,


Björn

Xpost cll,clp

-- 
BOFH excuse #235:

The new frame relay network hasn't bedded down the software loop
transmitter yet. 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Automatic debugging of copy by reference errors?

[Niels L Ellegaard]

Gabriel Genellina wrote:
> I think you got in trouble with something and you're trying to avoid it
> again - but perhaps this is not the right way. Could you provide some
> example?

I have been using scipy for some time now, but in the beginning I made
a few mistakes with copying by reference. The following example is
exagerated
for clarity, but the principle is the same:

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:continue
print output

Now some of my fortran-using friends would like to use python to
analyze their data files. I wanted them to avoid making the same
mistakes as I did so I thought it would be good if they could get some
nanny-like warnings saying: "Watch out young man. If do this, then
python will behave differently from fortran and matlab". That could
teach them to do things the right way.

I am not an expert on all this, but I guessed that it would be possible
to make a set of constraints that could catch a fair deal of simple
errors such as the one above, but still allow for quite a bit of
programming.

  Niels

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Steven D'Aprano]

On Sat, 09 Dec 2006 00:56:35 -0800, Paul Rubin wrote:

> The syntax is a pretty superficial thing.  The reaction from outsiders
> to Lisp's parentheses and Python's indentation-based structure is
> about the same.  You get used to it either way.

I don't agree. Syntax is significant for human readers, who are the vast
majority of programmers.

Yes, people will get used to most syntax, eventually. But "used to"
doesn't necessarily mean "can read it efficiently". I did a lot of FORTH
coding in my youth, far more lines of code than Pascal, but Pascal was
always easier to read than FORTH for me. Now, I can look at a page of
Pascal code and it is still readable, but the FORTH... urgh.

Most programming languages, yes even FORTH, used indenting for human
readability. They just don't make them syntactically important. Python
just enforces good indenting. 

I've read all the arguments against significant indents/whitespace, or
in favour of braces, and while there are a few minor good points they
make, a few edge cases where Python's significant indentation is
sub-optimal, overall I believe that the famous reaction of programmers to
Python and whitespace is simply them being more like cats than usual:

"It's different, anything different is frightening, I don't like it, hiss
hiss spit!!!"

But Lisp's syntax is so unlike most written natural languages that that it
is a whole different story. Yes, the human brain is amazingly flexible,
and people can learn extremely complex syntax and grammars (especially if
they start young enough) so I'm not surprised that there are thousands,
maybe tens or even hundreds of thousands of Lisp developers who find the
language perfectly readable.

But that isn't to say that the syntax of Lisp is for everybody. Far from
it -- I'd be willing to bet that Lisp developers are a self-selected group
of far above average intelligence. That would explain why so many of them
seem to be so much more comfortable with higher-order functions than most
other people -- even intelligent people. 

(Looking back, I'm embarrassed about my first reaction to factory
functions all those years ago. Hiss hiss spit. But even with added
familiarity, there comes a time where one has to question the benefit of
sufficiently high-order functions. If you are writing a factory function
that returns factory functions that return factory functions that return
the functions that you needed in the first place, chances are you really
need to rethink your tactics.)

If I'm right, then maybe Lisp is "better" in some absolute sense, *for
those who can use it*. For those who can't, it isn't just a matter of
(say) the syntax being hard to read because it is unfamiliar, but it
being objectively harder to use.

An interesting study would be to track people's eyeballs as they read
code, or look at how much oxygen their brain uses. Do Lisp coders do more
work to read Lisp than Python coders do to read Python? I suspect they do,
but successful Lisp coders don't notice. Everybody else does, and
gravitate to languages which might not be "better" but are "good enough".

(If my post leads to any Lisp developer's already swollen head exploding
from pride, my job here is done *wink*)


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Greg Menke]

Paul Rubin  writes:

> [EMAIL PROTECTED] (Rob Warnock) writes:
> > Weird. This is exactly why I use *Lisp* -- because it stays
> > completely readable even if you don't use it on a daily basis!!!
> 
> Hmm.  I haven't used Lisp in a while and no longer find it so
> readable.

I haven't used Python in a while and don't find it especially readable.
A number of years ago I was looking for a high level alternative to C++,
I ran screaming from Perl.  Python was better but I ended up preferring
Lisp.  Like Python's space indents, Lisp's parens disappear into the
background once you learn how they work.  Whats left is the language
itself and I found Lisp worked more easily.
 
> 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.

The trick is separating new ideas from fads or things that look new but
are really incomplete reimplementations of older ideas.  Frankly I have
yet to find some language "feature" that doesn't exist in Common Lisp or
one of the implementations- OTOH I use it to write software to get
things done so my requirements are essentially practical rather than
doctrinal.

Gregm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[bearophileHUGS]

Andrea Griffini>Is this worth investigation or it has already been
suggested/tried ?<

Recently some people around the net have discussed about similar ideas
as a possible way to speed up Ruby interpreters a lot.

Bye,
bearophile

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Rob Warnock]

Steven D'Aprano  <[EMAIL PROTECTED]> wrote:
+---
| Wolfram Fenske wrote:
| > if Common Lisp didn't have CLOS, its object system, I could write my own
| > as a library and it would be just as powerful and just as easy to use as
| > the system Common Lisp already provides.  Stuff like this is impossible
| > in other languages.
| 
| Dude. Turing Complete. Don't you Lisp developers know anything about
| computer science?
| 
| Anything any language can do is possible in any other language,
| if you are willing to write your own libraries. And debug them.
+---

Yes, true, but by then you've effectively reimplemented Lisp!  ;-}

http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule
Greenspun's Tenth Rule of Programming [...]:
"Any sufficiently complicated C or Fortran program
contains an ad hoc, informally-specified, bug-ridden,
slow implementation of half of Common Lisp."


-Rob

-
Rob Warnock <[EMAIL PROTECTED]>
627 26th Avenue http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Automatic debugging of copy by reference errors?

[Marc 'BlackJack' Rintsch]

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.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Using Py_InitModule3 -> [Linker Error] Unresolved external '_Py_InitModule4TraceRefs'

[iwl]

Fredrik Lundh schrieb:
>
> you've mixed components compiled with Py_TRACE_REFS with components that
> aren't compiled with Py_TRACE_REFS.  don't do that.
>
H'm does this mean I have to write something like
#define Py_TRACE_REFS
befor I include 

> (what is it with you C programmers these days, btw?  have they stopped
> teaching how to how use "grep" and library inspection tools when they
> teach C and C++ ?)
>
I'm afraid so - I haven't teach me anything about grep yet.

I just downloaded the Phyton 2.5 Windows-Installer including C-Libs and

Headers and include  and linked Python25.lib after some
conversion needed for Borland C++ Builder 6 und tryed the embedded
Demo. In the Phyton module include file I red something that this
happens 
when size_t_size != sizeof_int.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> I don't agree. Syntax is significant for human readers, who are the vast
> majority of programmers.
> 
> Yes, people will get used to most syntax, eventually. But "used to"
> doesn't necessarily mean "can read it efficiently". I did a lot of FORTH
> coding in my youth, far more lines of code than Pascal, but Pascal was
> always easier to read than FORTH for me. Now, I can look at a page of
> Pascal code and it is still readable, but the FORTH... urgh.

Forth was always unreadable to me but I never did much.  I thought its
aficionados were silly.  Yes if you have a complicated math expression
in Lisp, you have to sit there for a moment rearranging it in infix in
your mind to figure out what it says.  The point is that such
expressions aren't all that common in typical Lisp code.

Anyway, you know this song?  I don't think it could have been written
for Python, which is what I mean about Lisp being primordial:

  http://www.songworm.com/db/songworm-parody/EternalFlame.html  words
  http://www.prometheus-music.com/audio/eternalflame.mp3audio

> But that isn't to say that the syntax of Lisp is for everybody. Far from
> it -- I'd be willing to bet that Lisp developers are a self-selected group
> of far above average intelligence. That would explain why so many of them
> seem to be so much more comfortable with higher-order functions than most
> other people -- even intelligent people. 

Nah, try Haskell for that.  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Timofei Shatrov]

On Sat, 09 Dec 2006 12:43:34 +0100, Bjoern Schliessmann
<[EMAIL PROTECTED]> tried to confuse everyone with
this message:

>samantha wrote:
>
>> What are you? A pointy haired boss?
>
>What are you? A 12 year old that has just learned to use Google
>Groups? 8)

Says a person with a 13-line sig.

-- 
|Don't believe this - you're not worthless  ,gr-.ru
|It's us against millions and we can't take them all... |  ue il   |
|But we can take them on!   | @ma  |
|   (A Wilhelm Scream - The Rip)|__|
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Automatic debugging of copy by reference errors?

[Niels L Ellegaard]

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.  As far
as I can see the garbage collector module would allow to do some of
this, but one would still have to edit the assignment operators of each
of the standard data structures:

http://docs.python.org/lib/module-gc.html

Anyway you are probably right that the end result would be a somewhat
crippled version of python


  Niels

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Timofei Shatrov]

On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
<[EMAIL PROTECTED]> tried to confuse everyone with this
message:

>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>
>> if Common Lisp didn't have CLOS, its object system, I could write my own
>> as a library and it would be just as powerful and just as easy to use as
>> the system Common Lisp already provides.  Stuff like this is impossible
>> in other languages.
>
>Dude. Turing Complete. Don't you Lisp developers know anything about
>computer science?

Here, you've basically shot yourself in the ass. Appealing to Turing
completeness when talking about programming language features is about the
dumbest thing you can make. In Turing sense, a program is simply a function that
takes an argument and returns a value. It doesn't say anything about how this
function was implemented. It could be Turing machine, lambda calculus, Markov
chains or whatever else. All these methods produce the same set of programs, but
that doesn't mean you could implement lambda in Turing machine for example.

Is is time for someone to read his computer science books again?

-- 
|Don't believe this - you're not worthless  ,gr-.ru
|It's us against millions and we can't take them all... |  ue il   |
|But we can take them on!   | @ma  |
|   (A Wilhelm Scream - The Rip)|__|
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Automatic debugging of copy by reference errors?

[Fredrik Lundh]

Niels L Ellegaard wrote:


> 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.  As far
> as I can see the garbage collector module would allow to do som

*all* objects in Python are referred to by "living" objects; those that 
don't are garbage, and are automatically destroyed sooner or later.

(maybe you've missed that namespaces are objects too?)



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Stefan Nobis]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

[Extensibility of syntax (via Lisp like macros)]
> In the real world, programmers aren't lone wolves stalking the
> programming landscape doing their own thing. Whether we're talking
> open source projects maintained by volunteers, or commercial
> software teams, standardized languages are a good thing. It is a
> good thing that not every hare-brained idea that some random
> programmer comes up with can be implemented as part of the core
> language.

Everything from functions over classes and class hierachies to macros
are just ways to create your own personal language, to create
abstractions.

That's the whole point of high level languages: Say it your
way. Create your (domain specific) vocabulary.

(By the way: You must really hate Guido for allowing operator
overloading in Python. It's exactly the same argument, nearly the same
wording you used, that others used against operator overloading. You
have to really love Java. :))

> It is a good thing that when Fred decides to stop contributing to an
> open source project (or leave the company), other people can read
> his code without having to learn his Uber-Special Custom Macro
> Extended Language.

You don't need macros for this kind of problem -- it's a really old
problem, independend of language. There are assembler, C, Fortran,
Java, Haskell, Lisp and many more hackers who write code, that's
really hard to understand for other people.

Heck, even in natural language there are many people who say or write
things others have really trouble to understand.

So what? Big class hierachies are always hard work to understand, even
the very best designs of mankind. There is much Python code out there,
that's really hard to understand. So Python is a bad language? No,
quite not.

So why do you think, Common Lisp or Macros are a bad thing? What's the
difference (from the perspective of understanding) between a function
foo and a macro bar? Both just transform their inputs. It's just
another form of abstraction and from time to time really quite
helpful.

-- 
Stefan.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Stefan Nobis]

Paul Rubin  writes:

> Python is more readable than Lisp because it stays readable even if
> you don't use it on a daily basis.

Girls, this is really bullshit!

None programming language is readable. I teach programming to complete
beginners and I tried some languages -- maybe some are a little bit
worse for the uneducated, but all languages are really unreadable.

Intuitive interfaces (GUI, languages,...) are an urban legend, pure
illusion. You have to do hard work and practice to understand them.

-- 
Stefan.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Stefan Nobis <[EMAIL PROTECTED]> writes:
> So why do you think, Common Lisp or Macros are a bad thing? What's the
> difference (from the perspective of understanding) between a function
> foo and a macro bar? Both just transform their inputs. It's just
> another form of abstraction and from time to time really quite
> helpful.

For a long time Scheme had no macros, and Scheme developers who were
exceedingly familiar with Common Lisp were nonetheless willing to get
by without them.  So I have to think macros aren't all THAT important.
Scheme did eventually get macros, but somewhat different from CL's.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Stefan Nobis <[EMAIL PROTECTED]> writes:
> Intuitive interfaces (GUI, languages,...) are an urban legend, pure
> illusion. You have to do hard work and practice to understand them.

Well if you write enough code in general, the principles stick with
you.  What I found with Perl was that after not using it for a while,
I completely forgot it.  I mean the principles were still the same,
but making any sense of the code depended on remembering a lot of
detail which had left me.  Python and C are not so much like that.
Lisp is somewhere in between.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote  :on '(09 Dec 2006 02:55:49 -0800))
(

 PR> "Alex Mizrahi" <[EMAIL PROTECTED]> writes:
 ??>> we can implement Scheme's call-with-current-continuation first :)
 ??>> it's relatively easy -- just a code walker that coverts everyting into
 ??>> CPS.

 PR> It's not enough to convert to CPS, you have to be able to actually
 PR> save the continuation when you switch to another one, so you can go
 PR> back to the first one later.  Maybe I'm missing something but I just
 PR> don't see how to do that in the Lisp execution model.

once you convert code to CPS, you can save continuation -- that would be a 
simple closure.
let's check how it works using CPS from ARNESI library.

(setq *cc* (with-call/cc (print 1) (let/cc cc cc) (print 3)))

that prints 1 and returns continuation.
when we call that contination:

(funcall *cc* nil)

it prints 3.

we can do a generator now:

(defun gen1 ()
  (let (state)
(setf state
   (lambda (ignored)
 (with-call/cc
  (loop for i upfrom 1
do (let/cc cc
 (setf state cc)
 i)
(lambda () (funcall state nil


(setq *gen* (gen1))

(funcall *gen*) => 1
(funcall *gen*) => 2
(funcall *gen*) => 3

then we can make a defgenerator macro so it will look like:

(defgenerator gen1 ()
(loop for i upfrom 1 do (yield i))

certainly yield is (let/cc cc (setf state cc) value)

 PR>   I guess you could write an interpreter in Lisp that simulates it all,
 PR> but it might as well be a Python interpreter ;-).

no, we can just transform code, and it can be then compiled or whatever.
there is only additional overhead (lambda and friends) for each call/cc. all 
"continuous" forms can be efficiently compiled.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity") 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Lars Rune Nøstdal]

On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano wrote:

> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
> 
>> if Common Lisp didn't have CLOS, its object system, I could write my own
>> as a library and it would be just as powerful and just as easy to use as
>> the system Common Lisp already provides.  Stuff like this is impossible
>> in other languages.
> 
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?
> 
> Anything any language can do is possible in any other language, if you are
> willing to write your own libraries.

*lol* Good luck with that attitude:
  http://redwing.hutman.net/~mreed/warriorshtm/troglodyte.htm

..or did you forget to add "in theory"; which is of course what everyone
already knows as they see their compilers do it every day.

-- 
Lars Rune Nøstdal
http://nostdal.org/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Blair P. Houghton]

Python doesn't annoyingly rip you out of the real world to code in it.

Anyone looking at a python script can get a sense of where it's going.

--Blair

-- 
http://mail.python.org/mailman/listinfo/python-list

py2exe Problem with cairo

[Michax]

Hi,

I have problem with my py2exe. When I want to run my compiled exe, then
i get
error information like that:

Trackback (most recent call last):
File "mysql_gui.py", line 2 in ?
File "gtk\__int__.pyc", line 12, in ?
File "gtk\_gtk.pyc", line 12, in ?
File "gtk\_gtk.pyc", line 10, in __load
ImportError: No module named cairo

I have similar problem with all compiled .exe using gtk library.

I want to add, that when I launch *.py file directly , everything works
great.

Detailed information :

System : Windows 2003 with SP1

Python 2.4.4

gtk-2.10.6-win32-1
gtk-dev-2.10.6-win32-1
py2exe-0.6.5.win32.py.2.4
pycairo-1.0.2-1.win32.py.2.4
pygtk-2.8.6-1.win32-py2.4
MySQL-python.exe-1.2.1_p2.win32-py2.4

And most important thing ,  I'm newbie :)

My source code http://www.moha.pl/mysql_gui.py

Thanks in advance for any suggestion
--
Michał Kuliński
Poland

-- 
http://mail.python.org/mailman/listinfo/python-list

py2exe Problem with cairo

[Michax]

Hi,

I have problem with my py2exe. When I want to run my compiled exe, then
i get
error information like that:

Trackback (most recent call last):
File "mysql_gui.py", line 2 in ?
File "gtk\__int__.pyc", line 12, in ?
File "gtk\_gtk.pyc", line 12, in ?
File "gtk\_gtk.pyc", line 10, in __load
ImportError: No module named cairo

I have similar problem with all compiled .exe using gtk library.

I want to add, that when I launch *.py file directly , everything works
great.

Detailed information :

System : Windows 2003 with SP1

Python 2.4.4

gtk-2.10.6-win32-1
gtk-dev-2.10.6-win32-1
py2exe-0.6.5.win32.py.2.4
pycairo-1.0.2-1.win32.py.2.4
pygtk-2.8.6-1.win32-py2.4
MySQL-python.exe-1.2.1_p2.win32-py2.4

And most important thing ,  I'm newbie :)

My source code http://www.moha.pl/mysql_gui.py

Thanks in advance for any suggestion
--
Michał Kuliński
Poland

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
> 
> 
>>if Common Lisp didn't have CLOS, its object system, I could write my own
>>as a library and it would be just as powerful and just as easy to use as
>>the system Common Lisp already provides.  Stuff like this is impossible
>>in other languages.
> 
> 
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?

We just know the Turing Complete thing cannot be used to duck language 
feature comparisons because the whole point of language comparison is 
"how much pain does each language spare me?", where a Turing machine is 
ranked as the ultimate in programming pain.

This might be because the whole point of a programming language is to 
spare us the pain of toggling switches on the back of an ENIAC.

> 
> Anything any language can do is possible in any other language,...

At what cost? 

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py2exe Problem with cairo

[Fredrik Lundh]

Michax wrote:
> Hi,
> 
> I have problem with my py2exe. When I want to run my compiled exe, then
> i get error information like that:
> 
> Trackback (most recent call last):
> File "mysql_gui.py", line 2 in ?
> File "gtk\__int__.pyc", line 12, in ?
> File "gtk\_gtk.pyc", line 12, in ?
> File "gtk\_gtk.pyc", line 10, in __load
> ImportError: No module named cairo
> 
> I have similar problem with all compiled .exe using gtk library.

seen this:

http://www.py2exe.org/index.cgi/Py2exeAndPyGTK

?



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 22:02:59 +0200, Alex Mizrahi wrote:
> 
> 
>>you have an expression 3 + 4 which yields 7.
>>you have an expression 4 * 1 which yields 4.
>>if you paste 3 + 4 in place of 1, you'll have 4 * 3 + 4 = 16. as we know, * 
>>is commutative, but 3 + 4 * 4 = 19.
>>so result depends on implicit operator precendence rules.
>>
>>in lisp, if you paste (+ 3 4) in (* 4 1), you'll have (* 4 (+ 3 4)), and it 
>>does not depend on order of operands, (* (+ 3 4) 4) yields same results. you 
>>do not have to remember precendence rules 
> 
> 
> Speaking as somebody who programmed in FORTH for a while, that doesn't
> impress me much. Prefix/postfix notation is, generally speaking, more of a
> pain in the rear end than it is worth, even if it saves you a tiny bit of
> thought when pasting code.
> 
> Except, of course, it doesn't really save you any thought. You can't just
> expect to paste an expression randomly into another expression and have it
> do the right thing.

Tell that to the unlimited number of monkeys I have over hear generating 
my next application. You might also read what I wrote earlier in this 
thread about how I leveraged the parens thing to edit code in logical 
chunks instead of chunks of text. If you think about it, that is exactly 
how code should be edited.

But I am fascinated: Python text can be edited randomly because it uses 
infix? Or did you just throw in randomly because your point sounded so 
weak without it? :)

> Oh, it will compile all right. But it won't do the
> right thing! Since you -- not the compiler -- have to understand the
> semantics of what you are pasting where, and paste the right expression
> into the right place, the effort saved by not using infix notation is less
> than the effort needed to mentally translate between prefix and infix.

Has it ever occurred to you that you might be the one translating? 
Because you are, you just do not know it. The only time I translate is 
when I have to express a multi-operator math formula in Lisp:

(eql y (+ (* m (expt x 2)) b))

I threw an exponent into the slope-intercept form of a line for the heck 
of it. Gotta tell you, I do not have to code a lot of math formulas in 
Lisp, and I would definitely download and infix-eating macro if I did.

Aside from that, you are the one translating. Prefix is terribly natural 
to the mind. Think about it. Add it all up. Add the tax and price and 
tip. Those are imperative, this one functional: the sum of the parts. 
The only time one hears infix in speech is when one is reading math 
notation. So... put two and two together.

> 
> If you are one of those people who actually think in prefix notation, then
> I raise my hat to you while backing away slowly.

Be careful backing away from yourself. :) I remember talking to a Welsh 
chap who had experienced the transition to a decimal system for money 
from the good old days of shillings, etc. He said he still had to 
translate pennies to shillings, even though the decimal system was less 
ornate. What mattered was the habit, not the clarity of representation.

The good news is in my earlier point: you already are using prefix. Even 
in programming. What does a functionall look like? fn(p1,p2,p3) Lisp 
just moved the left parenthesis in front of the fn so the logical chunk 
(function+parameters) is also a textual chunk neatly packaged and 
editable between matching parens.

> 
> (And actually, I'll give you one point: I've been hitting my head against
> a brick wall over a particular problem, and I think your email just gave
> me a clue how to solve it. Sometimes prefix/postfix notation is the right
> tool for the job. See, I can learn from Lisp.)

I think that was A Message From God(tm).

:)

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py2exe Problem with cairo

[Michax]

> seen this:
>
> http://www.py2exe.org/index.cgi/Py2exeAndPyGTK

Thanks ,I will check this one . 

Sorry for double post.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Driver selection

[Stuart D. Gathman]

On Fri, 08 Dec 2006 21:35:41 -0800, Gabriel Genellina wrote:

> On 9 dic, 00:53, "Stuart D. Gathman" <[EMAIL PROTECTED]> wrote:

>> Or you can modify the source to "from drivermodule import DNSLookup".
>>
>> What is the friendliest way to make this configurable?  Currently, users
>> are modifying the source to supply the desired driver.  Yuck.  I would
>> like to supply several drivers, and have a simple way to select one at
>> installation or run time.
> 
> You can store the user's choice in a configuration file (like the ones
> supported by ConfigParser).
> Then you can put all the logic to select and import the right function
> in a separate module, and export the DNSLookup name; make all the other
> parts of the application say "from mymodule import DNSLookup"

pyspf is a library, not an application.  It would be nasty to make it have
a config file.  We already have "from pydns_driver import DNSLookup" in
the pyspf module.  If only users could import *for* a module from
*outside* the module.  I suppose you can do something like this:

app.py:

import spf
# select dnspython driver for spf module
from spf.dnspython_driver import DNSLookup
spf.DNSLookup = DNSLookup
del DNSLookup

...

That is ugly.  I'm looking for better ideas.  Is there a clean way to make
a setdriver function?  Used like this, say:

app.py:

import spf
spf.set_driver('dnspython')
...

Can a function replace itself?  For instance, in spf.py, could DNSLookup
do this to provide a default:

def set_driver(d):
  if d == 'pydns':
from pydns_driver import DNSLookup
  elif d == 'dnspython':
from dnspython_driver import DNSLookup
  else: raise Exception('Unknown DNS driver')

def DNSLookup(name,t):
  from pydns_driver import DNSLookup
  return DNSLookup(name,t)

-- 
  Stuart D. Gathman <[EMAIL PROTECTED]>
Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:
> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
> 
> 
>>if Common Lisp didn't have CLOS, its object system, I could write my own
>>as a library and it would be just as powerful and just as easy to use as
>>the system Common Lisp already provides.  Stuff like this is impossible
>>in other languages.
> 
> 
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?
> 
> Anything any language can do is possible in any other language, if you are
> willing to write your own libraries.

I do not think you know what are macros. You are talking about 
functionality, macros are about the syntax. To achieve what Lisp 
developers do with macros you would need to write a preprocessor (and 
indeed this has been done when the need was great enough) to run thru 
the code expanding all the uses of the preprocessor language. But then 
your edit-run cycle is broken unless your IDE will let you specify a 
preprocessor and take care of seamlessly running it, but then what do 
you debug? And then you cannot just toss off a macro, it becomes an 
exercise in compiler development and now you have dozens of 
preprocessors running on each cycle. Ew.

> And debug them. Let's not forget the
> debugging and testing, unless you'd like us to believe that Lisp code
> never contains bugs. Lisp developers so often gloss over that: "Oh,
> feature X is *easy*, I could write it in a couple of macros. Two or three.
> Maybe thirty. Or forty, max. And they would work the right way first time.

Do you really talk to a lot of Lisp developers, or were you making that 
up? :)

Of course implementing an object system is a big job. Your fantasy about 
Lisp programmers misses the point to which you respond: after they had 
done all the work to implement an object system, they were able to make 
it look like Lisp had always had CLOS, without changing the compiler.

Keep those fat pitches coming. :)

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() and PEP 3000

[Colin J. Williams]

Giovanni Bajo wrote:
> Thomas Guettler wrote:
> 
>> I have read the FAQ to the len function:
>> http://www.python.org/doc/faq/general/#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list
> 
> Outdated. You want to read the new FAQ, here:
> http://effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm

Why not replace the __len__ method with a len property for strings, 
lists, tuples, dictionaries etc.  __len__ is not very special and the 
property len eliminates the redundant parentheses.

Colin W.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[David Golden]

Paul Rubin wrote:
 
> Forth was always unreadable to me but I never did much.  I thought its
> aficionados were silly.  Yes if you have a complicated math expression
> in Lisp, you have to sit there for a moment rearranging it in infix in
> your mind to figure out what it says.  The point is that such
> expressions aren't all that common in typical Lisp code.
> 


I find Lisp, Forth and classic funny-symbol APL relatively readable
(well, once you've learned the funny symbols in the APL case) That
spans prefix/postfix/infix... The commonality is simple evaluation
order, no damn precedence rules.  I can _cope_ with precedence rules,
I'm not a moron, but I prefer languages that don't make heavy use of
them. Well, more accurately, sources that don't, but most coders in
communities of languages-with-lots-of-precedence-rules consider
reliance on those precedence rules in source code idiomatic.  And
precedence rules, once you get beyond a few (sometimes rather
misleading) similarities to the ones that most people are made to learn
early on for arithmetic notation, can vary a lot from computer language
to computer language.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Automatic debugging of copy by reference errors?

[Stuart D. Gathman]

On Sat, 09 Dec 2006 05:58:22 -0800, Niels L Ellegaard wrote:

> 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.  As far
> as I can see the garbage collector module would allow to do some of
> this, but one would still have to edit the assignment operators of each
> of the standard data structures:

I think what you want is a namespace that requires each object to have
exactly one reference - the namespace.  Of course, additional references
will be created during evaluation of expressions.  So the best you can do
is provide a function that checks reference counts for a namespace when
called, and warns about objects with multiple references.  If that could
be called for every statement (i.e. not during expression evaluation -
something like C language "sequence points"), it would probably catch the
type of error you are looking for. Checking such a thing efficiently would
require deep changes to the interpreter.

The better approach is to revel in the ease with which data can be
referenced rather than copied.  I'm not sure it's worth turning python
into fortran - even for selected namespaces.

-- 
  Stuart D. Gathman <[EMAIL PROTECTED]>
Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[hg]

[EMAIL PROTECTED] wrote:

> Okay, since everyone ignored the FAQ, I guess I can too...
> 
> Mark Tarver wrote:
>> How do you compare Python to Lisp?  What specific advantages do you
>> think that one has over the other?
> 
> (Common) Lisp is the only industrial strength language with both pure
> compositionality and a real compiler. What Python has is stupid slogans
> ("It fits your brain." "Only one way to do things.") and an infinite
> community of flies that, for some inexplicable reason, believe these
> stupid slogns. These flies are, however, quite useful because they
> produce infinite numbers of random libraries, some of which end up
> being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
> is rapidly replacing Perl, and Ruby is simultaneously and even more
> rapidly replacing Python. Each is closer to Lisp than the last; the
> world is returning to Lisp and is dragging the flies with it.
> Eventually the flies will descend upon Lisp itself and will bring with
> them their infinite number of random libraries, and then things will be
> where they should have been 20 years ago, but got sidetracked by Tcl
> and other line noise.

p !

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:
> On Sat, 09 Dec 2006 02:29:56 -0500, Ken Tilton wrote:
> 
> 
>>
>>David Lees wrote:
> 
> 
>>Those raving about 
>>Lisp are quite accomplished at all those other languages, and know about 
>>  what they are talking. 
> 
> 
> Such a sweeping generalization. Every person who raves about Lisp is also
> accomplished with other languages. Yeah, right. I believe you, even if
> millions wouldn't.

Ah, but that is because you are not a careful thinker, you just like 
sounding off on Usenet. Me, too!

Think, Steve, think: do you think we pay the rent with /Lisp/ jobs?!

If logic does not work for you, try this:

 http://wiki.alu.org/RtL_Highlight_Film

Behind each sound bite is a full survey response, one question being 
"what other languages do you use?".


>>I doubt the Pythonistas weighing in on this 
>>thread ever got far at all with Lisp, so... should they really be 
>>offering comparative analysis?
> 
> 
> I hit my hand with a hammer once. 

Cool, first you use the lame Turing Completeness thing, now you are 
arguing by analogy, which does not work because now we have to argue 
about how well the analogue maps onto the topic.

When I switched Lisps after several years of Lisp I also had to switch 
IDEs (not using Emacs+ILisp). I hated the new IDE. I also told myself to 
wait thirty days before worrying about it, since obviously it might just 
be a matter of habit. Now when I port things back to the first Lisp I 
hate that IDE (except I know a couple of weeks would turn it around).

Now it may be distressing to you that I am talking about something 
closer to programming languages than is hammering ones hand, and for 
that I apologize in advance. :)

I didn't keep going until I was an
> expert in hitting-own-hand-with-hammer before deciding that hitting my
> hand with a hammer was not for me. Did I do the wrong thing? Should I have
> kept going until I was an expect at it?
> 
> (Of course, writing Lisp isn't precisely like hitting one's hand with a
> hammer. With the hammer, the endorphins kick in eventually, and it can
> become quite pleasant...)
> 
> 
> 
>>> Personally, I never like Lisp syntax; 
>>>Clearly some people, some fanatic judging by this thread :) think easily 
>>>in prefix.  I am not one of them. 
>>
>>Yeah, you are, you just did not use it heads down for a month.
> 
> 
> The sheer arrogance of this claim is astounding.
> 
> Actually, this is comp.lang.lisp. It isn't astounding at all.

Exactly, and Usenet. Not the Supreme Court. We can speak casually. We 
can also speak cordially. 

> 
> I don't know, maybe lisp coders actually are more intelligent than
> ordinary mortals, 

No, it's the Lisp that makes them so effective. I was joking in my 
original remark. But not about Lisp programmers being better looking. :)

> but it has been my experience that they have absolutely
> no grasp whatsoever of the way most (many? some?) people think. And I'm
> not talking about can't-walk-and-think-at-the-same-time people either, I'm
> talking about bright, intelligent people who, nevertheless, don't agree
> with lisp coders.

As you will soon realize because you are such an open, 
intellectually-honest person and will do the reading I recommended, most 
of us came to Lisp late in our programming careers, having used and 
excelled at (in my case) Apple Integer Basic, Microsoft Basic, 6502 
Assembler, COBOL, any DEC Basics, C, Logo, and now Lisp (chosen over the 
new C++ because the latter seemed like evry bit the horror it turned out 
to be). I have done enough Python to appreciate the cleanliness of the 
code and its power, and enough Java... well, after Lisp it is impossible 
to find anything in some other language that would tempt one to work 
much in it.

My point is that we grasp what you think because we /are/ you, we have 
worked alongside you, and we are very good at your language. And we use 
Lisp and gloat about it and piss everyone off with our smugness. It 
can't be helped--Lisp is that good.

>>The way 
>>to tell if you spent enough time on Lisp is to look at Lisp code. If you 
>>see any parentheses, you have not spent enough time. They disappear in a 
>>month.
> 
> 
> If the parentheses are that meaningless, why do you need them?

Meaningless? Who said that? Did you say that? Someone said that. :)

I said they disappear. I am not looking at parens, I am looking at the 
code structure, as manifested by (you'll like this) the indentation, the 
indentation provided automatically when I kerplunk control-shift-P (I 
think, my fingers know).

You like analogies. When i tried on my first glasses I said "I can see 
the frames!". the glasses guy said, "That is because you are looking for 
them." Something like that. With the editor handling the parens 90% of 
the time, I do not have to thnk about or look for them.

btw, change all the ()s to []s and I /do/ see them. Possibly they would 
go away with time, but I have a hunch that []s might not go away, two 
cornery or something

Re: merits of Lisp vs Python

[Ken Tilton]

Alex Mizrahi wrote:
> (message (Hello 'Ken)
> (you :wrote  :on '(Sat, 09 Dec 2006 04:26:02 -0500))
> (
> 
>  KT> keep the Pythonistas from straying. But you have an excuse: Lispniks
>  KT> always /talk/ about macros giving us the ability to create a DSL. But
>  KT> no one does. :)
> 
> certainly there's no reason to make a new DSL each day, but sometimes they 
> are good.
> i've recently posted an example of DSL to do queries to RDF data base -- i 
> find it's very helpful.

That is different. Your very objective /was/ a language. Naturally, you 
created one. I am talking about PGs suggestion that the best way to 
solve a problem is to create a language for that problem and then use 
it. What I think happens more often is the other thing Graham said: 
building up CL to be a better language for the problem. So the language 
is still predominantly and visibly CL, and here and there are chunks of 
macrology hiding a crapload of boilerplate.

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Bjoern Schliessmann wrote:
> Ken Tilton wrote:
> 
> 
>>Note also that after any amount of dicing I simply hit a magic key
>>combo and the editor reindents everything. In a sense, Lisp is the
>>language that handles indentation best.
> 
> 
> Erm ... because there's an editor for it that indents automatically?
> Or did I miss the point?

I think so, but you did not say enough for me to understand /your/ 
point. It sounded like you were using sarcasm to point out to me exactly 
what I had just said.

We might want to punt on this. :)

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Steven D'Aprano]

On Sat, 09 Dec 2006 14:00:10 +, Timofei Shatrov wrote:

> On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
> <[EMAIL PROTECTED]> tried to confuse everyone with this
> message:
> 
>>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>>
>>> if Common Lisp didn't have CLOS, its object system, I could write my own
>>> as a library and it would be just as powerful and just as easy to use as
>>> the system Common Lisp already provides.  Stuff like this is impossible
>>> in other languages.
>>
>>Dude. Turing Complete. Don't you Lisp developers know anything about
>>computer science?
> 
> Here, you've basically shot yourself in the ass. Appealing to Turing
> completeness when talking about programming language features is about the
> dumbest thing you can make. In Turing sense, a program is simply a function 
> that
> takes an argument and returns a value. It doesn't say anything about how this
> function was implemented. It could be Turing machine, lambda calculus, Markov
> chains or whatever else. All these methods produce the same set of programs, 
> but
> that doesn't mean you could implement lambda in Turing machine for example.

What exactly are you trying to say here? Is this a comment about the
relative practicality of writing code in a Turing machine versus
high-level languages, or are you implying that lambda calculus is "bigger"
than any Turing-complete language?

If you're talking about practicality, then of course you're correct, not
all languages are equally expressive. Some languages are not expressive
enough. Some languages are too expressive. No language is optimal for all
people for all tasks.


> Is is time for someone to read his computer science books again?

Probably. Would you like to borrow mine?

Look, all snarkiness aside, it just isn't true that "stuff like this is
impossible in other languages". If Wolfram Fenske had said "stuff like
this isn't easy in many other languages" he would have been right. And if
he had said "and stuff like this carries risks as well as benefits" he
would have come across as less of a language fanatic.

One of the risks with Python is the ease with which you can modify the
built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
list from 2, 3, and 4, because the built-in list could be redefined.
(In practice, that's not often a real problem, because experienced
Python developers simply learn not to needlessly or confusingly shadow
built-ins. It's not the best system, but it works well enough in
practice.) But at least the basic syntax and keywords of the language are
known to be constant. 

With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
"Oh yes, macros give you great power, and with great power comes great
responsibility. Be careful." then, no doubt, we'd take you guys more
seriously. But we don't hear that -- we hear Lispers going on and on about
how great it is that they can easily redefine every corner of the
language. Do you blame people for *believing them* and imagining that
reading Lisp code is like following some ghostly will-o-the-wisp across a
swamp, where nothing is what it seems and the landscape is forever
shifting?

Now, if you want to tell me that, despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions, then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Wade Humeniuk]

tmh wrote:
> This is from the perspective of an aerospace engineer who passed
> through python several years ago on the way to lisp. Futhermore, this
> is a 2 glass of wine response.
> 


Thanks for the comments.  I think it is great that you took a "harder
and less travelled way".  It may be that some people get to a point
where they are either tired or think they know everything. Or.. their
brains just harden up and they become old dogs.

There seems to be a recurring theme to many of the posts in this thread
about syntax and readability.  Some of it is "If I can not instantly
read and understand what the code is doing then something is wrong
with it".  As if holding oneself as the standard of what is good and
correct is the only way.  If you see something and it
is not readily apparent what it is, then that is a sign than something
interesting may be going on.  I got into Lisp because when I
looked at it, I did not understand.  I did not think WTF! but thought
that something was  going on and maybe I was cheating myself if I
brushed it aside.

There is also some disdain expressed about badly written programs.
Why?  They may be that way for some very good reasons, it is folly
to think that programs have to be simple, obvious and elegant.  I find
interesting that a programmer got out their comfort zone and attempted
something.  Its better than the ones with the big egos who play it safe
so they do not appear to be a fool.

Wade
-- 
http://mail.python.org/mailman/listinfo/python-list

Error: unbound method in Tkinter class

[Kevin Walzer]

I am trying to structure a Tkinter application with classes instead of
just with simple functions, but I'm not sure how to call methods from my
main class.

My main class is packetstreamApp(). Within that class I call various
methods, including drawGUI() and authorizeDump(). My problem comes when
I try to call authorizeDump from the Tkinter menu. Here is the code that
calls authorizeDump():

self.packetmenu.add_command(label="Start Network Monitor",
command=packetstreamApp.authorizeDump())

Here is the code for authorizeDump():

 def authorizeDump(self):
##do stuff here

And here is the error message that comes when I try to call authorizeDump():

Traceback (most recent call last):
  File "/Users/kevin/Programming/packetstream/packetstream-classes.py",
line 257, in 
app = packetstreamApp()
  File "/Users/kevin/Programming/packetstream/packetstream-classes.py",
line 19, in __init__
self.drawGUI()
  File "/Users/kevin/Programming/packetstream/packetstream-classes.py",
line 49, in drawGUI
self.packetmenu.add_command(label="Start Network Monitor",
command=packetstreamApp.authorizeDump())
TypeError: unbound method authorizeDump() must be called with
packetstreamApp instance as first argument (got nothing instead)

I don't know how to interpret this error message, and so can't implement
a fix. Can anyone shed light on what I'm doing wrong?

Thanks.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Python Programmers...

[Kamyar Inanloo]

Salam

If you are a Python programmer, you are fond of python, or you want
to learn and start using Python, please join the new group:

Iranian Python Programmers

http://groups.yahoo.com/group/iranianpythonprogrammers

thanks

-- 
http://mail.python.org/mailman/listinfo/python-list

finalization signal for an object with ZODB involved?

[robert]

I have (large) disk files connected with ZODB objects and want the disk files 
to be removed when the Python/ZODB object all finalizes. 
Is it possible to get a kind of reliable __del__ signal for that?


Robert
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Error: unbound method in Tkinter class

[Peter Otten]

Kevin Walzer wrote:

> I am trying to structure a Tkinter application with classes instead of
> just with simple functions, but I'm not sure how to call methods from my
> main class.
> 
> My main class is packetstreamApp(). Within that class I call various
> methods, including drawGUI() and authorizeDump(). My problem comes when
> I try to call authorizeDump from the Tkinter menu. Here is the code that
> calls authorizeDump():
> 
> self.packetmenu.add_command(label="Start Network Monitor",
> command=packetstreamApp.authorizeDump())

If that code is inside a method of packetstreamApp:

self.packetmenu.add_command(label="...", command=self.authorizeDump)

i. e. you have to pass a bound method (a method that knows about "its"
instance) and you must not call authorizeDump here (no trailing '()').

Of course I'm only guessing...

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:

> 
> But Lisp's syntax is so unlike most written natural languages that that it
> is a whole different story. Yes, the human brain is amazingly flexible,
> and people can learn extremely complex syntax and grammars (especially if
> they start young enough) so I'm not surprised that there are thousands,
> maybe tens or even hundreds of thousands  of Lisp developers who find the
> language perfectly readable.
> 
> But that isn't to say that the syntax of Lisp is for everybody.

yeah, I think it is. Folks don't vary that much. If every Lisp 
programmer also reports parens disappearing at about thirty days, any 
given non-Lispnik can pretty much bet on the same experience.

And since no one can produce a witness who worked fulltime on Lisp for 
thirty days and gave up on it because it was a great language but they 
could not handle the syntax, or a witness who stayed with Lisp because 
it is a great language even though to this day they have trouble reading 
the synatx...

> Far from
> it -- I'd be willing to bet that Lisp developers are a self-selected group
> of far above average intelligence. 

I think the early adopter is distinguished not so much by greater 
intelligence as by restlessness and rebelliousness and a little lunacy. 
We lack the knack of happiness. Many of the stories on the RtL reveal 
folks who sought A Better Way after mastering other languages. And by 
Better Way, sorry, we mean "why do I have to forever worry about the 
damn paper tape on this Turing machine!". We do not really like 
programming, we like thinking about problems and using a computer to 
solve them.

> That would explain why so many of them
> seem to be so much more comfortable with higher-order functions than most
> other people -- even intelligent people. 
> 
> (Looking back, I'm embarrassed about my first reaction to factory
> functions all those years ago. Hiss hiss spit. But even with added
> familiarity, there comes a time where one has to question the benefit of
> sufficiently high-order functions. If you are writing a factory function
> that returns factory functions that return factory functions that return
> the functions that you needed in the first place, chances are you really
> need to rethink your tactics.)
> 
> If I'm right, then maybe Lisp is "better" in some absolute sense, *for
> those who can use it*. For those who can't, it isn't just a matter of
> (say) the syntax being hard to read because it is unfamiliar, but it
> being objectively harder to use.
> 
> An interesting study would be to track people's eyeballs as they read
> code, ...

I spend about 90% of my time thinking and writing code, and read it only 
to understand how something works or why it broke. And then I am looking 
at parentheses no more than you are looking at the lines of resolution 
on a TV when watching Baywatch. I am looking at a mechanism and how it 
works.

> ...or look at how much oxygen their brain uses. Do Lisp coders do more
> work to read Lisp than Python coders do to read Python? I suspect they do,
> but successful Lisp coders don't notice. 

My suspicion goes the other way, and is based not on punctuation, rather 
on imperative vs functional. In Lisp every form returns a value, so I do 
not have all these local variables around that, in the strecth of an 
interesting function, take on a stream of values and transformations to 
finally come up with some result, meaning to understand code I have to 
jump back and forth thru the code to see the lineage of a value and 
figure out its net semantics. Too much like work.

> Everybody else does, and
> gravitate to languages which might not be "better" but are "good enough".

No, they gravitated to a language that was closer to what they already 
knew, C or Java (which also mimicked C to pick up those users). Later 
charms of Python were a great community and library support. Lisp simply 
does not have the latter, one is forever rolling one's own bindings to C 
libs.

> (If my post leads to any Lisp developer's already swollen head exploding
> from pride, my job here is done *wink*)

They can't get any bigger. :)

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[[EMAIL PROTECTED]]

Carl Banks wrote:
> [EMAIL PROTECTED] wrote:
> > Okay, since everyone ignored the FAQ, I guess I can too...
> [snip]
> > What Python has is stupid slogans
> > ("It fits your brain." "Only one way to do things.") and an infinite
> > community of flies that, for some inexplicable reason, believe these
> > stupid slogns.
>
> IOW, you posted the FAQ so you could appear to have highest moral
> ground, then you ignore your own advice and promptly head to the very
> lowest ground with ad hominem insults.

You're right, in part: My implicitly linking Python's pros or cons with
its stupid marketing hype is, I think, an ad hominem argument. But I
don't see a moral issue here; the purpose of posting the FAQ was merely
to try to stop the fight. It failed.

Regardless, there was some content in my post which you have not
addressed:

To wit:

1. Lisp is the only industrial strength language with pure
compositionality, and that this makes it suprior to Python. We don't
have to debate this because it's being debated elsewhere in this
thread.

2. Ruby, which is closer to Lisp than Python, is beginning to eat
Python's lunch. We don't have to debate this either because George has
kindly gave support to it through posting a survey that made this point
quite nicely; Thanks, George! :-)

BTW, for the record, I don't have anything particularly against Python
aside from its stupid marketing hype and a bit of jealousy over those
flies building libraries which I wish we had in Lisp. I've made the
choice uncountable times between PERL, Python, and Tcl when I didn't
have Lisp as an option, and I have always chosen Python in these cases,
even though I can program in any of these. (Although I'm probably going
to start using Ruby instead of Python in these cases, but I'm not
really expert in it yet.)

(Actually, in many cases I can get away with Emacs keyboard macros
where others would program in PERL or Python, although not always.)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Ken Tilton]

Steven D'Aprano wrote:
>  Some languages are too expressive.

:)

> Look, all snarkiness aside, it just isn't true that "stuff like this is
> impossible in other languages". If Wolfram Fenske had said "stuff like
> this isn't easy in many other languages" he would have been right.

Remember, Lisp macros are like being able to run a preprocessor on an 
ad-hoc basis. Without Lisp compilers (er, should I say the Lisp 
"reader"?) understanding macros and macro functions, not even Lisp could 
transform source code this way.

We won't have an intelligent discussion on macros until this gets better 
understood. Macros are not about what one can do at run-time, they are 
about what happens at compile time. If your compiler/preprocessor/IDE 
are not going to cooperate, then embedding a preprocessed language in 
Python is so hard as to be unfeasible.

I also would not quibble over "impossible" vs. "incredibly hard". The 
bottom line is that at a pretty low level hard becomes "aint gonna happen".

> And if
> he had said "and stuff like this carries risks as well as benefits" he
> would have come across as less of a language fanatic.
> 
> One of the risks with Python is the ease with which you can modify the
> built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
> list from 2, 3, and 4, because the built-in list could be redefined.
> (In practice, that's not often a real problem, because experienced
> Python developers simply learn not to needlessly or confusingly shadow
> built-ins.

Well, duuh. This the Great Strawman, that Lisp programmers (a) love 
having a powerful language (b) so they can produce unreadable code. This 
nonsense is an implicit concession that you have no point at all.

> It's not the best system, but it works well enough in
> practice.) But at least the basic syntax and keywords of the language are
> known to be constant. 
> 
> With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful." 

I have to admit you are probably still catching up on what I have 
written today.

> then, no doubt, we'd take you guys more
> seriously. But we don't hear that -- we hear Lispers going on and on about
> how great it is that they can easily redefine every corner of the
> language.

You have this tendency as your paragraphs grow to get sillier and 
sillier and make up more and more hobgoblin crap, I suppose as you sense 
the weakness of your case. Can you point to where someone said that? No, 
of course not. Get a grip, will you, this could be a useful cultural 
exchange, but not with your hysterics.

> why do you need
> macros then if you are just using them as functions? Why not use functions?

Hint: famous Lisp style rule: never use a macro where a function will do.

Not sure it is worth wasting more time on you at this point or I would 
offer examples. Could you calm down a bit and stop making things up?

ken

-- 
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[[EMAIL PROTECTED]]

Thankfully folks (including me) seem to be starting to cool off, so
perhaps we can disucss this in somewhat calmer register. I think that
Kenny unintentionally sold macros short by implying that they are
merely window-dressing for boilerplate, and you seem to have a
misunderstanding of macros, which I won't go into too deeply but to
point out that the purpose of macros is not the same as functions.
Functions create new ...uuuhh... functionality, whereas macros create
new programming constructs. These work in very different conceptual
parts of the programming landscape: The former addresses the way that
the functions offered by the programming language fit the parts of the
problem whereas the latter addresses the way that the programming
language itself fits the problem.

So, whereas I will grant that:

> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful."

I don't think that any experience Lisp programming would grant that:

> despite all the talk, Lisp coders don't
> actually create new syntax or mini-languages all that often, that they
> just use macros as functions

So, to your point:

> then the question becomes: why do you need
> macros then if you are just using them as functions? Why not use functions?

No, they are not functions. We need them because although it is usually
possible to make a given programming language's functionally fit any
given problem, it is often much more convenient, and much cleaner, both
practiaclly and conceptually, to make the programming langauge fit the
problem too.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: dict.has_key(x) versus 'x in dict'

[skip]

> "Hendrik" == Hendrik van Rooyen <[EMAIL PROTECTED]> writes:

Hendrik> <[EMAIL PROTECTED]> wrote:
Hendrik> - as long as it works, and is fast enough, its not broken, so
Hendrik> don't fix it...

>> That's the rub.  It wasn't fast enough.  I only realized that had
>> been a problem once I fixed it though.

Hendrik> LOL - this is kind of weird - it was working, nobody
Hendrik> complained, you fiddled with it to make it faster, (just
Hendrik> because you could, not because you had to, or were asked to),
Hendrik> it became faster, and then, suddenly, retrospectively, it
Hendrik> became a problem 

No, I think you misunderstand.  I was poking around in that function for
other reasons, saw the "k in d.keys()" and realized that the wrong way to
write it.  Rewrote it and noticed the performance increase.  What's so weird
about that?

Skip
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Interacting with keyboard LEDs

[Chris Lasher]

Jonathan Curran wrote:
> Spur of the moment answer: call setleds program from within your program
>
> better answer (fox X11):
> http://python-xlib.sourceforge.net/doc/html/python-xlib_16.html
>
> Take a look at get_keyboard_control() and change_keyboard_control(). As far as
> knowing how to properly invoke them, I have no idea, maybe you could google
> for examples or take a look at the setleds source?
>
> - Jonathan

Thanks for your reply, Jonathan. The difficulty with setleds is that
only works from a virtual console (e.g., tty, CTRL+ALT+F1 through F6,
etc.), not from a terminal emulator inside X (e.g., pts, Xterm, Gnome
Terminal, Konsole, etc.), which is the environment where I'd like to
interact with the LEDs. The xlib package looks promising, though. One
thing I don't understand is the 32-bit mask. How does this represent
the LED states? I profess my ignorance.

Thanks!
Chris

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[mystilleef]

Mark Tarver wrote:
> How do you compare Python to Lisp?  What specific advantages do you
> think that one has over the other?
>
> Note I'm not a Python person and I have no axes to grind here.  This is
> just a question for my general education.
>
> Mark

Advantages of Python:

1). More and better mature standard libraries (Languages don't matter,
libraries do).
2). Multiple programming paradigms (including functional style
programming see itertools, functools, operator modules (lambda, map,
filter, reduce, sum etc builtins), higher order functions, list
comprehension, blah, blah)
3). Better OO implementation. (I used to hate OO until I started using
Python)
4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
said. Bindings for almost any lib worth using, at least on *nix)
5). Clearer syntax.
6). Better namespace management. (nobody ever talks about this, but
Python seems to be one of the few languages that gets symbol management
right from a users perspective)
7). Easier packaging and distribution system.
8). Ubiquity! Python is everywhere. Lisp, bleh.
9). Relatively good docs (PHP has better).
10). Fewer perceived community assholes. Large community.
11). Less fragmentation.

Advantages of Lisp:

Learning a functional language can improve your programming range and
depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
when there's mind bending Haskell. I'd go as far as saying I believe
Haskell has a better fate than Lisp.

On Lisp Macros:

I think they are overrated, and in general cause more harm than good.
It's the reason I find Lisp-like programs difficult to grok, maintain
and extend. Cos every smart ass wants to needlessly write his own mini
language to the point of absolute obfuscation. Naturally, I'm supposed
to be awed by his mischievous cleverness.

Conclusion:

The semantics or features of a language is almost irrelevant today.
Developers want to put the lego pieces together, they don't want to
make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
was popular in the 70s, but it's boring and expensive today. Today,
when a developer needs to solve a problem, the question they ask is,
"Is there a library for that?". If the answer is no, they a more likely
to switch to a language that provides a library that solves their
problem. The challenge for developers today is software architecture,
robustness and scalability, not language purity or semantics. The Lisp,
and to an extent Haskell, community will never ever ever grok this.
They'll continue to wonder why an "inferior" language like Python keeps
getting popular. It will always escape them that it might be because
Python is actually easier to use for most people to write "real world"
applications. It has good usability.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Timofei Shatrov]

On Sun, 10 Dec 2006 04:24:43 +1100, Steven D'Aprano
<[EMAIL PROTECTED]> tried to confuse everyone with this
message:

>On Sat, 09 Dec 2006 14:00:10 +, Timofei Shatrov wrote:
>
>> On Sat, 09 Dec 2006 20:36:02 +1100, Steven D'Aprano
>> <[EMAIL PROTECTED]> tried to confuse everyone with this
>> message:
>> 
>>>On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>>>
 if Common Lisp didn't have CLOS, its object system, I could write my own
 as a library and it would be just as powerful and just as easy to use as
 the system Common Lisp already provides.  Stuff like this is impossible
 in other languages.
>>>
>>>Dude. Turing Complete. Don't you Lisp developers know anything about
>>>computer science?
>> 
>> Here, you've basically shot yourself in the ass. Appealing to Turing
>> completeness when talking about programming language features is about the
>> dumbest thing you can make. In Turing sense, a program is simply a function 
>> that
>> takes an argument and returns a value. It doesn't say anything about how this
>> function was implemented. It could be Turing machine, lambda calculus, Markov
>> chains or whatever else. All these methods produce the same set of programs, 
>> but
>> that doesn't mean you could implement lambda in Turing machine for example.
>
>What exactly are you trying to say here? Is this a comment about the
>relative practicality of writing code in a Turing machine versus
>high-level languages, or are you implying that lambda calculus is "bigger"
>than any Turing-complete language?
>

I'm trying to say that the ability to read is a very useful skill in a Usenet
discussion. Your posts, like the two quoted above, seem to indicate the lack of
it.

-- 
|Don't believe this - you're not worthless  ,gr-.ru
|It's us against millions and we can't take them all... |  ue il   |
|But we can take them on!   | @ma  |
|   (A Wilhelm Scream - The Rip)|__|
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[tayssir . john]

Steven D'Aprano wrote:
> With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful." then, no doubt, we'd take you guys more
> seriously.

Who are "we"? I was a heavy Python and Java user before being aware of
Lisp. I knew even then that there was something wrong with the
programming world, because there were too many programming patterns I
could not automate away within the language. It's ironic to be a
programmer who can't automate her own work.

I told people that programming was just "glorified accounting." I
shrugged when reading about how complexity was exploding, because that
was the language designers' job to manage it.

Upon hearing of Lisp, I taught it to myself alone, because it was
important. Despite all the FUD, despite all the people who presumed
that a language designer was smarter than his users. I came to realize
that the programming world was full of users who repeated "conventional
wisdom" based on generalities they heard from a friend of a friend of
an evangelist of a corporation -- and worse yet, I was part of that
culture and picked up those poor habits.


> Now, if you want to tell me that, despite all the talk, Lisp coders don't
> actually create new syntax or mini-languages all that often, that they
> just use macros as functions, then the question becomes: why do you need
> macros then if you are just using them as functions? Why not use functions?

You may wish to read the following:


Perhaps Lisp becomes clearer once you see its syntactic similarity with
a very mainstream language -- XML. (But sexps are far more lucid than
XML.) Then we can seriously talk about the real-world engineering
implications of macros, and other powerful features which aren't so
hyped as macros.


Tayssir

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() and PEP 3000

[bearophileHUGS]

Colin J. Williams:
> Why not replace the __len__ method with a len property for strings,
> lists, tuples, dictionaries etc.  __len__ is not very special and the
> property len eliminates the redundant parentheses.

You mean something like:
>>> "ab".len, [1, 2, 3].len
(2, 3)

In the given page Guido says:

>I didn't want these special operations to use ordinary method names, because 
>then pre-existing classes, or classes written by users without an encyclopedic 
>memory for all the special methods, would be liable to accidentally define 
>operations they didn't mean to implement, with possibly disastrous 
>consequences.<

I think it's easy enough to remember a len attribute, you use it all
the time.


>many functions are defined in terms of informal interfaces; for example, 
>reversed works on anything that supports random access to items and has a 
>known length. In practice, implementing things like max, sum, map, any, in and 
>others, as built-in functions and operators is actually less code than 
>implementing them as methods for each and every type that needs to support 
>them.<

I agree, but I think some exceptions can be made for len attribute, and
for .copy(), .deepcopy(), and maybe for few other general methods.

Bye,
bearophile

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> I've read all the arguments against significant indents/whitespace, or
> in favour of braces, and while there are a few minor good points they
> make, a few edge cases where Python's significant indentation is
> sub-optimal, overall I believe that the famous reaction of programmers to
> Python and whitespace is simply them being more like cats than usual:
>
> "It's different, anything different is frightening, I don't like it, hiss
> hiss spit!!!"

What about "It's wrong, it's wrong, hiss hiss spit!" ?

I want to be able to change my code and let the editor indent the
result; if I make extensive changes to a section of Python code, I
have to review it afterward and make sure I haven't introduced any
subtle indentation mistakes.  Compare

(let ((x 'blah))
 (if (eql x 'foo)
  (print "blah")
 (print "bloo"

This could quite conceivably be the result of a lot of refactoring
of (admittedly silly) code.  But now I just press C-M-q and, pow:

(let ((x 'blah))
  (if (eql x 'foo)
  (print "blah")
  (print "bloo")))

All happily-indented.  And mistakes in nesting show up as mistakes in
indenting.  Who could ask for anything more?  Python requires me to
review the structure of the code to make sure I haven't inadvertantly
broken it.  Why?

Why do I need Python to enforce my indentation (potentially leading to
bugs) when my editor can indent my code perfectly because the syntax
of Lisp is so free of special cases?

> But Lisp's syntax is so unlike most written natural languages that that it
> is a whole different story. Yes, the human brain is amazingly flexible,
> and people can learn extremely complex syntax and grammars (especially if
> they start young enough) so I'm not surprised that there are thousands,
> maybe tens or even hundreds of thousands of Lisp developers who find the
> language perfectly readable.

Most programming languages are nothing like natural languages
(thankfully - ever heard of something called COBOL?).  Lisp's syntax
is trivial to lean, and its semantics are very precise.

> But that isn't to say that the syntax of Lisp is for everybody. Far from
> it -- I'd be willing to bet that Lisp developers are a self-selected group
> of far above average intelligence. That would explain why so many of them
> seem to be so much more comfortable with higher-order functions than most
> other people -- even intelligent people. 
>
> (Looking back, I'm embarrassed about my first reaction to factory
> functions all those years ago. Hiss hiss spit. But even with added
> familiarity, there comes a time where one has to question the benefit of
> sufficiently high-order functions. If you are writing a factory function
> that returns factory functions that return factory functions that return
> the functions that you needed in the first place, chances are you really
> need to rethink your tactics.)
>
> If I'm right, then maybe Lisp is "better" in some absolute sense, *for
> those who can use it*. For those who can't, it isn't just a matter of
> (say) the syntax being hard to read because it is unfamiliar, but it
> being objectively harder to use.
>
> An interesting study would be to track people's eyeballs as they read
> code, or look at how much oxygen their brain uses. Do Lisp coders do more
> work to read Lisp than Python coders do to read Python? I suspect they do,
> but successful Lisp coders don't notice. Everybody else does, and
> gravitate to languages which might not be "better" but are "good enough".
>
> (If my post leads to any Lisp developer's already swollen head exploding
> from pride, my job here is done *wink*)

I'm afraid you're on the wrong track.  Any programmer can pick up Lisp
and be productive in it these days.  Please don't try to make Lisp
seem more mysterious or elitist than it really is.  It's just a
programming language, and anyone can learn it:

  http://www.gigamonkeys.com/book
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Fri, 08 Dec 2006 23:38:02 -0800, Wolfram Fenske wrote:
>
>> if Common Lisp didn't have CLOS, its object system, I could write my own
>> as a library and it would be just as powerful and just as easy to use as
>> the system Common Lisp already provides.  Stuff like this is impossible
>> in other languages.
>
> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?

Of course, but you have to realize that Turing-completeness is a
useless concept when comparing languages.  C and Python are both
Turing-complete.  So: write me some code in each that reads in a line
of text, splits it on spaces and stores the result in an array.  Which
would you rather write?  Which will be shorter and more easily changed
and straightforwardly grasped in the future?

QED.  Turing-completeness is irrelevant when comparing languages.
Take it as a given.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

"mystilleef" <[EMAIL PROTECTED]> writes:

> Mark Tarver wrote:
>> How do you compare Python to Lisp?  What specific advantages do you
>> think that one has over the other?
>>
>> Note I'm not a Python person and I have no axes to grind here.  This is
>> just a question for my general education.
>>
>> Mark
>
> Advantages of Python:
>
> 1). More and better mature standard libraries (Languages don't matter,
> libraries do).
> 2). Multiple programming paradigms (including functional style
> programming see itertools, functools, operator modules (lambda, map,
> filter, reduce, sum etc builtins), higher order functions, list
> comprehension, blah, blah)
> 3). Better OO implementation. (I used to hate OO until I started using
> Python)
> 4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
> said. Bindings for almost any lib worth using, at least on *nix)
> 5). Clearer syntax.
> 6). Better namespace management. (nobody ever talks about this, but
> Python seems to be one of the few languages that gets symbol management
> right from a users perspective)
> 7). Easier packaging and distribution system.
> 8). Ubiquity! Python is everywhere. Lisp, bleh.
> 9). Relatively good docs (PHP has better).
> 10). Fewer perceived community assholes. Large community.
> 11). Less fragmentation.

Are any of these not subjective?

> Advantages of Lisp:
>
> Learning a functional language can improve your programming range and

Lisp is much more than a functional language.

> depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
> when there's mind bending Haskell. I'd go as far as saying I believe
> Haskell has a better fate than Lisp.

Yeah, that's pretty far.

> On Lisp Macros:
>
> I think they are overrated, and in general cause more harm than good.
> It's the reason I find Lisp-like programs difficult to grok, maintain
> and extend. Cos every smart ass wants to needlessly write his own mini
> language to the point of absolute obfuscation. Naturally, I'm supposed
> to be awed by his mischievous cleverness.

Uh huh.  Can you cite examples of this?  Sounds like you're just
making stuff up here.  Contrary to popular belief, writing a Lisp
macro that warps your mind and introduces a totally un-CL-like
semantics is extremely difficult.  Most of the people who are good
enough at CL to do it (I'm certainly not one of them) are also
experienced enough to know when it's the right choice.

And Lisp environments all support getting the macroexpansion,
documentation, and source of any unfamiliar macro you might happen
upon, so really this is not as much of a problem as you might
fantasize it to be.

> Conclusion:
>
> The semantics or features of a language is almost irrelevant today.
> Developers want to put the lego pieces together, they don't want to
> make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
> was popular in the 70s, but it's boring and expensive today. Today,
> when a developer needs to solve a problem, the question they ask is,
> "Is there a library for that?". If the answer is no, they a more likely
> to switch to a language that provides a library that solves their
> problem. The challenge for developers today is software architecture,
> robustness and scalability, not language purity or semantics. The Lisp,
> and to an extent Haskell, community will never ever ever grok this.
> They'll continue to wonder why an "inferior" language like Python keeps
> getting popular. It will always escape them that it might be because
> Python is actually easier to use for most people to write "real world"
> applications. It has good usability.

I don't agree with a lot of what you say in this paragraph, but I
you're right that libraries are crucial.  That's why I wish there were
more people writing Lisp libraries instead of being scared away by
sheer fabrications like the stuff that's appearing in this thread.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> Dude. Turing Complete. Don't you Lisp developers know anything about
> computer science?

"Can you imagine if carpenters were like computer scientists?  Some of 
 them would argue that it's not necessary to own a hammer because the 
 butt of a screwdriver is naildriver-complete." 
  -- Barry Margolin in comp.lang.lisp 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() and PEP 3000

[tac-tics]

> __len__ is not very special and the
> property len eliminates the redundant parentheses.

One might say the current syntax eliminates the redundant dot.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote  :on '(09 Dec 2006 01:01:14 -0800))
(

 PR> If Common Lisp didn't have lexically scoped variables (most Lisp
 PR> dialects before Scheme didn't have them) then it would be very
 PR> difficult to add that with macros.

i think there's some way to hack that. for example, make defun a macro that 
will collect all lexically scoped variable and mangle them. for example:

(defun foo () (let ((i 1)) (print i)))

will be transformed to

(defun foo () (let ((i_foo 1)) (print i_foo)))

(or just some random suffix). this way variables in different functions will 
never collide. maybe there's a catch somewhere, but that should look very 
close to lexical variables.

 PR> Do you seriously think lexical scoping is the last word in language
 PR> features and that there's now nothing left in other languages that
 PR> can't straightforwardly be done in CL?  Hint:
 PR> call-with-current-continuation (also known as call/cc).

there's nothing impossible :)
we even have a lib for nondeterministic calculations -- Screamer, that's 
much much more cool than that call/cc..

(defun pythagorean-triples (n)
 (all-values
  (let ((a (an-integer-between 1 n))
(b (an-integer-between 1 n))
(c (an-integer-between 1 n)))
   (unless (= (+ (* a a) (* b b)) (* c c)) (fail))
   (list a b c

you define ranges for variables, define constraints (in a form very close to 
normal lisp code) and then just say -- all-values, or solutions (first thing 
that satisfies constaints).

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity") 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Paul Rubin  writes:

> There is just not that much boilerplate in Python code, so there's
> not so much need to hide it.

Well, of course there is.  There are always going to be patterns in
the code you write that could be collapsed.  Language has nothing to
do with it; Lisp without macros would still be susceptible to
boilerplate.

Here's a concrete example:

  (let ((control-code (read-next-control-code connection)))
(ecase control-code
  (+break+
(kill-connection connection)
(throw :broken-by-client))
  (+status+
(send-status-summary connection))
  ((+noop+ +keep-alive+
  ;; +X+ indicates a constant

The standard ECASE macro encapsulates this pattern: Compare the
variable control-code to +break+.  If the two are EQL, then run the
code provided in the +break+ clause.  Likewise for +status+.  In the
last clause, the test-form is a list, so the generated code will
compare control-code to either +noop+ or +keep-alive+.  If it is EQL
to either, it runs the body of that clause, which happens to be blank
here.  The E in ECASE stands for "error," so if control-code doesn't
match any of these choices, the generated code will signal an error
with the following text "CONTROL-CODE fell through ECASE expression;
was not one of: +BREAK+, +STATUS+, +NOOP+, +KEEP-ALIVE+".  All of that
boilerplate is handled by the macro.  In Python, I would need to do
something like:

  control_code = connection.read_next_control_code()
  if control_code == +break+:
connection.kill()
throw blah
  else if control_code == +status+:
connection.send_status_summary()
  else if control_code == +noop+ || control_code == +keep_alive+:
  else:
error "CONTROL_CODE fell through conditional cascade; was not one of 
+BREAK+, +STATUS+, +NOOP+, +KEEP_ALIVE+"

To change what control codes you want to check for, you need to add
conditionals for them and keep the error text relevant.  The reality
is that a computer could be doing this for you, leaving your code
simpler and more easily changed.

Now someone will complain that the ECASE code means nothing until I
understand ECASE.  Yep.  But once you understand ECASE, you can look
at that code and, *at a glance*, see how control flows through it.  In
the equivalent Python code, I need to walk through each conditional
and make sure they're all following the same pattern.  If you're not
convinced, extend the example to 12 different control codes.

Note also that ECASE is just expanding to the COND conditional.  There
is nothing mind-bending (or even mind-twisty) going on inside of it.
It's simply a way of expressing a common syntactic pattern in
higher-level terms.  To prove that macros are not the frightening
beasts you guys are making them out to be:

CL-USER 13 > (let ((*print-case* :downcase))
   (pprint (macroexpand '(ecase control-code
   (+break+ 
(kill-connection connection)
(throw :broken-by-client))
   (+status+
(send-status-summary connection))
   ((+noop+ +keep-alive+))

(let ((#:g17558 control-code))
  (case #:g17558
(+break+ (kill-connection connection) (throw :broken-by-client))
(+status+ (send-status-summary connection))
((+noop+ +keep-alive+))
(otherwise (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ 
+keep-alive+))

If you treat the #:G17548 as just a weirdly-named variable, you can
see that the code is just expanding into the standard CASE macro.  I
can in turn expand this CASE to:

CL-USER 14 > (let ((*print-case* :downcase))
   (pprint (macroexpand '(case #:g17558
   (+break+ 
(kill-connection connection) (throw 
:broken-by-client))
   (+status+
(send-status-summary connection))
   ((+noop+ +keep-alive+))
   (otherwise (conditions::ecase-error 
#:g17558 '(+break+ +status+ (+noop+ +keep-alive+

(let ((#:g17559 #:g17558))
  (cond ((eql '+break+ #:g17559) (kill-connection connection) (throw 
:broken-by-client))
((eql '+status+ #:g17559) (send-status-summary connection))
((or (eql '+noop+ #:g17559) (eql '+keep-alive+ #:g17559)) nil)
(t (conditions::ecase-error #:g17558 '(+break+ +status+ (+noop+ 
+keep-alive+))

COND is the Lisp conditional form.

As you can see, ECASE does not blow your mind, but simply names and
standardizes a common pattern of code.  It expands into standard
macros.  And ECASE is so easy to write that most Lisp programmers have
extended versions of it in their personal libraries.  And most of
these are named GENERIC-CASE or STRING-CASE, etc. and m

Re: Interacting with keyboard LEDs

[Jonathan Curran]

Chris,
I googled for {xlib caps led} and the first link was to a forum post: 
http://forums.whirlpool.net.au/forum-replies-archive.cfm/619126.html

The third post down, the guy made a program to set the LED of his scroll lock 
key. The C source is at http://members.optusnet.com.au/foonly/hddled.c

If you can manage to convert his code into python w/python-xlib you will be 
set. When you do, e-mail me the snippet will you ;)

- Jonathan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> With Lisp macros, even that isn't guaranteed. Now, if Lispers would say
> "Oh yes, macros give you great power, and with great power comes great
> responsibility. Be careful." then, no doubt, we'd take you guys more
> seriously. But we don't hear that -- we hear Lispers going on and on about

And, of course, we do say that.  Nobody wants people running around
writing incomprehensible macros.  How does that help anyone?
Fortunately, it's not a problem in practice, because most macros map
quite straightforwardly to Lisp constructs and almost no one has the
time or the intelligence to write the mini-languages that seem to be
terrifying you so much.

> how great it is that they can easily redefine every corner of the
> language. Do you blame people for *believing them* and imagining that
> reading Lisp code is like following some ghostly will-o-the-wisp across a
> swamp, where nothing is what it seems and the landscape is forever
> shifting?

"every corner of the language"?  Please.  Why are you so post-happy
when it's quite obvious that you don't know enough about Lisp to
attack it?

Most programmers do not write macros that are incredibly difficult to
understand.  Beginners might, but beginners might also write
incomprehensible code in Java or Python.  As you learn Lisp, you learn
to keep your macros tied to the underlying Lisp.  You learn to make
the expansions into function or method defintions, instead of
reinventing the wheel.  You leverage what Lisp offers, instead of
redefining it.

The only times you are really going to find completely alien semantics
are in textbooks (like Prolog in Lisp), in very ambitious and large
projects where the new semantics are the only reason you'd use the
code in the first place (like Franz's AllegroProlog or Marco
Baringer's CPS transformer), or in code written by beginners.  Please
stop spreading FUD about this.  In real life, macros make coding more
pleasant and make your code more maintainable.  They are something to
embrace, not something to fear.

To provide a more solid example, Peter Seibel's book _Practical Common
Lisp_ (full text at http://www.gigamonkeys.com/book) provides a set of
classes for parsing binary files.  Some user code provided in the
book:

(define-binary-class id3v2.3-tag (id3-tag)
  ((extended-header-size (optional :type 'u4 :if (extended-p flags)))
   (extra-flags  (optional :type 'u2 :if (extended-p flags)))
   (padding-size (optional :type 'u4 :if (extended-p flags)))
   (crc  (optional :type 'u4 :if (crc-p flags extra-flags)))
   (frames   (id3-frames :tag-size size :frame-type 
'id3v2.3-frame

This code very closely mirrors the standard DEFCLASS in Common Lisp,
so a maintainer knows right away what to expect.  The macro expands
into DEFCLASS and DEFMETHOD forms.  There's nothing mysterious going
on here; the macro is just a friendlier syntax for expressing an idea.
What I get from this are methods that read binary data into objects of
the class that I've just defined (*).  That's all - methods and a
class.  There is no mind-bending going on at all here.  It's true of
course that I have to understand how the macro works.  But without it,
I'd have to write and/or read through a lot of similar-looking code
for handling binary data.  Which would you prefer?

Without a macro like this, the code required would be the definition
of boilerplate.  Instead of specifying declaratively the order and
type of fields in the binary file, I would write code to read each
field from the file and then store the result in an object.  I'd also
have to take into account fields that are optional.  This is ugly and
boring code.  Did I mention that DEFINE-BINARY-CLASS also defines
methods to save these objects back to binary files?  Because it does.

So why not write this code once and then take advantage of it in the
future to get more expressive, less boring programs?



*  If you don't believe me, here is the expansion of the code I cited above:

http://paste.lisp.org/display/31799

Just methods and a class.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() and PEP 3000

[Colin J. Williams]

tac-tics wrote:
>> __len__ is not very special and the
>> property len eliminates the redundant parentheses.
> 
> One might say the current syntax eliminates the redundant dot.
> 
touché

On the other hand, one can argue that, since len is intimately 
associated with an object, it's better treated as an attribute/property 
than to have an unconnected function out in namespace.

Colin W.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: len() and PEP 3000

[Fredrik Lundh]

Colin J. Williams wrote:

> On the other hand, one can argue that, since len is intimately 
> associated with an object, it's better treated as an attribute/property 
> than to have an unconnected function out in namespace.

"unconnected" ???



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Bill Atkins]

Bill Atkins <[EMAIL PROTECTED]> writes:

> "every corner of the language"?  Please.  Why are you so post-happy
> when it's quite obvious that you don't know enough about Lisp to
> attack it?

In addition to macros that define classes or methods, a common macro
is the WITH-* macro, which sets up some kind of context, runs the body
inside that context, and then does some cleanup.

For example, my Lisp vendor, LispWorks, provides the macro MP:WITH-LOCK :

(mp:with-lock (*the-big-lock*)
  (do-something-atomic)
  (something-else)
  (almost-odone))

The generated first seizes a process lock called *THE-BIG-LOCK*, runs
the code in the body and then releases the lock.  I never have to
worry that I've taken a lock without releasing it, because LispWorks
has encoded that behaviour into MP:WITH-LOCK (and if they handn't,
this macro is trivial to write).

Now I can tell if I'm keeping a lock around too long because all the
code that appears inside this WITH-LOCK is all the code that I'm
locking.  Further, the generated code is surrounded by an
UNWIND-PROTECT, which means that if an error is raised or anything
abnormal happens in the dynamic scope of the UNWIND-PROTECT, Lisp will
run cleanup code as it flees back up the stack.  So if there is an
error in my code, it does not prevent other processes from seizing
that lock, because it will be released as the error is signaled.

Here is the expansion:

CL-USER 7 > (write (macroexpand '(mp:with-lock (*the-big-lock*)
   (do-something-atomic)
   (something-else)
   (almost-odone)))
   :pretty t :case :downcase)
(let ((#:g17553 *the-big-lock*))
  (when (mp:process-lock #:g17553)
(unwind-protect
(progn (do-something-atomic) (something-else) (almost-odone))
  (mp::in-process-unlock #:g17553
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Kirk Sluder]

In article <[EMAIL PROTECTED]>,
 "mystilleef" <[EMAIL PROTECTED]> wrote:

> 1). More and better mature standard libraries (Languages don't matter,
> libraries do).

> On Lisp Macros:
> 
> I think they are overrated, and in general cause more harm than good.
> It's the reason I find Lisp-like programs difficult to grok, maintain
> and extend. Cos every smart ass wants to needlessly write his own mini
> language to the point of absolute obfuscation. Naturally, I'm supposed
> to be awed by his mischievous cleverness.

I've not seen a convincing explanation as to why imported macros 
from some library are so much more evil than imported functions. In 
both cases one might have to dig into documentation and/or comments 
to understand exactly what that imported snippit is doing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Bourguignon]

Kirk  Sluder <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]>,
>  "mystilleef" <[EMAIL PROTECTED]> wrote:
>
>> 1). More and better mature standard libraries (Languages don't matter,
>> libraries do).
> 
>> On Lisp Macros:
>> 
>> I think they are overrated, and in general cause more harm than good.
>> It's the reason I find Lisp-like programs difficult to grok, maintain
>> and extend. Cos every smart ass wants to needlessly write his own mini
>> language to the point of absolute obfuscation. Naturally, I'm supposed
>> to be awed by his mischievous cleverness.
>
> I've not seen a convincing explanation as to why imported macros 
> from some library are so much more evil than imported functions. In 
> both cases one might have to dig into documentation and/or comments 
> to understand exactly what that imported snippit is doing.

And the difference with a library function is?

(defpackage "LIBRARY" (:export "THIS-IS-A-FUNCTION"))

(library:this-is-a-function ???) ; ???

-- 
__Pascal Bourguignon__ http://www.informatimago.com/

"This statement is false."In Lisp: (defun Q () (eq nil (Q)))
-- 
http://mail.python.org/mailman/listinfo/python-list