Re: merits of Lisp vs Python

[Espen Vestre]

Paul Rubin  writes:

> Robert Brown <[EMAIL PROTECTED]> writes:

> > Does this make Lisp "less dynamic" than Python?  Espen would say it's not
> > less dynamic, but rather that a similar level of dynamism is achieved in
> > Common Lisp via well defined interfaces.  The compiler knows the interfaces,
> > so it can do a better job optimizing the code.

[thank you for clarifying my post, Robert]

> I'd say Python is more dynamic in the sense that the Python runtime
> system has to actually concern itself about the dynamism all the time
> in practice, i.e. on every object method invocation.  

Ok, but when you state that language A is more dynamic than language
B, most programmers would interpret that as (or so I guess) "A offers
more dynamism to the programmer than B" - not that it burdens the run
time system implementor with more dynamism...

-- 
  (espen)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: alternate language

[Hendrik van Rooyen]

"Bryan" <[EMAIL PROTECTED]> wrote:


> what is a good alternate language to learn? i just want something to expand
> my mind and hopefully reduce or delay any chance of alzheimer's. i would
> especially like to hear from those of you who learned python _before_ these
> languages.
>
> haskell, erlang, ocaml, mozart/oz, rebel, etc.
>
> i don't require any of these features, but extra browny points for any of
> the following:
>
> interactive interpreter
> batteries included
> can integrate with c
> compiles to native code
> can use a gui toolkit such as wx
> doesn't take 60 hour weeks over years to master

Here's a skewed alternative, that has none of the features you are looking for:

1) Buy a development kit for a pic, 8031, avr or arm.
2) Read the documentation for the processor
3) Write a "hello world" in Assembler, simultaneously flickering an LED.

It will give more satisfaction, and delay the onset of Alzheimer's, far more
effectively than any of the higher level languages you are contemplating.

And if you really want a challenge, don't use the assembler, hand code the hex.
Just once.
Just so that you can appreciate what an assembler, and by extension,
a compiler, does for you.

- Happy hacking   ;-)

- Hendrik



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

Error

[dominis]

Your message was undeliverable due to the following reason:

Your message was not delivered because the destination server was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message could not be delivered within 2 days:
Host 216.78.202.45 is not responding.

The following recipients did not receive this message:


Please reply to [EMAIL PROTECTED]
if you feel this message to be in error.

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

Re: merits of Lisp vs Python

[Juan R.]

Rob Thorpe ha escrito:
> Juan R. wrote:
> > Ken Tilton ha escrito:
> > > You missed it? Google fight:
> > >
> > >http://www.googlefight.com/index.php?lang=en_GB&word1=Python&word2=Ruby
> > >
> > > Python wins, 74 to 69.3. And there is no Monty Ruby to help.
> > >
> > > ken
> >
> > Nice animation!
> >
> > http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Monty+Ruby
>
> It's not fair to pick on him just because you're better at
> Googlefighting...

I simply noticed (eval "there is no Monty Ruby to help") --> NIL

> http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Juan+Gonz%E1lez
>
> This thing is strange, I don't understand it at all...

There is many "Juan González" but i am not one of them. Try next

http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Juan+R.+Gonz%E1lez+%C1lvarez

> http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Robert+Thorpe
> I find the results dubious.  A conspiracy masterminded by Monty Ruby no
> doubt.

With some help from mediocre programmers :)

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

Re: merits of Lisp vs Python

[I V]

On Mon, 11 Dec 2006 23:24:07 -0500, Ken Tilton wrote:
> Also, Python does not support a functional style of programming so the 
> line is the only meaningful textual entity. In this sense the 
> primitiveness of Python makes editing easier.

Why do you say that? Wouldn't a block in python be a "meaningful textual
entity" in the same way a lisp form would be?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pekka Karjalainen]

In article <[EMAIL PROTECTED]>, Paul Rubin wrote:
>Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> writes:
>> So there seems to be something macro-like for Haskell.
>
>I think that's some kind of proposed or experimental Haskell feature,
>not in the current standard, but I'm not sure.  I'm barely even a
>newbie with Haskell.

It's called Template Haskell.

http://www.haskell.org/th/

"Template Haskell is an extension to Haskell 98 that allows you to do
type-safe compile-time meta-programming, with Haskell both as the
manipulating language and the language being manipulated."

There is an experimental implementation in new versions of GHC.

Follow-ups set to comp.lang.haskell in case anyone wants to discuss it. I
claim no understanding of it yet. Better figure out ordinary Haskell
first...

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

Re: merits of Lisp vs Python

[I V]

On Sun, 10 Dec 2006 03:18:07 -0500, Bill Atkins wrote:
> We're not counting lines here, you goon.  We're talking about how
> expressive constructs are and how closely they match your concept of
> what you want to do.  The conditional example is lower-level; you're
> talking to the interpreter instead of saying what you want to achieve.
> You're having to repeat things because that's what the language asks
> of you, instead of describing in a higher-level way what you're
> actually doing.

To be a little provocative, I wonder if the idea that you're "talking to
the interpreter" doesn't apply more to lisp than to python; you can have
any syntax you like, as long as it looks like an AST. 

One of the things I've always found off-putting about lisp as that all the
syntax looks the same. In Algol-derived languages, each syntactic
construct has a fairly distinctive appearance, so when, for instance, I
encounter a for loop, I can quickly recognize that that's what it is, and
bracket out the "scaffolding" and pick out the details that interest me.
With lisp, I can't do that, I have to read through the sexp, decide on
what syntax it is, and then remind myself where to look for the relevant
specific details.

Now, this might well be just due to my comparative lack of familiarity
with lisp; I'd be interested to hear if you lisp people find different
lisp constructs as visually distinctive as constructs in python (or other
similar languages). But I think what people are getting at when they
complain about "all the brackets" in lisp may actually be this issue of
a visual distinction between different constructs (this is also a reason
why having a limited number of syntactic constructs can be helpful - there
are a probably a  limited number of stereotypical layouts a programmer can
keep in their mind at once).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Juan R.]

Kay Schluehr ha escrito:

> Juan R. wrote:
>
> > Kay Schluehr ha escrito:
> > > Note also that a homogenous syntax is not that important when
> > > analyzing parse trees ( on the contrary, the more different structures
> > > the better ) but when synthesizing new ones by fitting different
> > > fragments of them together.
> >
> > Interesting, could you provide some illustration for this?
>
> My approach is strongly grammar based. You start with a grammar
> description of your language. This is really not much different from
> using Lex/Yacc except that it is situated and adapted to a pre-existing
> language ecosystem. I do not intend to start from scratch.
>
> Besides the rules that constitute your host language you might add:
>
> repeat_stmt ::=  'repeat' ':' suite 'until' ':' test
>
> The transformation target ( the "template" ) is
>
> while True:
> 
> if :
> break
>
> The structure of the rule is also the structure of its constituents in
> the parse tree. Since you match the repeat_stmt rule and its
> corresponding node in the parse tree you immediately get the 
> node and the  node:
>
> class FiberTransformer(Transformer):
> @transform
> def repeat_stmt(self, node):
>  _suite = find_node(node, symbol.suite)
>  _ test = find_node(node, symbol.test, depth = 1)
>  #
>  # create the while_stmt here
>  #
>  return _while_stmt_node
>
> So analysis works just fine. But what about creating the transformation
> target? The problem with the template above is that it can't work
> precisely this way as a Python statement, because the rule for a while
> statement looks like this:
>
> while_stmt: 'while' test ':' suite
>
> That's why the macro expander has to merge the  node, passed
> into the template with the if_stmt of the template, into a new suite
> node.
>
> Now think about having created a while_stmt from your original
> repeat_stmt. You return the while_stmt and it has to be fitted into the
> original syntax tree in place of the repeat_stmt. This must be done
> carefully. Otherwise structure in the tree is desroyed or the node is
> inserted in a place where the compiler does not expect it.
>
> The framework has to do lots of work to ease the pain for the meta
> programmer.
>
> a) create the correct transformation target
> b) fit the target into the syntax tree
>
> Nothing depends here particularly on Python but is true for any
> language with a fixed grammar description. I've worked exclusively with
> LL(1) grammars but I see no reason why this general scheme shall not
> work with more powefull grammars and more complicated languages - Rubys
> for example.

Thanks.

> > > The next question concerns compositionality of language
> > > enhancements or composition of even completely independent language
> > > definitions and transformers both on source and on binary level. While
> > > this is not feasible in general without creating ambiguities, I believe
> > > this problem can be reduced to ambiguity detection in the underlying
> > > grammars.
> >
> > A bit ambiguous my reading. What is not feasible in general? Achieving
> > compositionality?
>
> Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> grammars and T1, T2 transformers that transform source written in L1 or
> L2 into some base language
> L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> s.t. the transformers T1 and T2 can be used also to transform  L3 = (G3
> = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> the answer is NO.

You mean direct compositionality. Is there any formal proof that you
cannot find a (G2' , T2') unambiguously generating (G2, T2) and
combining with L1 or this is always possible?

This would not work for language enhancements but for composition of
completely independent languages.

> But it could also be YES in many relevant cases. So
> the question is whether it is necessary and sufficient to check whether
> the "crossing" between G1 and G2 is feasible i.e. doesn't produce
> ambiguities.

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

Re: How do I edit a PythonWin path to import custom built modules???

[mohan]

BartlebyScrivener wrote:
> mohan wrote:
>
> > I had created my own modules (.py files) in
> > drives and folders other than the python root.
>
> Probably easiest if you keep them all in one place. Then add that
> "place" to your path by going into Control
> Panel|System|Advanced|Environment Variables and adding the path to the
> path variable.
>
> Hope that helps.
>
> rd

Thanks rd,

I tried your advice, by adding a new path to the "System Variable"
section. It still does not work. I don't understand how could PythonWin
interpreter would look for new folders when we have not yet updated the
path in the interpreter. I'm sorry I might be mising something here as
i'm not too familiar with these things.

Any further ideas??

Regards,
Mohan.

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

ANN: BayPIGgies, Thu 12/14 7:30-9p, Mtn View

[wesley chun]

reminder that we have a "lite" meeting this thursday evening at
Google.  it is a meet-n-greet event, almost a "long random access"
session where folks introduce themselves, mingle/network, discuss
common interests, and get to know one another in the community. we may
discuss any number of current topics such as Python 2.5, the upcoming
PyCon conference at Dallas at the end of Feb, the latest Python books
and reviews, future meeting coordination, etc.

more info and directions at http://baypiggies.net

pre-register here to avoid the long security lines:
http://wiki.python.org/moin/BayPiggiesGoogleMeetings

hope to see some of you there!
-wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
http://corepython.com

wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Juan R.]

Kaz Kylheku ha escrito:

> Kay Schluehr wrote:
> > Juan R. wrote:
> > > A bit ambiguous my reading. What is not feasible in general? Achieving
> > > compositionality?
> >
> > Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> > grammars and T1, T2 transformers that transform source written in L1 or
> > L2 into some base language
> > L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> > s.t. the transformers T1 and T2 can be used also to transform  L3 = (G3
> > = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> > the answer is NO. But it could also be YES in many relevant cases. So
> > the question is whether it is necessary and sufficient to check whether
> > the "crossing" between G1 and G2 is feasible i.e. doesn't produce
> > ambiguities.
>
> See, we don't have this problem in Lisp, unless some of the transfomers
> in T1 have names that clash with those in T2. That problem can be
> avoided by placing the macros in separate packages, or by renaming.

Or simply namespacing!

foo from package alpha --> alpha:foo

foo from package beta --> beta:foo

But what composition of different languages? E.g. LISP and Fortran in
the same source.

> In
> In the absence of naming conflicts, the two macro languages L1 and L2
> combine seamlessly into L3, because the transformers T are defined on
> structure, not on lexical grammar. The read grammar doesn't change (and
> is in fact irrelevant, since the whole drama is played out with
> objects, not text). In L1, the grammar is nested lists. In L2, the
> grammar is, again, nested lists. And in L3: nested lists. So that in
> fact, at one level, you don't even recognize them as being different
> languages, but on a different level you can.
>
> The problems you are grappling with are in fact created by the
> invention of an unsuitable encoding. You are in effect solving a puzzle
> that you or others created for you.

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

Re: Tarfile .bz2

[Yu-Xi Lim]

Jordan wrote:
> So that would explain why a tar.bz2 archive can't be appended to
> wouldn't it...  And also explain why winrar was so slow to open it (not
> something I mentioned before, but definitely noticed).  I had wondered
> what it was that made bz2 so much better at compression than zip and
> rar.  Not really on topic anymore but what's the method for tar.gz? And
> even more off the topic, does anyone know a good lossless compression
> method for images (mainly .jpg and .png)?

You can get the same effect from RAR and other formats (ACE, 7z) by 
using the "Solid Archive" or similar option. Ideally, you'd be 
compressing lots of similar files for this to be effective. The actual 
compression ratios of RAR and bz2 can be pretty similar when done this way.

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

Re: Tarfile .bz2

[Yu-Xi Lim]

Martin v. Löwis wrote:
> Well, .jpg files are already compressed in a lossy way (.jpg is
> inherently lossy); to compress it further, you need to increase
> the loss. PNG is also compressed already, see

Not really. Stuffit has a JPEG compressor which takes advantage of the
fact that the JPEG algorithm isn't as optimal as it can be. It converts
JPEG images to its own more compact representation which then can be
converted back to JPEG as needed, without any loss. It is sadly not free.


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

Re: Avoiding "invalid literal for int()" exception

[Peter Otten]

Marc 'BlackJack' Rintsch wrote:

> In <[EMAIL PROTECTED]>, Gabriel
> Genellina wrote:
> 
>> At Monday 11/12/2006 07:22, [EMAIL PROTECTED] wrote:
>> 
>>>elif int(uniList[0]) in range(0,10):
>> 
>> Either of these will work to avoid an unneeded conversion:
>> 
>> elif uniList[0] in "0123456789":
>> 
>> elif uniList[0] in string.digits:
>> 
>> elif uniList[0].isdigit():
> 
> The last does not work.  Not only that it accepts numbers greater than 9
> because it checks if the whole string consists of digits, it also accepts
> u'²?' and other unicode digits.

By the way, if you require an implicit 0 <= int(s) < 10 check, none of the
above work with the newer Pythons:

>>> s = "23"
>>> s in "0123456789"
True
>>> s in set("0123456789")
False

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

Re: merits of Lisp vs Python

[Juan R.]

greg ha escrito:

>  From another angle, think about what a hypothetical
> Python-to-Lisp translator would have to do. It couldn't
> just translate "a + b" into "(+ a b)". It would have
> to be something like "(*python-add* a b)" where
> *python-add* is some support function doing all the
> dynamic dispatching that the Python interpreter would
> have done.
>
> That's what I mean by Python being more dynamic than
> Lisp.

I see no dinamism on your example, just static overloading.

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

One module per class, bad idea?

[Matias Jansson]

I come from a background of Java and C# where it is common practise to have 
one class per file in the file/project structure. As I have understood it, 
it is more common practice to have many classes in a Python module/file. 
What is the motivation behind it, would it be a bad idea to have a guideline 
in your project that promotes a one class per file structure (assuming most 
of the programmers a background similar to mine)? 


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

Re: Can't register to CheeseShop at command line...only on web?!..

[Richard Jones]

[EMAIL PROTECTED] wrote:
> I created $HOME/.pypirc with this:
> [server-login]
> username:seberino
> password:SECRET
> 
> but I can still only do CheeseShop tasks at web interface.
> 
> Here is what happens when I try to register at command line with
> .pypirc above...
> 
> Using PyPI login from /home/seb/.pypirc
> Server response (401): Authorization Required

Do you use a proxy to access the web?


Richard

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

how can I block a thread until some other thread finished?

[bearsprite]

I start a thread A. In A, I start thread B,C,D,...

How can I block A until B,C,D,...(All the thread started by A) finished?

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

Re: merits of Lisp vs Python

[greg]

[EMAIL PROTECTED] wrote:

> Does the word "TRONDANT" hold some special meaning for you?

Er, no, in fact my brain raises a KeyError on it.
Is it supposed to mean anything?

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

Re: how can I block a thread until some other thread finished?

[bearsprite]

I think I need some implement like win32 API WaitForMultiObject.

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

Re: Tarfile .bz2

[Fredrik Lundh]

Martin v. Löwis wrote:

> Well, .jpg files are already compressed in a lossy way (.jpg is
> inherently lossy); to compress it further, you need to increase
> the loss.

or use a better algorithm, such as JPEG 2000 or Microsoft's HD Photo, 
which both give better visual quality at lower bit rates (which means 
that you can often get by with around half the bits compared to JPEG).



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

Re: merits of Lisp vs Python

[Kay Schluehr]

Juan R. schrieb:

> > Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
> > grammars and T1, T2 transformers that transform source written in L1 or
> > L2 into some base language
> > L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
> > s.t. the transformers T1 and T2 can be used also to transform  L3 = (G3
> > = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
> > the answer is NO.
>
> You mean direct compositionality. Is there any formal proof that you
> cannot find a (G2' , T2') unambiguously generating (G2, T2) and
> combining with L1 or this is always possible?

You mean a universal language adapter? I guess this is always possible
using alpha conversion but I don't believe this leads to theoretical or
practical interesting solutions but is just a limit concept.

> This would not work for language enhancements but for composition of
> completely independent languages.

The practical problem with composing enhancements is that any two
extensions L1, L2 share a lot of rules and rely on their structure.
What if they don't just extend their host language L0 conservatively
but also redefine rules of L0? This is not just a theoretical problem
but it happens quite naturally if you want to adapt an extension
developed for Python 2.4 for working with Python 2.5. Here Python 2.5
is considered as just another particular extension. Obviously Py3K will
become an interesting testcase for all kinds of syntactical and
semantical transformations.

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

Re: One module per class, bad idea?

[billie]

> would it be a bad idea to have a guideline
> in your project that promotes a one class per file structure (assuming most
> of the programmers a background similar to mine)?

Yes, it would be a bad idea. =)

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

Re: merits of Lisp vs Python

[Kay Schluehr]

I V schrieb:

> One of the things I've always found off-putting about lisp as that all the
> syntax looks the same. In Algol-derived languages, each syntactic
> construct has a fairly distinctive appearance, so when, for instance, I
> encounter a for loop, I can quickly recognize that that's what it is, and
> bracket out the "scaffolding" and pick out the details that interest me.

I guess towards the intentional programming guys around Charles Simonyi
also all Algol languages look roughly the same. I remember how annoyed
I was as a math student that no PL supported my familiar notations
directly. I don't even try to speculate what chemists think about ASCII.

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

Re: One module per class, bad idea?

[Fredrik Lundh]

Matias Jansson wrote:

> I come from a background of Java and C# where it is common practise to have 
> one class per file in the file/project structure. As I have understood it, 
> it is more common practice to have many classes in a Python module/file. 

even more important is that in Python, you don't use classes for every-
thing; if you need factories, singletons, multiple ways to create 
objects, polymorphic helpers, etc, you use plain functions, not classes 
or static methods.

once you've gotten over the "it's all classes", use modules to organize 
things in a way that makes sense to the code that uses your components. 
  make the import statements look good.



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

Re: Password, trust and user notification

[Gabriel Genellina]

placid ha escrito:

> I was going to write this script for a friend that notifies him via
> logging onto his Gmail account and sending him an email to his work
> email about some events occurring in the execution of the script.
> If you enter your password into a script as input how can someone trust
> the programmer that he will not send a email to himself containing his
> password? Assuming this person does not know anything about programming
> and this person knows nothing about programming ethics.

You DON'T need the password for the receiving account just to send him
an email!
And you don't even need that special Gmail library, smtplib should be
fine.

-- 
Gabriel Genellina

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

Re: How do I edit a PythonWin path to import custom built modules???

[Gabriel Genellina]

mohan ha escrito:

> > > I had created my own modules (.py files) in
> > > drives and folders other than the python root.
> >
> I tried your advice, by adding a new path to the "System Variable"
> section. It still does not work. I don't understand how could PythonWin

There was an error in a previous post, you should create a variable
called PYTHONPATH, not change the system PATH.
Or, group your modules into packages and put them below
lib\site-packages.

-- 
Gabriel Genellina

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

Re: Avoiding "invalid literal for int()" exception

[Gabriel Genellina]

Marc 'BlackJack' Rintsch ha escrito:

> In <[EMAIL PROTECTED]>, Gabriel
> Genellina wrote:
>
> > elif uniList[0].isdigit():
>
> The last does not work.  Not only that it accepts numbers greater than 9
> because it checks if the whole string consists of digits, it also accepts
> u'²₂' and other unicode digits.

Oh, I didn't know that last part! Thanks.
I get a bit confused by the [0], thinking it was checking a single
character.

-- 
Gabriel Genellina

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

Re: Avoiding "invalid literal for int()" exception

[Fredrik Lundh]

Gabriel Genellina wrote:

>>> elif uniList[0].isdigit():
>>

>> The last does not work.  Not only that it accepts numbers greater than 9
>> because it checks if the whole string consists of digits, it also accepts
>> u'²₂' and other unicode digits.
> 
> Oh, I didn't know that last part! Thanks.
> I get a bit confused by the [0], thinking it was checking a single
> character.

if you really want to use isdigit(), writing

 uniList[0].encode("ascii", "ignore").isdigit()

should solve the unicode issue, I think.



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

Re: merits of Lisp vs Python

[Pascal Costanza]

I V wrote:

> One of the things I've always found off-putting about lisp as that all the
> syntax looks the same. In Algol-derived languages, each syntactic
> construct has a fairly distinctive appearance, so when, for instance, I
> encounter a for loop, I can quickly recognize that that's what it is, and
> bracket out the "scaffolding" and pick out the details that interest me.
> With lisp, I can't do that, I have to read through the sexp, decide on
> what syntax it is, and then remind myself where to look for the relevant
> specific details.

May you have tried the wrong Lisp dialects so far:

(loop for i from 2 to 10 by 2
   do (print i))


This is Common Lisp. (Many Lisp and Scheme tutorials teach you that you 
should implement this using recursion, but you really don't have to. ;)


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: One module per class, bad idea?

[Fuzzyman]

Matias Jansson wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python module/file.
> What is the motivation behind it, would it be a bad idea to have a guideline
> in your project that promotes a one class per file structure (assuming most
> of the programmers a background similar to mine)?

It's not a bad general guideline.

We try and use one class per file unless they are really trivial or
tightly coupled to another.

It allows you to be very specific in the naming of files and isolate
functionality.

We also have files with 'helper functions', which often have several
functions.

Fuzzyman
http://www.voidspace.org.uk/index2.shtml

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

Re: One module per class, bad idea?

[Andy Dingley]

Matias Jansson wrote:

> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure.

Don't confuse packages and files.  Java commonly splits a package
across many files, Python binds a module to a single file. If you see
"Java package" as more comparable to "Python module" then the
difference in how many classes are in a file becomes unimportant.

Java also puts many classes in the same source file, if they're tightly
coupled (e.g. Swing UI). It spits them out into separate .class files
though.

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

Re: merits of Lisp vs Python

[Paul Rubin]

Espen Vestre <[EMAIL PROTECTED]> writes:
> > I'd say Python is more dynamic in the sense that the Python runtime
> > system has to actually concern itself about the dynamism all the time
> > in practice, i.e. on every object method invocation.  
> 
> Ok, but when you state that language A is more dynamic than language
> B, most programmers would interpret that as (or so I guess) "A offers
> more dynamism to the programmer than B" - not that it burdens the run
> time system implementor with more dynamism...

I'm sorry for any misunderstanding.  Maybe I should have said that
Python's dynamism is more pervasive: it can be activated in more
different ways and that creates an extra burden on the runtime system.
Remember that the context was whether Python could be compiled to
efficient machine code.  So I referred to "more dynamism" from the
implementers' point of view--the runtime has to pay attention to more
things and spend more resources dealing with the dynamism.

I think the Lispies see "more dynamism" as a good thing and are
therefore defending their language from suggestions that Python is
even more dynamic than Lisp.  I mean "dynamic" in a less good way--
there is a huge amount of state scattered all through a running Python
program, that the application can modify at random and whose contents
the working of really fundamental operations like method invocation.
It's just a big mess and I'd get rid of it if I could.  It reminds me
of like old time Lisp programs that pervasively used property lists on
symbols to attach random attributes to the symbol, instead of using
something like defstruct to make multi-field data values.

How about if I say Python and Lisp are both dynamic, but Lisp does a
better job of keeping its dynamism's potentially chaotic effects
contained.  Does that help?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

I V <[EMAIL PROTECTED]> writes:
> > Also, Python does not support a functional style of programming so the 
> > line is the only meaningful textual entity. In this sense the 
> > primitiveness of Python makes editing easier.
> 
> Why do you say that? Wouldn't a block in python be a "meaningful textual
> entity" in the same way a lisp form would be?

You normally wouldn't refactor Python code by moving an indented block
to the inside of an expression.  That is done all the time in Lisp.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Pascal Costanza <[EMAIL PROTECTED]> writes:
> May you have tried the wrong Lisp dialects so far:
> 
> (loop for i from 2 to 10 by 2
>do (print i))

The loop language is so complicated and confusing that I never
bothered trying to learn it.  I always used simpler primitives to
write loops and it was always enough.

> This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
> you should implement this using recursion, but you really don't have
> to. ;)

You can't really use that much recursion in Lisp because of the lack
of guaranteed TCO.  I think that makes it reasonable to say that
Scheme is a functional language but Lisp is not.  ("Functional" = it's
reasonable to code in a style where the only way to connect variables
to values is lambda binding (maybe through syntax sugar), so all loops
are implemented with recursion).
-- 
http://mail.python.org/mailman/listinfo/python-list

Emulate @classmethod using decorator and descriptor

[WaterWalk]

Hello, I was recently learning python decorator and descriptor and
emulated a @classmethod decorator:
class EmuClassMethod(object):
def __init__(self, f=None):
self.f = f
def __get__(self, obj, klass=None):
if klass is None:
   klass = type(obj)
def  wrapped(*args):
   return self.f(klass, *args)
return wrapped

class Test(object):
@EmuClassMethod
def t(cls):
print "I'm %s" % cls.__name__

It worked, and seems that a function decorator works as follows:
# decf is a decorator
@decf
def func():
print 'func'

will be "converted" to:

def func():
print 'func'
func = decf(func)

Is this really the case? Or correct me if i'm wrong. Thanks in advance.

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

Re: About alternatives to Matlab

[Jon Harrop]

Paul Rubin wrote:
> Well, work is already under way (already mentioned) to implement
> Python in Python, including a reasonable compiler (Psyco).
> 
> The big deficiency of MLton from a concurrency perspective is
> inability to use multiprocessors.  Of course CPython has the same
> deficiency.  Same with OCaml.  Is the ML community trying to do
> anything about this?

Yes. Several MLs support concurrency. Perhaps F# is the most notable in this
case because it would provide an easier path to JIT (to .NET IL).

Concurrent GC seems to be a lot slower though (e.g. Java or .NET vs OCaml or
MLton).

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

[Espen Vestre]

Paul Rubin  writes:

> I think the Lispies see "more dynamism" as a good thing 

Sure...

> I mean "dynamic" in a less good way-- there is a huge amount of
> state scattered all through a running Python program, that the
> application can modify at random and whose contents the working of
> really fundamental operations like method invocation.

That's what I call /kludgy/, not /dynamic/ ;-)

> How about if I say Python and Lisp are both dynamic, but Lisp does a
> better job of keeping its dynamism's potentially chaotic effects
> contained.  Does that help?

Yes, that's fine with me!
-- 
  (espen)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Paul Rubin wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
>> May you have tried the wrong Lisp dialects so far:
>>
>> (loop for i from 2 to 10 by 2
>>do (print i))
> 
> The loop language is so complicated and confusing that I never
> bothered trying to learn it.

You can start with loop by using only the simple and straightforward 
constructs, and slowly move towards the more complicated cases when 
necessary. The nice thing about loop is that with some practice, you can 
write code that more or less reads like English.

 > I always used simpler primitives to
 > write loops and it was always enough.

No language construct is so simple that it cannot be replaced with a 
combination of simpler primitives.

>> This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
>> you should implement this using recursion, but you really don't have
>> to. ;)
> 
> You can't really use that much recursion in Lisp because of the lack
> of guaranteed TCO.  I think that makes it reasonable to say that
> Scheme is a functional language but Lisp is not.  ("Functional" = it's
> reasonable to code in a style where the only way to connect variables
> to values is lambda binding (maybe through syntax sugar), so all loops
> are implemented with recursion).

All Common Lisp implementations that I am aware of provide ways to 
enable TCO, so it's definitely possible to program in a functional style 
if you want to. It's just that the ANSI Common Lisp specification 
doesn't guarantee this, but this doesn't matter much. The only downside 
is that there is no common interface to enable TCO - that would indeed 
be an improvement. The upside is that you can switch TCO off if you want 
to, which for example may improve debugging.

It's correct that Scheme has a stronger tendency towards functional 
programming than Lisp has.


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

[Stephen Eilert]

Greg Johnston escreveu:

> Stephen Eilert wrote:
> > So, let's suppose I now want to learn LISP (I did try, on several
> > occasions). What I would like to do would be to replace Python and code
> > GUI applications. Yes, those boring business-like applications that
> > have to access databases and consume those new-fangled web-services and
> > whatnot. Heck, maybe even code games using DirectX.
>
> DrScheme for the first. Oh...well, there's loads of OpenGL support if
> you can bear using that instead of DirectX. If you want CL, cl-opengl
> and cells-gtk seem to work well.
>

Actually, that was an example. I'd rather use OpenGL, but sometimes you
are requested to do otherwise.

As soon as I get some free time, I'm going to play with them.


> > So, how would I do that? For Python, that was simple. I learned the
> > basics, then moved to the libraries, learning as I went. Python has
> > some excelent online resources.
>
> http://www.gigamonkeys.com/book/ (Practical Common Lisp)
> http://www.paulgraham.com/onlisp.html (On Lisp)
> http://www.htdp.org/ (HTDP)
> http://mitpress.mit.edu/sicp/ (SICP)
> http://schemecookbook.org/
> http://www.cliki.net/index
> (Note: I mixed Scheme and CL pages above)
>

It will take some time, but I'll take a look at those.


> You're welcome to use things like first, rest, or second instead of
> car, cdr, or cadr, but I always find the latter easier (car and cdr are
> composable, and remind you that you're using cons cells). What other
> mnemonics are there? I guess cons, but that shouldn't be hard...

I think they are too cryptic for no reason. Then again, that's the sort
of thing that disappears with usage.

> On the other hand, Python has no 3-letter words. *struck dead by a
> flying "def"*

There's len, and a couple more built-ins. But at least they've got
proper names :P


Stephen

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

How to upload a file

[Lad]

Users needs to upload big files upto 100MB.So I think that FTP protocol
would be a solution, but how can I allow users to select the right file
,on their  local disk, via a file dialog ?

Thank you for your ideas
L.

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

Re: Emulate @classmethod using decorator and descriptor

[Dustan]

WaterWalk wrote:
> Hello, I was recently learning python decorator and descriptor and
> emulated a @classmethod decorator:
> class EmuClassMethod(object):
> def __init__(self, f=None):
> self.f = f
> def __get__(self, obj, klass=None):
> if klass is None:
>klass = type(obj)
> def  wrapped(*args):
>return self.f(klass, *args)
> return wrapped
>
> class Test(object):
> @EmuClassMethod
> def t(cls):
> print "I'm %s" % cls.__name__
>
> It worked, and seems that a function decorator works as follows:
> # decf is a decorator
> @decf
> def func():
> print 'func'
>
> will be "converted" to:
>
> def func():
> print 'func'
> func = decf(func)
>
> Is this really the case? Or correct me if i'm wrong. Thanks in advance.

Yes, the two are equivalent. The documentation is found here:
http://docs.python.org/ref/function.html

But I personally found the explanation for decorators a bit confusing.

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

py-ldap question

[Laszlo Nagy]

 Hello,

I'm using the ldap module under Windows. This is the error that I get:

import ldap
l = ldap.initialize("ldaps://neptunus.msnet:636")
l.simple_bind_s("cn=gandalf,ou=Users,dc=neptunus,dc=msnet","gandalf")
l.search_s("ou=AddressBooks,dc=neptunus,dc=msnet", ldap.SCOPE_SUBTREE, 
"objectclass=inetOrgPerson")


Traceback (most recent call last):
  File 
"T:\developer20\knowledgebase\FreeBSD\Thunderbird_OpenLDAP_AddressBook\working\05\example.py",
 
line 3, in ?
l.simple_bind_s("cn=gandalf,ou=Users,dc=neptunus,dc=msnet","gandalf")
  File "C:\Python24\Lib\site-packages\ldap\ldapobject.py", line 175, in 
simple_bind_s
msgid = self.simple_bind(who,cred,serverctrls,clientctrls)
  File "C:\Python24\Lib\site-packages\ldap\ldapobject.py", line 169, in 
simple_bind
return 
self._ldap_call(self._l.simple_bind,who,cred,serverctrls,clientctrls)

  File "C:\Python24\Lib\site-packages\ldap\ldapobject.py", line 94, in 
_ldap_call
result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'info': 'error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc': 
"Can't contact LDAP server"}

I think that I need to specify to the openldap client to trust the 
server's certificate. The problem is that the ldap module bundles the 
openldap-client implementation, and there is no ldap.conf file (or at 
least I cannot find it). So how can I configure it to trust my server's 
certificate?

Thanks,

   Laszlo

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

Re: About alternatives to Matlab

[Ramon Diaz-Uriarte]

On 12/12/06, Jon Harrop <[EMAIL PROTECTED]> wrote:
> Paul Rubin wrote:
> > Well, work is already under way (already mentioned) to implement
> > Python in Python, including a reasonable compiler (Psyco).
> >
> > The big deficiency of MLton from a concurrency perspective is
> > inability to use multiprocessors.  Of course CPython has the same
> > deficiency.  Same with OCaml.  Is the ML community trying to do
> > anything about this?
>
> Yes. Several MLs support concurrency. Perhaps F# is the most notable in this
> case because it would provide an easier path to JIT (to .NET IL).
>
> Concurrent GC seems to be a lot slower though (e.g. Java or .NET vs OCaml or
> MLton).
>

Would this be of any interest? (specially since the Lisp vs. Python
thread seems to be dying out :-). Its Scheme (Gambit, so one of the
speedy Schemes) with Erlang-like concurrency

http://toute.ca/
http://lambda-the-ultimate.org/node/841


Best,

R.

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


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

[Paul Rubin]

Pascal Costanza <[EMAIL PROTECTED]> writes:
> You can start with loop by using only the simple and straightforward
> constructs, and slowly move towards the more complicated cases when
> necessary. The nice thing about loop is that with some practice, you
> can write code that more or less reads like English.

Yeah, but I'd also get English-like imprecision.  Anyway, If I wanted
to write code that reads like English, I'd write in Cobol.  

> All Common Lisp implementations that I am aware of provide ways to
> enable TCO, so it's definitely possible to program in a functional
> style if you want to. It's just that the ANSI Common Lisp
> specification doesn't guarantee this,

Yes; I'd rather go by what the standard says than rely on
implementation-dependent hacks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py-ldap question

[Laszlo Nagy]

By the way, I already tried the set_option function, but I still get the 
same error.


import ldap
import local

ldap.set_option(ldap.OPT_X_TLS_ALLOW,1)
ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT,0)
ldap.set_option(ldap.OPT_X_TLS_CERTFILE,local.LDAP_CACERTFILE)
ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,local.LDAP_CACERTFILE)

def getnewconnection(logindc,password):
conn = ldap.initialize(local.LDAP_SERVER_URL)
conn.simple_bind_s(logindc,password)
return conn

if __name__ == '__main__':
conn = getnewconnection(local.LDAP_MANAGER_DC,local.LDAP_MANAGER_PWD)
print conn
 


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

Re: Python Plugin for Web Browser

[Sébastien Ramage]

pour ceux que ça intéresse

http://base.google.com/base/a/1438658/D18001067256043490325

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

Re: About alternatives to Matlab

[Konrad Hinsen]

On Dec 11, 2006, at 14:21, Jon Harrop wrote:

> F# runs under Linux with Mono.

Well, then it should also run on my Mac... Do you have any experience  
with performance of numerical code under Mono, or, for that matter,  
under .NET? I suspect that the JIT compilers were not written with  
number crunching in mind, but perhaps I am wrong.

Konrad.
--
-
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: [EMAIL PROTECTED]
-


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

Re: merits of Lisp vs Python

[Pascal Costanza]

Paul Rubin wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
>> You can start with loop by using only the simple and straightforward
>> constructs, and slowly move towards the more complicated cases when
>> necessary. The nice thing about loop is that with some practice, you
>> can write code that more or less reads like English.
> 
> Yeah, but I'd also get English-like imprecision.  Anyway, If I wanted
> to write code that reads like English, I'd write in Cobol.  

That's the neat thing in Lisp: You can stay in Lisp if you want to write 
code in a different style. No need to switch your whole tool chain.

>> All Common Lisp implementations that I am aware of provide ways to
>> enable TCO, so it's definitely possible to program in a functional
>> style if you want to. It's just that the ANSI Common Lisp
>> specification doesn't guarantee this,
> 
> Yes; I'd rather go by what the standard says than rely on
> implementation-dependent hacks.

You shouldn't limit yourself to what some standard says.


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: paramiko public key

[hg]

[EMAIL PROTECTED] wrote:

> paramiko
http://www.lag.net/paramiko/docs/

__str__ ?


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

Re: merits of Lisp vs Python

[Ken Tilton]

Pascal Costanza wrote:
> Paul Rubin wrote:
> 
>> Pascal Costanza <[EMAIL PROTECTED]> writes:
>>
>>> May you have tried the wrong Lisp dialects so far:
>>>
>>> (loop for i from 2 to 10 by 2
>>>do (print i))
>>
>>
>> The loop language is so complicated and confusing that I never
>> bothered trying to learn it.

That was my stance for about seven years of intense Lisp. Then the 
author of Practical Common Lisp did a nice job of breaking the whole 
mess up into sensible chunks and I picked it up. If one programs Lisp, 
one should learn Loop -- it is definitely worth the bother. I def regret 
not learning it sooner.

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: Sorting Multidimesional array(newbie)

[Robert Kern]

Fredrik Lundh wrote:
> also note the OP didn't specify what to do for records where the first 
> column was identical, so I guess a plain sort() call, without any custom 
> compares or mappings, would work as well as the fancier alternatives...

If the OP had lists of lists, yes. However, he seems to be using one of (numpy,
numarray, Numeric). Because of rich comparisons, just using sorted() won't work.
The cheap and cheerful approach would be to convert to lists of lists using
.tolist(), .sort() the list, and then reconstruct the array object. Depending on
the size of the array, that may be just fine.

numpy (and maybe numarray, I'd have to check) has a function lexsort(), which
unfortunately has a confusing interface.


In [2]: lexsort?
Type:   builtin_function_or_method
Base Class: 
Namespace:  Interactive
Docstring:
lexsort(keys=, axis=-1) -> array of indices. argsort with list of keys.

Return an array of indices similar to argsort, except the sorting is
done using the provided sorting keys.  First the sort is done using
key[0], then the resulting list of indices is further manipulated by
sorting on key[1], and so forth. The result is a sort on multiple
keys.  If the keys represented columns of a spreadsheet, for example,
this would sort using multiple columns (the last key being used for the
primary sort order, the second-to-last key for the secondary sort order,
and so on).  The keys argument must be a sequence of things that can be
converted to arrays of the same shape.


This is the idiomatic way to lexicographically sort an array by columns
equivalent to the .tolist() approach I give above. I usually wrap lexsort() with
these operations so my brain doesn't explode.


In [15]: from numpy import *

In [16]: a = array([[5, 2], [1, 3], [1, 2]])

In [17]: a[lexsort(keys=a.transpose()[::-1])]
Out[17]:
array([[1, 2],
   [1, 3],
   [5, 2]])

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: merits of Lisp vs Python

[Ken Tilton]

Paul Rubin wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
> 
>>You can start with loop by using only the simple and straightforward
>>constructs, and slowly move towards the more complicated cases when
>>necessary. The nice thing about loop is that with some practice, you
>>can write code that more or less reads like English.
> 
> 
> Yeah, but I'd also get English-like imprecision.  Anyway, If I wanted
> to write code that reads like English, I'd write in Cobol.  

That was my stance until 

There /is/ a second Lispy syntax for LOOP, btw. But the goofier syntax 
is also where lies part of the "win", so learn that.

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: problem while going through a tutorial

[Ralf Schönian]

Simon Schuster schrieb:
[..]
 x = "fljshfjh"
 x
> 'fljshfjh'
 count(x, 'h')
> Traceback (most recent call last):
>  File "", line 1, in ?
> NameError: name 'count' is not defined
> 
> I'm not sure what changed, because it used to work. anyhow thanks a lot!

You forgot to import the string module:
from string import *

Regards,
Ralf Schoenian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What are python closures realy like?

[Roy Smith]

John Nagle <[EMAIL PROTECTED]> wrote:
> Most of the examples given here are kind of silly, but closures have
> real uses.  I used one today in Javascript because I was writing an
> AJAX application, and I was using an API, the standard XMLHttpRequestObject,
> which required a callback function with no arguments.  A closure allowed
> the code to pass relevant information with the callback function, which
> would be called when a request to the server completed.  A global
> variable wouldn't have worked, because multiple instances of the object
> making the callback are possible.

As another example, from a large C++ project I'm currently working on, we 
use closures in many places to push actions onto queues.

One kind of queue we have is a timed queue.  You push a closure and a time 
onto it, and it executes the closure at the appointed time.  Another kind 
of queue is for inter-thread communication.  You push a closure onto a 
thread's input queue when you want it to do something.  The thread just 
keeps popping closures off the other end of the queue and executing them.

Think of a closure as a way of saying "do this".  You can say, "At 5:00, do 
this", or "Do this as soon as you get a chance".

# pseudocode
class husband (spouse):
   def pickUpGroceries():
  etc
   def addToQueue():
  etc

c = makeClosure (husband.pickUpGroceries, [milk, eggs, bread])
h = husband()
h.addToQueue (c)
-- 
http://mail.python.org/mailman/listinfo/python-list

Updating variables indirectly

[Tommy Grav]

I have a little problem that look something like this:

Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class test: pass
...
>>> test.a = 1
>>> test.b = 2
>>> for x in [test.a,test.b]:
...   x = x + 1
...
>>> print test.a
1
>>> print test.b
2
>>>

However, what I am after is a way to increment the variables in the  
list,

e.q. I want test.a to be 2 and test.b to be 3.

Is there a way of doing this?

Cheers
   Tommy

[EMAIL PROTECTED]
http://homepage.mac.com/tgrav/

"Any intelligent fool can make things bigger,
more complex, and more violent. It takes a
touch of genius -- and a lot of courage -- to
move in the opposite direction"
 -- Albert Einstein




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

Re: How to do a Http HEAD requests

[Gerard Flanagan]

Soni Bergraj wrote:

> Hello list,
> I was just wondering if there is a more convenient way of doing a Http
> HEAD requests then the socket module?
>
> Any ideas?

I recently used this:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286225

Gerard

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

Re: Tkinter button doesn't appear in OS X

[Kevin Walzer]

crystalattice wrote:
> Kevin Walzer wrote:
>> What version of Tk are you running? I've seen this bug on old versions
>> of Tk (i.e. 8.4.7) but not recently.
>>
>> --
>> Kevin Walzer
>> Code by Kevin
>> http://www.codebykevin.com
> 
> I'm using Python 2.4.2, which I believe is the default version for OS
> X.  How do I check the Tk version?  Can I force my programs to use a
> different version of Python, e.g. if I installed Python 2.5?
> 
When you run your program on OS X, there should be a menu item next to
the Apple menu that says "about Tcl/Tk," which you access from the
"Python" menu item. That will give you the version number.

Python 2.3.5 and Tcl/Tk 8.4.7 ship with OS X 10.4. Python 2.4.2 is a
separate installation, but probably accesses the system Tcl/Tk unless
you have installed a more recent version. Using the official Mac build
of Python 2.5 will update your Python, but not Tcl/Tk--you'll need to
install something more recent.

You can install ActiveTcl for a "batteries-included" distro of
Tcl/Tk--it has the latest and greatest of everything. Or, you can
install a slightly older (8.4.13) version of Tcl/Tk at
http://tk-components.sourceforge.net. (This is a version of Tcl/Tk Aqua
that I use in my own programs and I made the build available for others
to use.)

Hope that helps,
Kevin

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

Re: merits of Lisp vs Python

[Jon Harrop]

Stephen Eilert wrote:
> So, let's suppose I now want to learn LISP (I did try, on several
> occasions). What I would like to do would be to replace Python and code
> GUI applications. Yes, those boring business-like applications that
> have to access databases and consume those new-fangled web-services and
> whatnot. Heck, maybe even code games using DirectX.
> 
> So, how would I do that?

You may also be interested in related languages. I've written several
interesting programs in OCaml:

  http://www.ffconsultancy.com/free/ocaml/examples.html
  http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation

More recently, I've been writing F# examples:

  http://www.ffconsultancy.com/dotnet/fsharp

You can probably translate the F# demos into a Lisp for .NET without too
much difficulty.

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

[Rob Thorpe]

Paul Rubin wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:

> Yes; I'd rather go by what the standard says than rely on
> implementation-dependent hacks.

But in that case what do you call Python?  The whole language has no
standard - is it an "implementation dependent hack"?

Standards are useful, but they are not the beginning and end of
programming.

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

Re: How to do a Http HEAD requests

[Fredrik Lundh]

Soni Bergraj wrote:

> I was just wondering if there is a more convenient way of doing a Http
> HEAD requests then the socket module?

quick version:

>>> import urllib2
>>> request = urllib2.Request("http://www.python.org";)
>>> request.get_method = lambda: "HEAD"
>>> http_file = urllib2.urlopen(request)
>>> http_file.headers

>>> http_file.headers["content-type"]
'text/html'
>>> print http_file.headers
Date: Tue, 12 Dec 2006 14:33:08 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) DAV/2 SVN/1.1.4 mod_python/3.1.3 Python
/2.3.5 mod_ssl/2.0.54 OpenSSL/0.9.7e
Last-Modified: Tue, 12 Dec 2006 07:04:52 GMT
ETag: "61b82-2fd2-e60f4d00"
Accept-Ranges: bytes
Content-Length: 12242
Connection: close
Content-Type: text/html

 



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

Re: comparing two IP addresses and the underlying machine

[Tim Chase]

 > I've been trying to figure this one out for some time but
 > with no success.  I have a machine with two network
 > interfaces, each with their own IP address and it's own
 > domain, for example:
 > - ipA on machineA.domainA
 > - ipB on machineB.domainB
 >
 > Given any pair of IPs or hostnames (or a mix of them), how
 > can I figure whether they belong to the same physical
 > machine or not? Of course, this is trivial if my python
 > program is running the given machine but what if a remote
 > machine is trying to figure this out (but that machine has
 > access to both domains/IPs).
 > Appreciate and ideas.


I have a feeling that you're trying to attempt the
impossible.  What do you mean by "the same physical
machine"?  The same case?  What happens if there are two
virtual OSes on the machine, each using its own NIC?

Unless you have a client application running on "the
physical machine" that can respond to queries on each NIC,
you're pretty much out of luck.  You could write something
like a "same_ping" program that would listen on both NICs,
and respond with a "yeah, I'm the same machine"
confirmation.  There are all sorts of ways to do this,
depending on how sure you need to be that nobody can spoof
it...ranging from simple "here's a random number on one IP
address followed by asking the other IP if it's seen that
random number before" to having the physical machine sign
one request on each port and confirm that their signatures
are the same.

-tkc




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

Re: Inheritance doesn't work

[Fredrik Lundh]

John Salerno wrote:

> Well, I can't say I was surprised, but my main (subtle, understated,
> sneaky) point was how do you expect anyone to help you when you aren't
> even giving us the proper information that produces the error?

I've stopped trying to make that point; I just apply a basic error correction
algorithm to the posted code, and try to make sense of the result.  sometimes
it misfires (e.g. if there are multiple errors in the code), but it usually 
gets me
pretty close to the actual issue.

 



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

Re: merits of Lisp vs Python

[Alexandre Vassalotti]

"There are only two kinds of languages: the ones people complain about
and the ones nobody uses" -- Bjarne Stroustrup

http://www.googlefight.com/index.php?word1=%22Python+sucks%22&word2=%22Ruby+sucks%22

According to the rule, Python is more popular. On the other side, Java
squashes us. 
(http://www.googlefight.com/index.php?word1=%22Python+sucks%22&word2=%22Java+sucks%22)

And by the way, I think we need alt.religion.lisp.

On 12/11/06, Ken Tilton <[EMAIL PROTECTED]> wrote:
> You missed it? Google fight:
>
>http://www.googlefight.com/index.php?lang=en_GB&word1=Python&word2=Ruby
>
> Python wins, 74 to 69.3. And there is no Monty Ruby to help.

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

Re: merits of Lisp vs Python

[Jon Harrop]

Michael Livshin wrote:
> Paul Rubin  writes:
>> Nobody seems to concerned that Haskell lacks macros.  What's up with
>> that?
> 
> Haskell is lazy, so it doesn't need macros

Outside Lisp, macros are for syntax. Evaluation semantics (e.g. lazy
evaluation) then have nothing to do with macros.

So Haskell being lazy doesn't obviate macros. You might still want to extend
the syntax of Haskell, i.e. want macros. However, this is much less
desirable than Lisp because Haskell already provides a wealth of powerful
features and related syntax (e.g. pattern matching, comprehensions). I
think this is an important point often missed by Lispers.

> lazyness has a nontrivial cost, however, both runtime and cognitive.

The main problem with lazy evaluation is unpredictable memory use.

-- 
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: How do I edit a PythonWin path to import custom built modules???

[BartlebyScrivener]

Gabriel Genellina wrote:
>
> There was an error in a previous post, you should create a variable
> called PYTHONPATH, not change the system PATH.
> Or, group your modules into packages and put them below
> lib\site-packages.
>

Perhaps your way works also, but I have no PythonPath defined in system
variables on Windows XP.

I keep my Python scripts and modules in d:\Python. I added d:\Python to
the Path variable and I can call and import the scripts and modules
from anywhere I please.

I'm pretty sure that the ActiveState distribution of Python adds its
paths to the Path variable also.

rd

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

Re: merits of Lisp vs Python

[Jon Harrop]

Pascal Costanza wrote:
> Paul Rubin wrote:
>> Yes; I'd rather go by what the standard says than rely on
>> implementation-dependent hacks.
> 
> You shouldn't limit yourself to what some standard says.

You shouldn't ignore previous work and standards can embody decades of
programming language research.

-- 
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: os.popen3 hangs in Windows XP SP1, SP2. Python 2.5 & 2.4. Consistent test case.

[Thomas Guettler]

Pierre Rouleau wrote:

> Hi all,
>
> I have a consistent test case where os.popen3() hangs in Windows.  The
> system hangs when retrieving the lines from the child process stdout.
> I know there were several reports related to os.popen3() hanging under
> Windows in this group before.

I had a problem like this some time ago. But it was a problem that
would happen under any operating system.

If there is output on stdout and stderr, you will get a dead lock sooner
or later.

Example: The childprocess tries to write to stderr, and the
parent process reads from stdin. The buffer of stderr will
get full. The child will block. The parent will wait for ever.

See http://docs.python.org/lib/popen2-flow-control.html

My hint: Always use popen4

You can get dead locks with popen4, too. But only if you
write to pipe.tochild.

  Thomas

-- 
Thomas Güttler, http://www.thomas-guettler.de/ http://www.tbz-pariv.de/
E-Mail: guettli (*) thomas-guettler + de
Spam Catcher: [EMAIL PROTECTED]

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

RE: wxPython, dynamically modify window

[Bell, Kevin]

I think that you'll just need to change the frame size property when you
hit your checkbox...



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Grant
Sent: Tuesday, December 12, 2006 12:02 AM
To: python-list@python.org
Subject: wxPython, dynamically modify window

Hi, I am looking for a tip.  I have a panel and a checkbox.  When I 
check the checkbox, I would like to add buttons to the panel 
(dynamically).  When the checkbox is unchecked, the buttons should not 
appear (be deleted)---all the while, the window should resize if
necessary.

If you have a simpler example, that is fine.  I just need a hint as to 
how you dynamically change the widgets and their layouts.

Looking at the wx demos, there is something close wx.lib.expando, but 
this is just modifying a particular widget.

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

Sybase module 0.38pre1 released

[Sébastien Sablé]

WHAT IS IT:

The Sybase module provides a Python interface to the Sybase relational
database system.  It supports all of the Python Database API, version
2.0 with extensions.

MAJOR CHANGES SINCE 0.37:

* This release works with python 2.5

* It also works with sybase 15

* It works with 64bits clients

* It can be configured to return native python datetime objects

* The bug "This routine cannot be called because another command
structure has results pending." which appears in various cases has
been corrected

* It includes a unitary test suite based on the dbapi2.0 compliance
test suite
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[André Thieme]

Paul Rubin schrieb:
> André Thieme <[EMAIL PROTECTED]> writes:
>>> import module
>>> module.function = memoize(module.function)
>> Yes, I mentioned that a bit earlier in this thread (not about the
>> "during runtime" thing).
>> I also said that many macros only save some small bits of code.
>> Your python example contains 4 tokens / brain units.
>> The Lisp version only has 2.
> 
> You shouldn't count the import statement, since you'd need the
> equivalent in Lisp as well.

I didn't count it.

1P) module.function
2P) =
3P) memoize(
4P) module.function)

vs
1L) (memoize
2L) function)

I counted 1P and 4P only as one (each) although it should have been 2
for each. But it would have worked too if we didn't need the "module.":
function = memoize(function).



> Contrast the much more common
> 
>   a[i] = b[n]
> 
> with
> 
>   (setf (aref a i) (aref b n))
> 
> and the attractions of Python may make more sense.

Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in Python
one has to write less since "[]" are 2 chars while "aref" are 4, plus
the setf.
But from counting the brain units which I regard as an important factor
they are both equal.


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

Re: merits of Lisp vs Python

[Jon Harrop]

jayessay wrote:
> Fair enough.  But really, I don't see any of these things as
> particularly "modern" (whatever that means) or groundbreaking.
> Certainly not at this point.

Performance and type theory are modern in the context of FPLs. Both have
been retrofitted to Lisp with varying results.

> Also, there is the issue of whether there even is a "continual
> progression", as in "moving up some ladder" towards something
> "better", in the context of programming languages.  All of that is
> pretty fuzzy stuff, and plenty of CogSci work has shown these value
> judgements in this context to be less than obvious in any meaning.

If you look over a long period of time (e.g. back to the last major change
to Lisp) then language research has had clear overall directions.

> There is also a question about "old/new" wrt these value judgements.
> Since Lisp is (admittedly some hand waving here) more or less lambda
> calculus embodied, is it closer to say The Calculus or Group Theory
> than to some random piece of technology?[1] If Lisp is "old
> fashioned", then The Calculus and Group Theory are like _really_ old
> fashioned.  But does that lessen them in some way?  What would that
> be?  Is some random "new" technique (say brute force iterative
> techniques for calculus problems with computers) somehow "better"?

Again, just read research papers to learn what's new.

For example, we're going multicore whether you like it or not, so concurrent
GCs will become much more important over the next few years. F# adds that
to OCaml. That's new and its better.

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

[Jon Harrop]

Paul Rubin wrote:
> Are there any Lisp devotees who have done serious development in ML?

There is a disproportionately small overlap between the Lisp/Scheme and
ML/Haskell communities. They are probably of comparable size at the moment.
I believe the difference is largely geographical.

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

Reference to base namespace in a class.

[David]

Hi,
I'm working on a project where we're juggling with two potential
implementations.
In the two scenarios, we create objects in the base namespace. These
objects are interdependent, in the sense that to compute something,
they have to look up the value of the other objects (their parents).
The objects are functions, by the way, with some additional attributes.


In the first scenario, as the objects are created, they immediately
share references and can call each other's value. All these objects are
then referenced in a class that defines some methods accessing those
objects. The advantage is that you can call the functions from the base
namespace and they'll know where to look to make the computations. The
downsize is that if you delete one object by mistake, nothing works
anymore, that is, the methods from the class will no longer reference
the right objects.

In the second scenario, as the objects are created, they only know the
name of their parents, and don't have their actual reference. To
compute something, we have to pass the values of the other objects
explicitely. A class is then instantiated, where we look up the
__main__ dictionary for the names of the parents given by each
function, copy the objects inside the class, create an attribute for
each object on the fly and link the objects together using the parents
names.  The advantage is that even if an object in the base namespace
is destroyed, the class methods will still work since the references
are all internal to the class instance.  The disadvantage is that the
objects in the base namespace are dummy objects, ie they don't speak to
each other.

I guess it's hard to understand the context from this quick
description, but the code would look equally opaque.

Here is an attempt to put that into a simple question:

Are there counter indications to reference objects in the base
namespace from a class ?

Thanks for your help. 

David Huard

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

Re: oo problem

[Tool69]

Dennis Lee Bieber a écrit :

> On 10 Dec 2006 03:47:21 -0800, "Tool69" <[EMAIL PROTECTED]>
> declaimed the following in gmane.comp.python.general:
>
> > Thanks for your answers,
> > I though about the first solution too, but I've redundant code, say ie:
> > p = Paper(100,200)
> > p.draw( Rectangle(p,10,20,50,60) ) <-- we're forced to write 'p' two
> > times.
> >
>
>   I'd suggest not passing an instance initialization to your "Paper"
> draw() method...
>
> p = Paper(100, 200)
> p.add(Rectangle(10, 20, 50, 60))
> p.add(OtherPrimitives())
> p.draw()
>
> where p.draw() (Paper.draw(self) really) does something like:
>
>   self.whatever_is_needed_for_Paper_itself
>   for prm = self.primitives:  #list of stuff from p.add(...) calls
>   prm.draw(self)  #pass current paper to the 
> primitive
>   #which draws 
> itself on the paper
>   #and can do 
> whatever calculations
>   #(CLIPPING 
> perhaps) needed

Thanks for all your comments and suggestions.
Denis, I would like to know how I can made a draw method for a
primitive without a Paper instance inside ...that's always the same
problem as only my Paper instance knows the Paper sizes !

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

Embedding a shell / editor in a wxPython application

[hg]

Hi,

Are there modules out there (ex: scintilla for editor ...) ?

Thanks

hg

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

Validate XML against a set of XSD files, with Python

[Laszlo Nagy]

Do you know an open source lib that can do $subject?

Thanks,

   Laszlo

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

Re: About alternatives to Matlab

[Jon Harrop]

Konrad Hinsen wrote:
> Well, then it should also run on my Mac... Do you have any experience
> with performance of numerical code under Mono, or, for that matter,
> under .NET? I suspect that the JIT compilers were not written with
> number crunching in mind, but perhaps I am wrong.

Actually, F# seems to be very fast for array-based floating-point
calculations. From the timings I gave earlier in this thread, for example,
it is between C++ and OCaml.

F# (actually .NET) seems to be slower for GC intensive programs, like my ray
tracer. I suspect this is because a concurrent GC is inherently slower. I
haven't benchmarked this in detail but F# seems to be 2-4x slower than
OCaml here.

-- 
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: object data member dumper?

[George Sakkis]

tom arnall wrote:
> >object data member dumper?
> >George Sakkis george.sakkis at gmail.com
> >Wed Nov 8 03:42:47 CET 2006
>
> > tom arnall wrote:
> >
> > > Bruno Desthuilliers wrote:
> > >
> > > > tom arnall a écrit :
> > > >> does anyone know of a utility to do a recursive dump of object data
> > > >> members?
> > > >>
> > > >
> > > > What are "object data members" ? (hint: in Python, everything is an
> > > > object - even functions and methods).
> > > >
> > > > What is your real use case ?
> > >
> > > something like:
> > >
> > >class A:
> > >   def __init__(self, p1):
> > >  self.p1 = p1
> > >
> > >class B:
> > >   def __init__(self,p1, p2):
> > >  self.a = A(p1)
> > >  self.p2 = p2
> > >  self.v1 = '3'
> > >
> > >class C:
> > >   def __init__(self):
> > >  self.b = B(3,4)
> > >  self.p3 = 5
> > >
> > >class D:
> > >   def __init__(self):
> > >  self.v2=2
> > >  self.o1 = C()
> > >  self.o2 = B(11,12)
> > >
> > >
> > >d = D()
> > >objectDataDumper(d)
> > >
> > >
> > > would produce something like:
> > >
> > >object of class D with:
> > >o1(C)->b(B)->a(A)->p1=3
> > >o1(C)->b(B)->p2=4
> > >o1(C)->b(B)->v1=3
> > >o1(C)->p3=5
> > >o2(B)->a(A)->p1=11
> > >o2(B)->p2=12
> > >o2(B)->v1=3
> > >v2=2
> > >
> > >
> > > tom arnall
> > > north spit, ca
> > > usa
> >
> > At first I thought pickle would be what you're looking for, because
> > that's exactly what it does; it dumps arbitrary objects, without
> > choking on recursive references. Only problem is, it's not human
> > readable (even in its ascii form).If you want it to be human readable,
> > you may check the gnosis.xml.pickle module
> > (http://cheeseshop.python.org/pypi/Gnosis_Utils/1.2.1-a). That's the
> > output of gnosis.xml.pickle.XML_Pickler(d).dumps() on your example:
> >
> > 
> > 
> > 
> > 
> >  > class="B">
> >> class="A">
> > 
> >   
> >   
> >   
> > 
> >  > class="C">
> >   
> >> class="B">
> >  > class="A">
> >  
> > 
> > 
> > 
> >   
> > 
> > 
> >
> >
> > I've also written a similar but less verbose xml dumper. The gnosis.xml
> > package provides a bidirectional mapping between objects and xml
> > (objects -> xml and xml->object) and therefore has to be precise; mine
> > simply generates a nice xml dump of the object which isn't necessarily
> > reversible. Here's the output for your example:
> >
> > 
> >   
> > 
> >   
> > 3
> >   
> >   4
> >   3
> > 
> > 5
> >   
> >   
> > 
> >   11
> > 
> > 12
> > 3
> >   
> >   2
> > 
> >
> >
> > If you find it suits you better, I'll try to make it available
> > somewhere (probably in the cookbook).
> >
> > George
> >
>
>
>  George,
>
>  did you ever put up your object dumper on the net?

Here it is: http://rafb.net/paste/results/C0NHBp27.html
Mostly undocumented but works for most common types. Most methods are
overridable so you can customize the dumping for a specific type (or
types) in a subclass.

George

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

Re: merits of Lisp vs Python

[Christophe]

André Thieme a écrit :
> Paul Rubin schrieb:
>> André Thieme <[EMAIL PROTECTED]> writes:
 import module
 module.function = memoize(module.function)
>>> Yes, I mentioned that a bit earlier in this thread (not about the
>>> "during runtime" thing).
>>> I also said that many macros only save some small bits of code.
>>> Your python example contains 4 tokens / brain units.
>>> The Lisp version only has 2.
>>
>> You shouldn't count the import statement, since you'd need the
>> equivalent in Lisp as well.
> 
> I didn't count it.
> 
> 1P) module.function
> 2P) =
> 3P) memoize(
> 4P) module.function)
> 
> vs
> 1L) (memoize
> 2L) function)
> 
> I counted 1P and 4P only as one (each) although it should have been 2
> for each. But it would have worked too if we didn't need the "module.":
> function = memoize(function).

If you really need to : memoize('module.function') but it's ugly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Robert Uhl]

Mathias Panzenboeck <[EMAIL PROTECTED]> writes:
>
> I do not know much about Lisp. What I know is:
>
> Python is a imperative, object oriented dynamic language with duck
> typing, List is a declarative, functional dynamic language -> those
> two languages have different scopes.

Common Lisp is an object oriented language too, and while it has more
declarative features than Python, I don't think that it's really fair to
call it declarative in the same sense as, say, SQL.

Language-feature-wise, Lisp is a superset of Python: there's nothing one
can do in Python that cannot be done in Lisp, although there are some
things one would need to write oneself (e.g. generators) and some stuff
would be more of a pain (e.g. Python provides iterators, which means
that for can understand new objects; CL LOOP is not extensible, unless I
have missed something big, but it's simple enough to write a
map-new-object or loop-new-object or whatever).

Library-wise, Python is pretty much a superset of Lisp, and in fact many
of the things Lisp was criticised for providing as a standard part of
the language are also standard parts of Python.

-- 
Robert Uhl 
The problem with 'post-modern' society is there are too many people with
nothing meaningful to do, building 'careers' around controlling the lives of
others and generally making social nuisances of themselves.
 --Graham Strachan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jon Harrop]

André Thieme wrote:
> Well, macros are one (big) thing that Lisp has and which many other
> languages don't have. Their are other things too, and some of them are
> in Python as well, which is a very nice scripting language.

I think s-exprs and EVAL are the main things that Lisp has and that other
languages don't. Note that most other languages don't have these because
they were deemed to be a bad trade-off three decades ago. ;-)

> Often macros save just some bits of code. Saving one loc is not much you
> might say. But think about it the other way around.
> How would you like it to call doodleShooble() each time before you use
> the if statement? Of course you would not like it. The good thing about
> Lisp is, that you can eliminate this pattern.

You can eliminate that pattern with a HOF, of course. You don't need macros.

  let if' p e1 e2 =
doodleShooble();
force (if p then e1 else e2)

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

[Jon Harrop]

André Thieme wrote:
> I think you could do that with functional programming.
> You can protect the evaluation by encapsulating the args in a function
> object?
> 
> def f_Args(x):
>return x
> 
> def g_Args(x):
>return x
> 
> and then
> a = cond(test, f, g, f_Args(x), g_Args(x))
> 
> if you adopt cond. But of course it is getting ugly.
> So a macro can free you from this extra code.

Yes, that's just lazy evaluation. Again, you don't need macros.

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

[Paul Rubin]

"Rob Thorpe" <[EMAIL PROTECTED]> writes:
> > Yes; I'd rather go by what the standard says than rely on
> > implementation-dependent hacks.
> 
> But in that case what do you call Python?  The whole language has no
> standard - is it an "implementation dependent hack"?

This is one of my perpetual complaints about Python.  It does have a
reference manual and library manual, but these manuals are full of
gaps, and in practice one does go by the implementation.  CLTL2 is a
model of precision and thoroughness compared with any document that's
ever been written about Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Paul Rubin]

Ken Tilton <[EMAIL PROTECTED]> writes:
> >> The loop language is so complicated and confusing that I never
> >> bothered trying to learn it.
> 
> That was my stance for about seven years of intense Lisp. Then the
> author of Practical Common Lisp did a nice job of breaking the whole
> mess up into sensible chunks and I picked it up. If one programs Lisp,
> one should learn Loop -- it is definitely worth the bother. I def
> regret not learning it sooner.

I don't really code in Lisp any more, I never felt a need for loop
when I was coding in Lisp, and I'm trying to move towards a style of
programming without loops (i.e. I'm playing with Haskell, which
doesn't have loops), giving me even less need for a hairy loop macro.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Jon Harrop]

André Thieme wrote:
>> Contrast the much more common
>> 
>>   a[i] = b[n]
>> 
>> with
>> 
>>   (setf (aref a i) (aref b n))
>> 
>> and the attractions of Python may make more sense.
> 
> Here Python and Lisp are equal, 7 tokens vs 7 tokens, but in Python
> one has to write less since "[]" are 2 chars while "aref" are 4, plus
> the setf.

Why are you not counting Lisp's superfluous parentheses but you are counting
the brackets in the Python? I get 9 tokens for Python vs 13 for Lisp.

> But from counting the brain units which I regard as an important factor
> they are both equal.

Python is clearly more succinct in this case. I also think it is worth
counting chars or LOC as well as tokens. Lisp has unnecessarily long
built-in tokens...

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

[Robert Uhl]

Bjoern Schliessmann <[EMAIL PROTECTED]> writes:
>
>> 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?

Because it's the language for which indentation is automatically
determinable.  That is, one can copy/paste a chunk of code, hit a key
and suddenly everything is nicely indented.

-- 
Robert Uhl 
Flagrant system error!  The system is down.  I dunno what you did, 
moron, but you sure screwed everything up --Strongbad
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: comparing two IP addresses and the underlying machine

[Ratko Jagodic]

By the same physical machine I meant one OS using two interfaces and
multiple IP addresses mapped to different interfaces. I figured there
wouldn't be a direct solution to this so each time I will send all IP
addresses to the "match maker" so I can make comparisons and that should
work. Thanks for the help.

Ratko


On 12/12/06, Tim Chase <[EMAIL PROTECTED]> wrote:


> I've been trying to figure this one out for some time but
> with no success.  I have a machine with two network
> interfaces, each with their own IP address and it's own
> domain, for example:
> - ipA on machineA.domainA
> - ipB on machineB.domainB
>
> Given any pair of IPs or hostnames (or a mix of them), how
> can I figure whether they belong to the same physical
> machine or not? Of course, this is trivial if my python
> program is running the given machine but what if a remote
> machine is trying to figure this out (but that machine has
> access to both domains/IPs).
> Appreciate and ideas.


I have a feeling that you're trying to attempt the
impossible.  What do you mean by "the same physical
machine"?  The same case?  What happens if there are two
virtual OSes on the machine, each using its own NIC?

Unless you have a client application running on "the
physical machine" that can respond to queries on each NIC,
you're pretty much out of luck.  You could write something
like a "same_ping" program that would listen on both NICs,
and respond with a "yeah, I'm the same machine"
confirmation.  There are all sorts of ways to do this,
depending on how sure you need to be that nobody can spoof
it...ranging from simple "here's a random number on one IP
address followed by asking the other IP if it's seen that
random number before" to having the physical machine sign
one request on each port and confirm that their signatures
are the same.

-tkc





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

Re: merits of Lisp vs Python

[Jon Harrop]

Bill Atkins wrote:
> Despite its dynamism, Lisp is quite compilable.  For example, I can
> redefine classes, functions, macros, etc. at runtime and compiled code
> referring to the old code will still work.  You are conflating
> dynamism with interpretedness, and that's incorrect.

There is clearly a trade-off. Look at my ray tracer benchmark, for example:

  http://www.ffconsultancy.com/free/ray_tracer/languages.html

The static languages are significantly faster.

I think Python can hope to be as fast as SBCL-compiled Lisp, after a huge
amount of work on Python compilers, but it will never be as fast as the
compiled static languages.

On that ray tracer, Python might be able to approach OCaml's brevity but it
will be orders of magnitude slower as long as it is interpreted. Compiling
Python to a decent bytecode might give better performance, but OCaml
bytecode is 30x slower than native code on this benchmark.

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

[Pillsy]

Ken Tilton wrote:
[...]
> That was my stance for about seven years of intense Lisp. Then the
> author of Practical Common Lisp did a nice job of breaking the whole
> mess up into sensible chunks and I picked it up. If one programs Lisp,
> one should learn Loop -- it is definitely worth the bother. I def regret
> not learning it sooner.

When I first read PCL (which was my introduction to Lisp) I thought
LOOP was really neato. Once I actually started using it for things that
weren't so simple, I began to really hate it. I think that having a
specialized mini-language for iteration is a superb idea, but I don't
think LOOP is it.

That being said, there's a portable alternatives out there that I like
way better, and I still use LOOP for dashing stuff off one-liners at
the REPL. 

Cheers,
Pillsy

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

Re: About alternatives to Matlab

[Filip Wasilewski]

Jon Harrop wrote:
> Filip Wasilewski wrote:
> > Besides of that this code is irrelevant to the original one and your
> > further conclusions may not be perfectly correct. Please learn first
> > about the topic of your benchmark and different variants of wavelet
> > transform, namely difference between lifting scheme and dwt, and try
> > posting some relevant examples or use other topic for your benchmarks.
>
> Your lifting implementation is slightly longer and slower than the
> non-lifting one but its characteristics are identical. For n=2^25 I get:

Jon, both Python and Matlab implementations discussed here use the
lifting scheme, while yours is a classic convolution based approach.
These are two *different* algorithms for computing wavelet transforms.
Although they have similar names and give similar results, it does not
mean you can use them interchangeably in one benchmark! It just does
not make sense.

What's more, taking only very big input 'n' gives only very limited
information about true performance. How do you think who is faster, a
sprinter or a long distance runner? If you want to draw objective
conclusions about algorithm implementation you should measure timing
and memory usage characteristic for different input lengths. This will
also give you some idea about call overhead and possible memory
bandwidth influence. For example, the 4-tap db2 lifting transform
should be about 50% faster than the one using subband filtering. That's
theory. In practice, due to specific memory usage, the speedup gained
with reduction of number of arithmetic operations is easily wasted by
huge cache miss overhead (C implementation, measured on x86
architecture) for arrays which don't fit entirely in the CPU cache. See
my point?

> 1.88s C++ (816 non-whitespace bytes)
> 2.00s OCaml (741 b)
> 2.33s F# (741 b)
> 9.83s Your Python (1,002 b)
>
> The original python was 789 bytes.

Is the byte count a standard measure you apply to describe code
quality? I don't think you would be much happier to see totally
obfuscated golf one-liners.

> > Neglecting this issues, I wonder if it is equally easy to juggle
> > arbitrary multidimensional arrays in a statically typed language and do
> > operations on selected axis directly from the interactive interpreter
> > like in the NumPy example from my other post -
> > http://groups.google.com/group/comp.lang.python/msg/a71a5bf00a88ad57 ?
> > I don't know much OCaml so it would be great if you could elaborate on
> > this.
>
> It is probably just as easy. Instead of dynamic typing you have parametric
> polymorphism. If you want to make your function generic over arithmetic
> type then you can pass in the arithmetic operators.

Probably? Using the interactive interpreter, how can I easily create
two n-dimensional arrays of arbitrary data type, add them and multiply
by 17?

> >> In this specific context (discrete wavelet transform benchmark), I'd have
> >> said that speed was the most important thing after correctness.
> >
> > Not necessarily, if you are doing research with different kinds of
> > wavelets and need a general, flexible and easily adaptable tool or just
> > the computation speed is not considered a bottleneck.
>
> Brevity is probably next.

Memory usage, development time, cost, portability, scalability,
readability, level of abstraction, usage experience and many many
others, not necessarily in this order. I do not intend getting into
advocacy of any specific language or feature here. I just prefer fair
comparisons and clean use cases instead of marketing like that and I
don't believe anyone will buy your story about OCaml superior brevity
after seeing one fairly irrelevant loop with few arithmetic operations
as a killer argument.

> > Please don't make this discussion heading towards `what is the fastest
> > way of doing d4 transform and why OCaml rules` instead of `what is the
> > optimal way of doing things under given circumstances and still have a
> > free afternoon ;-)`.
>
> Comments like that seem to be based on the fundamental misconception that
> writing C++ like this is hard.

Not harder than writing a loop in bazillion of other languages. When
developing software do you only count time spent on typing because you
are idle during build process?

> Here's my complete OCaml:
...
> and C++:
> #include 
...

You didn't mention your platform and compiler settings. Using vector
at() method instead of plain C/C++ array indexing increases the timings
by factor of ~1.5 to 10 or more (GCC, MSVC), depending on the
optimizations set, so it doesn't seem to be the best possible solution.

I was also unable to run your OCaml example for n >= 2^21 (win32, out
of the box OCaml installation). Is there some 16MB memory limit imposed
on Array?
# let q = Array.make (1 lsl 21) 0.0;;
Exception: Invalid_argument "Array.make".

cheers,
fw

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

Re: How do I edit a PythonWin path to import custom built modules???

[Fredrik Lundh]

BartlebyScrivener wrote:

> Perhaps your way works also, but I have no PythonPath defined in system
> variables on Windows XP.
> 
> I keep my Python scripts and modules in d:\Python. I added d:\Python to
> the Path variable and I can call and import the scripts and modules
> from anywhere I please.

Python does *not* use the Path when searching for modules; sys.path is 
initialized based on the contents of PYTHONPATH, the location of the 
Python executable (or PYTHONHOME), some heuristics, and certain registry 
entries.  there used to be a page about this on python.org, but it seems 
to have disappeared; here's the SVN copy:

https://svn.python.org/www/trunk/pydotorg/windows/registry.ht



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

Re: One module per class, bad idea?

[Paddy]

On Dec 12, 8:29 am, "Matias Jansson"
<[EMAIL PROTECTED]> wrote:
> I come from a background of Java and C# where it is common practise to have
> one class per file in the file/project structure. As I have understood it,
> it is more common practice to have many classes in a Python module/file.
> What is the motivation behind it, would it be a bad idea to have a guideline
> in your project that promotes a one class per file structure (assuming most
> of the programmers a background similar to mine)?
Hi,
This is one of the cases where Java and C# common practice diverge from
Pythons.
You might try looking at the source to some of the standard modules to
see how things are done in Python.

- Paddy.

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

Re: merits of Lisp vs Python

[Robert Uhl]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
>
> 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.

Of course, you use prefix notation all the time in Python:

  for x in range(0,len(y)):
dosomething(x)

In the example, 'for,' 'range,' 'len' and 'dosomething' all use
prefix notation.  In Lisp the example might look like this, assuming the
proper functions and macros to make it work:

  (for ((x (range 0 (length y
 (dosomething x))

Slightly more idiomatic would be:

  (loop for x in (range 0 (length y))
do (dosomething x))

Even more idiomatic would be:

  (loop for x below (length y)
do (dosomething x))

Which doesn't seem particularly more or less prefixy or infixy than the
Python version.

Infix is really only used in arithmetic--and there are Lisp macros which
give one infix notation if wanted, so one could write:

  (infix 1 + x / 4)

-- 
Robert Uhl 
Give a man a fish and you feed him for a day; give him a freshly-charged
Electric Eel and chances are he won't bother you for anything ever again.
--Tanuki the Raccoon-dog
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: merits of Lisp vs Python

[Pascal Costanza]

Pillsy wrote:
> Ken Tilton wrote:
> [...]
>> That was my stance for about seven years of intense Lisp. Then the
>> author of Practical Common Lisp did a nice job of breaking the whole
>> mess up into sensible chunks and I picked it up. If one programs Lisp,
>> one should learn Loop -- it is definitely worth the bother. I def regret
>> not learning it sooner.
> 
> When I first read PCL (which was my introduction to Lisp) I thought
> LOOP was really neato. Once I actually started using it for things that
> weren't so simple, I began to really hate it. I think that having a
> specialized mini-language for iteration is a superb idea, but I don't
> think LOOP is it.
> 
> That being said, there's a portable alternatives out there that I like
> way better, and I still use LOOP for dashing stuff off one-liners at
> the REPL. 

If you hate LOOP then you don't have to use it.

There's an important lesson to learn here: Not all language constructs 
are supposed to be loved by everyone. ;)


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

[Petter Gustad]

Robert Uhl <[EMAIL PROTECTED]> writes:

> that for can understand new objects; CL LOOP is not extensible, unless I
> have missed something big, but it's simple enough to write a
> map-new-object or loop-new-object or whatever).

There is no standard way to extend loop, but most of the major vendors
let you extend it using add-loop-path. In CLSQL you can do stuff like

(loop for (time event) being the tuples of "select time,event from log"
  from *my-db*
  do ... )

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Can't register to CheeseShop at command line...only on web?!..

[[EMAIL PROTECTED]]

> > Here is what happens when I try to register at command line with
> > .pypirc above...
> >
> > Using PyPI login from /home/seb/.pypirc
> > Server response (401): Authorization Required
>
> Do you use a proxy to access the web?

Not that I'm aware of unless my job uses one without my knowing about
it.
If I am..is there a workaround for proxies?

cs

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

Re: merits of Lisp vs Python

[Robert Uhl]

"HowiPepper" <[EMAIL PROTECTED]> writes:

> I have checked out Lisp several times in the past, but I always get
> turned off completely by the parenthesis you have to use for
> everything.  What's up with that anyway?

It's no different from having to use newlines and spaces and square
brackets and parentheses in Python.  E.g. the Lisp (f x y) is exactly
equivalent to the Python f(x, y); the Lisp (if x y z) is exactly
equivalent to the Python:

  if x:
y
  else:
z

There is, though, an advantage: (f x y) and (if x y z) aren't just parts
of programs--they're also lists.  That means that one can use all the
list-manipulation primitives on a program, and thus that it's very easy
to write programs which manipulate programs.  This in turn leads to
being able to extend the syntax of the language.  Imagine if one could
write this in Python:

  defsyntax unless(condition, commands):
if not condition:
  commands

And use it like this:

  unless day == 'Sunday':
work()

That'd be pretty cool, right?  After all, 'unless day is Sunday' conveys
the sense of what you're doing a little better than 'if days is not
Sunday.'  But in Python it's not possible--even my defsyntax example is
absurd: how would the compiler know the difference between pre-colon
argument and the command block?  What if I wanted multiple blocks
(e.g. as with an else:)?

Whereas with Lisp one might simply write:

  (defmacro unless (condition &body commands)
 `(if (not ,condition)
  ,@commands))

When used as:

  (unless (equal day "Sunday")
  (work))

The compiler transforms it into:

  (if (not (equal day "Sunday"))
  (work))

This is a _really_ simple example (unless is nice, but it's hardly
vital); but what one can do is end up making a much more declarative
program by creating new syntax to describe stuff.

> With Python's ease of learning and use, availability of a large number
> of libraries, extremely active development community and large
> user-base, I'd say the question to ask is what specific advantages
> over Python does Lisp offer, to make people switch to it?

Well, these come to mind; they're in no order and are just my own
particular thoughts.  No doubt more reflective commentators can come up
with a better list.

o Macros

As mentioned above, macros can make one's life significantly nicer.  I
use Python a lot (it's currently a better choice than Lisp for many of
the problems I face), and I find myself missing macros all the time.
The ability to take some frequently-used idiom and wrap it up in a macro
is wonderful.  E.g. a common idiom in Python is:

  file = open(path, 'r')
  for line in file.readlines():
  foo(line)
  bar(line)
  baz(line)

Even this isn't much nicer:

  for line in open(path, 'r').readlines():
  foo(line)
  bar(line)
  baz(line)

Wouldn't it be nice to have a macro with-open-file?

  filefor line in path:
  foo(line)
  bar(line)
  baz(line)

o Speed

Lisp interpreters are several orders of magnitude faster than Python,
and Lisp compilers are faster yet.  Speed's not the most important
thing, but it is _an_ important thing; all other things being equal, the
faster solution is better.

o Symbols

In Lisp, a symbol is essentially a hashed string; two symbols are alike
if their names are alike, but comparison of symbols is a constant-time
operation.  Thus where in Python I have lots of string comparisons for
constants, and in C I have #defined integers, in Lisp I have symbols.
It's not just a performance hack--symbols are part of why macros and
packages work--but when I miss them, I miss them for the performance
side of things

o CLOS

The Common Lisp Object System is a really remarkable piece of work.
Among other things, it has generic functions instead of methods.
E.g. in Python or most other OO languages object.method(arg1, arg2) is
really just a fancy piece of syntactic sugar for method(object, arg1,
arg2); method does different things depending on the type of object, its
first argument.

Wouldn't it be nice to be able to specialise a method on _any_ subset of
its arguments, not just its first one?  Well, CLOS offers that.  (method
object1 object2) could be specialised on the first argument, the second
or both.  This can be very powerful.

Wouldn't it be nice to specify that some action be taken before or after
a superclass's method, rather than over-riding that method entirely?
Sure, one can over-ride the method and then call it within one's own
code, but that obscures the meaning of what one's doing.

o CLSQL

An OR mapper which actually works.  'Nuff said.


OTOH, here's what Python offers which Lisp doesn't:

o A capable standard library

Lisp's standard library was considered large once upon a time--why, it
included lists and hashes!  But that's not a big deal nowadays.  Right
now there are a plethora of choices, but it's not clear which choices
are blessed or particularly good.  Sure, once could use a different MIME

Re: merits of Lisp vs Python

[Pillsy]

Pascal Costanza wrote:
> Pillsy wrote:
[...]
> > When I first read PCL (which was my introduction to Lisp) I thought
> > LOOP was really neato. Once I actually started using it for things that
> > weren't so simple, I began to really hate it. I think that having a
> > specialized mini-language for iteration is a superb idea, but I don't
> > think LOOP is it.

> > That being said, there's a portable alternatives out there that I like
> > way better, and I still use LOOP for dashing stuff off one-liners at
> > the REPL.

> If you hate LOOP then you don't have to use it.

Indeed, I *don't* use it except for the simplest things.

> There's an important lesson to learn here: Not all language constructs
> are supposed to be loved by everyone. ;)

Especially in Common Lisp, where it's possible to have replacements
that integrate with the rest of the language as seamlessly as the
original feature they're replacing.

I don't love CL because its devoid of features I hate. I love it
because it provides so many great ways of getting around the features I
hate. If it didn't have features I hate, I might actually like it less,
because I wouldn't have anything to bitch about on USENET. :)

Cheers,
Pillsy

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

Re: merits of Lisp vs Python

[Paul Rubin]

jayessay <[EMAIL PROTECTED]> writes:
> > It's simply that newer language designs by definition have more of an
> > experience base to build on than older ones, if the designers care to
> > make use of it.
>
> Agreed.  Indeed, that was the underlying guiding principle in putting
> together CL.  *ML being older than CL didn't have any more opportunity
> in this respect.

You're forgetting that CL tried to be more or less backwards
compatible with its predecessors, at least compatible enough that
large systems in Maclisp, Interlisp, Zetalisp, etc. could be ported
without too much pain.  Therefore, CL could not erase too many
mistakes from the past.  Scheme went somewhat further than CL at
cleaning things up, and Scheme's aficionados think CL is a clumsy old
kludge as a result.  But it's still a Lisp dialect.  The ML's, for
their part, were able to start from scratch.
-- 
http://mail.python.org/mailman/listinfo/python-list