Python becoming less Lisp-like
Peter Seibel
map out of Python in the next big rev of Python (so called Python
3000):
<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
-Peter
--
Peter Seibel pe...@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Scott
that looks like an extension to the LOOP syntax:
any(x > 42 for x in S) # True if any elements of S are > 42
all(x != 0 for x in S) # True if all elements if S are nonzero
(Note that you can get the same effect in Lisp with SOME and EVERY and,
in the "any" example, a lambda function. (Note: I want the Arc-like [>
_ 42] reader syntax in CL, so I think I'll add it---something that
would be a very big deal in Python))
-Peter
M Jared Finder
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
Would someone who knows enough Python translate this over and post it?
Even though I know very little Python myself, I'd hate to see such a
useful feature as Lambda get thrown away. WRITE-INT32, SEEK, and
GET-POS all take seekable file streams as parameters. As you can guess,
I have yet to learn Lisp's file IO as well. This code is actually taken
from Java, where I wrote it using anonymous classes. :P
------------------------------
I think removing Lambda from Python is a huge mistake. Anonymous
functions are very useful when writing generic code. For example, let's
say you a chunky file format, where each chunk has a header that has the
chunk's unique ID, and the size of the chunk. Each chunk can contain
arbitrary data, including other chunks. With anonymous functions, you
could write a generic write_chunk function as follows:
(defun write-chunk (s id writer)
"S is the stream to write to, ID is the unique id, and writer is an
arbitrary block."
(let ((size-pos (+ (get-pos s) 4))
(start-pos (+ (get-pos s) 8)))
(write-int32 s id)
(write-int32 s -1) ;; total size, to be written later
(funcall writer)
(let ((end-pos (get-pos s)))
(seek s size-pos)
(write-int32 s (- end-pos start-pos))
(seek s end-pos))))
Which could then be used like this for writing a file format:
(write-chunk s +data-id+
(lambda ()
(write-int32 s +version+)
(write-int32 s (length enemies))
(doseq (enemy enemies)
(write-chunk s +enemy-id+
(lambda ()
(write-int32 s enemy.health)
(write-int32 s enemy.position)
(write-int32 s enemy.type))))
(write-int32 s (length power-ups))
(doseq (power-up power-ups)
(write-chunk s +power-up-id+
(lambda ()
(write-int32 s power-up.type)
(write-int32 s power-up.position))))
If you can't pass around anonymous clases you have to explicitly call
START-CHUNK at the start of each chunk and END-CHUNK at the end of each
chunk, which is much more error prone.
-- MJF
Bruce Stephens
> And yet at the same time they're making a big fuss about adding stuff
> that looks like an extension to the LOOP syntax:
>
> any(x > 42 for x in S) # True if any elements of S are > 42
> all(x != 0 for x in S) # True if all elements if S are nonzero
Adding LOOP-like syntax takes Python further away from Lisp doesn't
it?
[...]
Jim Newton
in the language, i found the lambda so limited that it was almost
useless. As i understand, the lambda can only contain a single
expression, and no control flow and no conditionals. it is
probably not a big loss to throw away such a limited partial
implementation.
-jim
Bruce Stephens
[...]
> If you can't pass around anonymous clases you have to explicitly call
> START-CHUNK at the start of each chunk and END-CHUNK at the end of
> each chunk, which is much more error prone.
Or you use a named function (or class) instead. Or you use
decorators, <http://www.python.org/doc/2.4/whatsnew/node6.html>, I
guess. (I don't know much about Python, but losing lambda doesn't
seem a catastrophe if you've got suitably scoped named functions, and
if you've got alternative syntaxes for common uses like generators.)
Tobias C. Rittweiler
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
The Lambda cannot be lambasted; its lambency shall shine forever!
--tcr.
Cláudio F. Gil
> i'm no python expert but in my few attempts to write someting
> in the language, i found the lambda so limited that it was almost
> useless. As i understand, the lambda can only contain a single
> expression, and no control flow and no conditionals. it is
> probably not a big loss to throw away such a limited partial
> implementation.
>
> -jim
I don't think that anonymous functions (or _lambda_) is partially
implemented in Python. For what I know, those limitations are intentional.
I've only programmed a few lines of Python but the whole language seamed
oriented to named functions.
Tayssir John Gabbour
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
That's probably a good thing. In particular, I feel bad for the
commentor (on the 3rd page) who claimed these were Python beliefs:
"The programmer knows best and is the ultimate authority."
"Power should be maximized."
Python's stated goal is actually about limiting choice: "There should
be preferably only one way to do something." In particular, a tool that
Guido van Rossum wants to personally use.
If you're a poor overworked programmer coming from Java, Python is
obviously a liberation. That leads many to believe peculiar things
about Python's goals, which Guido honestly states are not the case.
M Jared Finder
> i'm no python expert but in my few attempts to write someting
> in the language, i found the lambda so limited that it was almost
> useless. As i understand, the lambda can only contain a single
> expression, and no control flow and no conditionals. it is
> probably not a big loss to throw away such a limited partial
> implementation.
Wow, I would have never thought that lambda in Python would be so wimpy.
What was the rationale behind this limitation? Please tell me it was
not so that return could be implicit; that would be an awful reason.
-- MJF
Stefan Nobis
[Python: lambda allows only a single expression]
> Wow, I would have never thought that lambda in Python would be
> so wimpy. What was the rationale behind this limitation?
I thing the problem is syntax. In Python only whitespaces can
delimit blocks and i think they don't accept more syntax only for
this single feature. As far as i understand this, lambda is only a
quick hack from some lisp-guy.
I like Python very much as a language for beginners (i use it in
basic programming courses) and it's a great language for the
average programmer. But for lisp programmer, it's not a very
natural choice -- i think in the group Perl, Python, PHP, Ruby the
last one would fit better.
--
Stefan.
Jacek Generowicz
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
Aaaargh, don't remind me. It pissed me off so much when I read in on
Friday, that I didn't want look at Python all day ...
Take some clear, simple, orthogonal features and replace them with
ad-hoc special case solutions for the use cases you can think of.
... and now you rub my nose in it in c.l.lisp, of all places.
Let's just hope that this really happens in the year 3000.
Harald Hanche-Olsen
| The Lambda cannot be lambasted; its lambency shall shine forever!
And of course, the lambada is a rather indecent form of dance in the
eyes of some people.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Ulrich Hobelmann
> Aaaargh, don't remind me. It pissed me off so much when I read in on
> Friday, that I didn't want look at Python all day ...
Why look at Python at all? One day I went to their website, saw the
whitespace syntax and Yet-Another-Imperative-Scripting-Language. Didn't
look at Python ever again.
If someone forces me into scripting I will take a closer look at Ruby
and Lua.
> Take some clear, simple, orthogonal features and replace them with
> ad-hoc special case solutions for the use cases you can think of.
That's Python. They might have nicer ad-hoc solutions than the
C-dialects, but the whitespaces: uuuh.
Peter Scott
significance? That reminds me of disliking Lisp because of the
parentheses. Both are fairly easy to work with once you get your editor
set up and become accustomed to them.
Really, what's the problem?
-Peter
Ulrich Hobelmann
But in C I can at least write "foo->a = a; foo->b = b; bla(); barz();"
I don't want to use all whitespace and newlines, just because Mr van
Rossum thinks that's cool.
Also, why should I learn the language? What compelling advantages does
it have (again, except for libraries)?
Marcin 'Qrczak' Kowalczyk
>> You took one look at Python and were turned off by the whitespace
>> significance? That reminds me of disliking Lisp because of the
>> parentheses. Both are fairly easy to work with once you get your
>> editor set up and become accustomed to them.
>> Really, what's the problem?
> But in C I can at least write "foo->a = a; foo->b = b; bla(); barz();"
> I don't want to use all whitespace and newlines, just because Mr van
> Rossum thinks that's cool.
You can use semicolons in Python too. Not all kinds of compound
statements can be written without newlines, but in this case it's
accepted.
I agree that bashing Python because of whitespace is like bashing Lisp
because of parentheses. Some people like it, some people hate it,
it's not a real obstacle but a matter of taste.
> Also, why should I learn the language? What compelling advantages
> does it have (again, except for libraries)?
Don't underestimate the power of libraries.
For example Python makes easy to access the Unix API.
There are many C libraries which have an already made interface to
Python (e.g. databases, Gtk+ / GNOME, mod_python for Apache, XML
stuff, network protocols, cryptography, talking to CVS, accessing
a Gmail account etc.).
In the above two categories only C/C++, Perl and maybe Java can beat it
(Java only in the second category I think, if at all - certainly not
under Linux).
Python has a sane Unicode support (separate byte strings and Unicode
strings, most libraries can work with both). This is a rare thing
among scripting languages: Unicode in Perl is being worked on but
sucks horribly, Ruby mostly ignores Unicode because it's Japanese,
and Lua ignores Unicode because it has a tiny runtime on top of C.
Python is quite easily embeddable in C (much easier than Perl, a bit
harder than Ruby, I don't know about Lua).
Python is easy to learn for beginners. This is not a reason to use it
if you are experienced and you can invest more time into learning, but
it is a reason why it became popular.
I think Python code written by other people is easy to read, especially
if the task is typical. Instead of providing a set of hyper-general
constructs which can be used to roll your own abstractions for common
tasks, it provides these common tasks directly. This increases the
likelihood that different programmers would model a given problem in
the same way, and thus one of them will immediately recognize the
other's model.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Gareth McCaughan
> But in C I can at least write "foo->a = a; foo->b = b; bla(); barz();"
> I don't want to use all whitespace and newlines, just because Mr van
> Rossum thinks that's cool.
You can use semicolons that way in Python too. Unless
Guido decides that they don't belong in Python either,
which now I come to think of it sounds uncomfortably
plausible. I hope he doesn't read comp.lang.lisp.
> Also, why should I learn the language? What compelling advantages
> does it have (again, except for libraries)?
Well, the libraries *are* pretty nice. Whether the
language has compelling advantages depends on what
you compare it to. Compared to Common Lisp, probably
not, but then what has? List comprehensions are
nice; various things are more dynamic than in Lisp,
which makes it easier to define new kinds of things
to iterate over or index into, etc. These are advantages,
but certainly not compelling ones, especially when
comparing with a language where almost any feature
you can imagine is only a macro away.
Compared to C++ or Java or Perl, it's a different
story. The syntax is at least reasonably clean (true
also of Java, but not C++ or Perl), dynamic typing
is in most contexts a clear win (advantage over C++
and Java, but not Perl), and so on.
I use Python all the time at work. I want my colleagues
to be able to read the code I write, and it's not
reasonable to expect them to become fluent in Lisp.
For most of the things I need to do, I can get by
without a truly programmable programming language;
the thing I miss most is the performance of Lisp,
but I can get that at a cost by writing critical portions
of the software in C or C++, something Python supports
quite well.
If I had no colleagues, or if I worked for a company
full of lispniks, then I'd almost always prefer to
write in Lisp. But I don't, and Python's not a bad
second choice. That, for me, is the really compelling
advantage; the language is *good enough*, and it fits
into the Rest of the World a bit better than Lisp does.
Oh, and the libraries are handy sometimes, too.
--
Gareth McCaughan
.sig under construc
Ulrich Hobelmann
> If I had no colleagues, or if I worked for a company
> full of lispniks, then I'd almost always prefer to
> write in Lisp. But I don't, and Python's not a bad
> second choice. That, for me, is the really compelling
> advantage; the language is *good enough*, and it fits
> into the Rest of the World a bit better than Lisp does.
Sounds like a good compromise language. Maybe I'll learn it the next
time I do something with other people (instead of using Java then :( ).
Fernando
wrote:
>Looks like the BDFL is planning to take lambda, reduce, filter, and
>map out of Python in the next big rev of Python (so called Python
>3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
Basically, it says that it will get rid of the explicit map, filter
and reduce and substitute them by some syntactic sugar that uses them
implicitly. That's ok, and not a big deal.
It will also get rid of lambda, and it's not a great loss, since
python's version is so limited that it's almost useless. Besides,
given the syntactic sugar used to replace map, reduce and filter,
there's no real need for lambda in the most usual cases.
The real problem with Python is that it has been very successful as a
scripting language in the static-typing/C/C++ world. Those
programmers, instead of adapting their evil ways to Python, and
realizing the advantages of a dynamic language, are influencing
Python's design and forcing it into the static-typing mold. Python is
going the C++ way: piling feature upon feature, adding bells and
whistles while ignoring or damaging its core design.
The new 'perlified' syntax for decorators, the new static type bonds
and the weird decision to kill lambda instead of fixing it are good
examples that show that Python is going the wrong way. What used to be
a cool language will soon be an interpreted C/C++ without any
redeeming value. A real pity...
Brandon J. Van Every
> Jacek Generowicz wrote:
>> Aaaargh, don't remind me. It pissed me off so much when I read in on
>> Friday, that I didn't want look at Python all day ...
>
> Why look at Python at all? One day I went to their website, saw the
> whitespace syntax and Yet-Another-Imperative-Scripting-Language.
> Didn't look at Python ever again.
>
> If someone forces me into scripting I will take a closer look at Ruby
> and Lua.
Lua is very capable as a lightweight embeddable scripting language, as it
was designed to be. It is of no use as a systems language. Python has a
major advantage there. Someone at the Python convention last year gave a
talk entitled "Scripting Language My Ass" IIRC. Python could really stand a
marketing campaign to overcome the idea that it's only capable of scripting.
But, that crowd can't market, so....
Ruby is like Python done by Perl programmers, so I am told. It doesn't have
the user base of Python.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
Torsten Bronger
Fernando <f...@easyjob.net> writes:
> [...]
>
> [...] Python is going the C++ way: piling feature upon feature,
> adding bells and whistles while ignoring or damaging its core
> design.
I'm new to Python, but I while I skimmed through the "What's new?"
of recent versions, I saw the same unfortunate development.
Moreover, I dislike the fact that new features are implemented
partly in the interpreter and partly in Python itself. It reminds
me of TeX/LaTeX, where the enormous flexibility of TeX is used to
let it change itself in order to become a LaTeX compiler. However,
the underlying constructs are utterly ugly, as are some of Python's
features (e.g. __getattr__ and such, and decorators, in order to get
nice class properties).
> The new 'perlified' syntax for decorators,
Python lost its innocence here: The first really special character,
disturbing the former syntax style. Not important, but irritating.
> the new static type bonds
What is meant by that?
> [...] What used to be a cool language will soon be an interpreted
> C/C++ without any redeeming value. A real pity...
I don't think so, there will be always an enormous difference. But
Python seems a little bit chaotic.
I looked for a new language for my hobby programming. I used to use
Turbo Pascal for 10 years and then C++ for 6 years. A couple of
weeks ago, I narrowed my decision to C#, Ruby, and Python. At the
moment, I want to go with Python, but you can definitely see that
it's the oldest one: Many parts of its syntax are awkward and look
like patchwork.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Torsten Bronger
Fernando <f...@easyjob.net> writes:
> [...]
>
> [...] Python is going the C++ way: piling feature upon feature,
> adding bells and whistles while ignoring or damaging its core
> design.
I'm new to Python, but I while I skimmed through the "What's new?"
of recent versions, I saw the same unfortunate development.
Moreover, I dislike the fact that new features are implemented
partly in the interpreter and partly in Python itself. It reminds
me of TeX/LaTeX, where the enormous flexibility of TeX is used to
let it change itself in order to become a LaTeX compiler. However,
the underlying constructs are utterly ugly, as are some of Python's
features (e.g. __getattr__ and such, and descriptors, in order to
get nice class properties).
> The new 'perlified' syntax for decorators,
Python lost its innocence here: The first really special character,
disturbing the former syntax style. Not important, but irritating.
> the new static type bonds
What is meant by that?
> [...] What used to be a cool language will soon be an interpreted
> C/C++ without any redeeming value. A real pity...
I don't think so, there will be always an enormous difference. But
James Graves
> For example Python makes easy to access the Unix API.
And meanwhile, CL's portable Posix library is still in the planning
stages. :-(
I really ought to give those guys a hand. File streams and sockets
cover a lot of what I do, but I can forsee times where I'll really want
access to everything.
And speaking of Python's libraries... Hmmm. The FOIL people have
created interfaces for Java and C#, could Python be harder than those?
I'm guessing it would be easier, C# and Java are statically typed.
Hmmm...
James Graves
Fernando
<try_vanevery_a...@yahoo.com> wrote:
>Ruby is like Python done by Perl programmers, so I am told. It doesn't have
>the user base of Python.
Rather by smalltalkers. ;-)
Brandon J. Van Every
I think Python's compelling advantages are:
0) large open source library support
1) easy for newbies to pick up. Isn't weird, resembles C/C++. This is all
by design; BDFL puts a premium on readability, clarity, ease of use. That's
what the Zen Of Python is about.
2) consequently, many open source developers are standardizing on it as a
Builds, GUIs, and Tools language. It's good for communal development, where
projects are "relatively dumb."
Python's main disadvantage IMO is it's slow. I'm doing 3D graphics and game
AI, so slow matters to me. I want something compiled. I've seen little
compelling proof of concept in those problem domains. 3D, in particular,
always relies on some underlying C++ engine. Also game AI is a "roll my
own" problem, not a communal problem.
Valentino Volonghi aka Dialtone
> Python's main disadvantage IMO is it's slow. I'm doing 3D graphics and game
> AI, so slow matters to me. I want something compiled. I've seen little
> compelling proof of concept in those problem domains. 3D, in particular,
> always relies on some underlying C++ engine. Also game AI is a "roll my
> own" problem, not a communal problem.
It's not THAT slow. For example there's a VoIP software written in
Python and a SIP server too with Stun and UPnP support.
Since you might not know, SIP servers need to send packages every 20ms
to all the connected clients (if there is a conference going on clients
may be more than 2). And of course each voice stream has to be mixed
with the others.
Using python standard libraries and python itself the developers managed
to get the sampling/mixing done in about 1ms for 18 tracks.
There are many web servers written in python and each of them can serve
at least 500 reqs/sec.
Andrea Arcangeli (of linux Virtual Machine fame) is using python with
Twisted Matrix for its www.cpushare.com project.
And he managed to saturate a 10mbit line with just 2 Twisted.web
processes with a load balancer.
The popular RPG game: Temple of Elemental Evil was written using python.
All this to say: I probably have to agree if you talk about raw speed
(which anyway depends on the particular job, java, which is considered
to be faster, most of the times yields slower GUIs; libglade contains an
algorithm to handle scheduling which is slower than the one in Twisted
Matrix written in pure python), but the real question should be: is
python fast enough? Most of the times yes. When it is not, anyway, there
are many and confortable ways to make it faster: Pyrex, psyco, swig,
pyasm, ctypes and so on.
HTH, cheers
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
Ulrich Hobelmann
> I think Python's compelling advantages are:
> 0) large open source library support
> 1) easy for newbies to pick up. Isn't weird, resembles C/C++. This is all
You know, "not weird" and "resembles C" sounds like a contradiction to me ;)
> by design; BDFL puts a premium on readability, clarity, ease of use. That's
> what the Zen Of Python is about.
Okay, it really seems quite a readable language, even for non-pythoners.
> 2) consequently, many open source developers are standardizing on it as a
> Builds, GUIs, and Tools language. It's good for communal development, where
> projects are "relatively dumb."
Well, I would wish it could replace Perl, then I wouldn't have to learn
that in the future.
> Python's main disadvantage IMO is it's slow. I'm doing 3D graphics and game
> AI, so slow matters to me. I want something compiled. I've seen little
> compelling proof of concept in those problem domains. 3D, in particular,
> always relies on some underlying C++ engine. Also game AI is a "roll my
> own" problem, not a communal problem.
I think there's a partial compiler, Psycho (or Psyco?), but it isn't
really fast, either, from what I've heard.
Ulrich Hobelmann
> Hallöchen!
Tach!
> Moreover, I dislike the fact that new features are implemented
> partly in the interpreter and partly in Python itself. It reminds
> me of TeX/LaTeX, where the enormous flexibility of TeX is used to
> let it change itself in order to become a LaTeX compiler. However,
> the underlying constructs are utterly ugly, as are some of Python's
> features (e.g. __getattr__ and such, and descriptors, in order to
> get nice class properties).
Well, I think TeX is just an awful, weird language with (AFAIK) dynamic
scoping. Thinking of Lisp macros, I'd say that implementing features on
top of a small language core is GREAT!
Pascal Costanza
Brandon J. Van Every
> Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
>
>> Python's main disadvantage IMO is it's slow. I'm doing 3D graphics
>> and game AI, so slow matters to me. I want something compiled.
>> I've seen little compelling proof of concept in those problem
>> domains. 3D, in particular, always relies on some underlying C++
>> engine. Also game AI is a "roll my own" problem, not a communal
>> problem.
>
> It's not THAT slow. For example there's a VoIP software written in
> Python and a SIP server too with Stun and UPnP support.
>
> Since you might not know, SIP servers need to send packages every 20ms
> to all the connected clients (if there is a conference going on
> clients may be more than 2).
2ms is a very, very long time to a number crunching 3D graphics or AI guy.
> And of course each voice stream has to be mixed with the others.
Are you saying someone is doing tons of signal processing with Python and no
underlying C library?
> There are many web servers written in python and each of them can
> serve at least 500 reqs/sec.
If anyone claimed a 3D graphics card could do 500 triangles/sec, people
would laugh. 500 frames/sec would be quite impressive, however, for complex
scenes. I just don't think we're working with the same definition of the
term "fast."
> The popular RPG game: Temple of Elemental Evil was written using
> python.
In Pygame, which is written on top of SDL, which is a C library. A
developer interview:
http://www.pygame.org/interview/stevemoret.shtml I'm guessing by the
screenshot they're using SDL's OpenGL layer. Python is proven useful for
the scripting aspects of games. It does not have the chops to implement 3D
engines.
You may say, no problem, just use Python and C++ to implement your full
system. But I don't believe in this kind of split development. It does not
help me for my AI problems, which need to be both high level and fast, in
the millions of instructions sense of the term. For 3D graphics problems,
it is a chore to bridge between C++ and any high level language. That chore
is acceptable if someone has already built a complete 3D engine that has all
the capabilities one needs, but I'd never choose a 2 language approach if
starting from scratch.
> but the real question should be: is
> python fast enough? Most of the times yes.
The only way that statement is true, is if you're speaking of all problem
domains. Most software is accounting software, so in that sense, "yes,"
you're right. This idea of "most of the time" completely breaks down when
one's problem domain is more specific. Python is *never* fast enough to
implement the core of a 3D engine.
Brandon J. Van Every
> Brandon J. Van Every wrote:
>> I think Python's compelling advantages are:
>> 0) large open source library support
>> 1) easy for newbies to pick up. Isn't weird, resembles C/C++. This
>> is all
>
> You know, "not weird" and "resembles C" sounds like a contradiction
> to me ;)
Yes but you are hanging out in comp.lang.lisp, so probably have poisoned
tastes as far as the rest of the programming world is concerned. C is not
weird. C++ has parts that are weird and painful.
>> 2) consequently, many open source developers are standardizing on it
>> as a Builds, GUIs, and Tools language. It's good for communal
>> development, where projects are "relatively dumb."
>
> Well, I would wish it could replace Perl, then I wouldn't have to
> learn that in the future.
Python can do any job Perl can do. It's only a question of competing
installed base. If you have control over the development, you don't have to
use Perl. If you have the power of recommendation, you may be able to sway
a project from Perl to Python. It's only when "we're already using Perl"
that you're stuck.
> I think there's a partial compiler, Psycho (or Psyco?), but it isn't
> really fast, either, from what I've heard.
Yes, my Pythonic friend has done game development with Psyco. It doesn't
result in any amazing speedup. Maybe 2x 3x over something that was already
quite slow? Can't remember exactly, but it's still not approaching compiled
language speeds.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
Brandon J. Van Every
>>
>> The popular RPG game: Temple of Elemental Evil was written using
>> python.
>
> In Pygame, which is written on top of SDL, which is a C library. A
> developer interview:
> http://www.pygame.org/interview/stevemoret.shtml I'm guessing by the
> screenshot they're using SDL's OpenGL layer. Python is proven useful
> for the scripting aspects of games. It does not have the chops to
> implement 3D engines.
I apologize, I completely spaced out actually reading the article once I
Googled for it. It's an interview with the ToEE developer that just happens
to appear on the Pygame website. ToEE was not written on Pygame, so my
deductions about SDL are spurious. However, one can reasonably infer from
the article that Python was only used for scripting. The "big worry" was
one (1) script that got called every frame. Let's be generous and say the
game ran at 120 fps. 120 invocations of a script per second is nothing.
Run it millions of times a second, then we'll talk.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
Brandon J. Van Every
>> Valentino Volonghi aka Dialtone wrote:
>>>
>>> The popular RPG game: Temple of Elemental Evil was written using
>>> python.
>>
And BTW, the article strongly confirms my original points about "what Python
is good for." Python is excellent as a communal development language for
"relatively dumb" code. The article says:
"All the dialog writers used Python expressions to handle which dialog lines
were available to people, and the artists wrote simple Python statements to
emit particles or trigger visual effects during specific frames of
animation. In the end, I'd say over 1/2 of the team had touched Python code
at some point through the course of the development of the game."
I will wager 0 game artists touch lisp code. Would love to hear any
anecdotes to the contrary, even in hobbyist open source development.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Taking risk where others will not.
Ulrich Hobelmann
> Ulrich Hobelmann wrote:
>
>>Brandon J. Van Every wrote:
>>
>>>I think Python's compelling advantages are:
>>>0) large open source library support
>>>1) easy for newbies to pick up. Isn't weird, resembles C/C++. This
>>>is all
>>
>>You know, "not weird" and "resembles C" sounds like a contradiction
>>to me ;)
>
>
> Yes but you are hanging out in comp.lang.lisp, so probably have poisoned
> tastes as far as the rest of the programming world is concerned. C is not
> weird. C++ has parts that are weird and painful.
I'm not sure about that. Maybe.
I consider it weird when I have a function like this (annotated with the
*real* type):
/* parser -> parsetype * parsevalue */
ParseType parse(Parser * p, ParseValue * pv);
Yes, it's supposed to return INT or STRING or something else AND to
return the value of the int/string/bla as well. But in C I have to
write this with a crazy pointer.
To call it I have to:
ParseValue pv; ParseType t = parse(p, &pv);
instead of something sensible like (t, pv) = parse(p).
Ok, here we're actually talking Python, and totally unintended of me :)
Anyway, C is totally ad-hoc, has slow, arbitrary calling conventions,
has arbitrary syntax and other limitations (because it's ad-hoc). It's
incredible that millions of programmers just put up with it because of
inertia.
C++ is both much nicer in some respects and incredibly ugly (templates?
compiling the same generic container class over and over again, instead
of using a C module that just takes a void * as parameter).
Maybe I'll write a frontend to C someday that allows me some freedom.
But that will be a lot of work, too. So I end up using Scheme/Lisp/SML
once in a while.
> Python can do any job Perl can do. It's only a question of competing
> installed base. If you have control over the development, you don't have to
> use Perl. If you have the power of recommendation, you may be able to sway
> a project from Perl to Python. It's only when "we're already using Perl"
> that you're stuck.
Well, people will have to relearn everything (or something) for Perl 6.
That's the chance: Lispniks, bite them!
Frank Buss
> I will wager 0 game artists touch lisp code. Would love to hear any
> anecdotes to the contrary, even in hobbyist open source development.
Perhaps they don't talk about it, because if the competitors uses it, too,
they would lost an advantage, but there are some known stories:
http://groups.google.com/groups?selm=lak7reuqel.fsf%40buzz.in-fusio.com
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Brandon J. Van Every
>
> Anyway, C is totally ad-hoc, has slow, arbitrary calling conventions,
> has arbitrary syntax and other limitations (because it's ad-hoc).
True. The reason it isn't 'weird' is because everybody learns it.
> It's incredible that millions of programmers just put up with it
> because of inertia.
That's not the only reason. Name me 1 language that's easy to bind to other
languages, other than C. The C calling convention is the only thing we've
got. C is also a portable assembler, and useful wherever anyone would want
a portable assembler.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
Ulrich Hobelmann
> Perhaps they don't talk about it, because if the competitors uses it, too,
> they would lost an advantage, but there are some known stories:
>
> http://groups.google.com/groups?selm=lak7reuqel.fsf%40buzz.in-fusio.com
>
They mention the Final Fantasy Movie, and not all seemed to go well:
"Fluid naming convention : As mentioned above, the database operation
relied on the fact that all the data files followed well-defined naming
convention that the database knew. However, we needed to adjust naming
conventions constantly to address the problems in the production
pipeline, and the internals of the database had to be adjusted
constantly. Occasionally such changes were made locally rather than with
global consensus, and the database had to interpret several sets of
mutually incompatible rules (*8). Since the database was written in a
single monolithic server including the Web interface part, and written
in a rather uncommon language Lisp, all of such requests had to go
through only one or two programmers, and eventually this became a
bottleneck."
So, always bring enough programmers!
Following some links brought me this:
http://www.shiro.dreamhost.com/scheme/docs/jlugm2000.html
(Shooting A Moving Target---An Experience In Developing A Production
Tracking Database), which describes the DB used for the FF movie in more
detail.
...going off to read.
Ulrich Hobelmann
>>because of inertia.
>
>
> That's not the only reason. Name me 1 language that's easy to bind to other
> languages, other than C. The C calling convention is the only thing we've
> got. C is also a portable assembler, and useful wherever anyone would want
> a portable assembler.
>
(rant
"I dare disagree (though I agree an C being the standard for calling
conventions and language bindings). Calling C a portable assembler IMHO
is an insult to the people who made PPC, ARM, and other beautiful
architectures what they are (I'm sure you didn't mean it that way ;) ),
unfortunately.
There's so much you can do with assembly language, that C doesn't even
consider, like the already mentioned multiple-return-values (sure, after
all we are allowed to pass n parameters TO the function, right?), tail
calls (or space-safety in general, though this is an implementation
issue, I guess [1]), special variables that are kept in registers (I'm
not sure, does C honor global register int definitions?). (Of course
there's C-- for stuff like this, but everyone uses C, even for compiler
backends.) In x86 the calling conventions are somewhat braindead, but
then the architecture isn't the best, anyway. In particular pushing the
return-value on a call might make continuations harder (that is: a lot
slower I would guess, since it confuses the CPU's optimizations to work
around this old 'feature'). On PPC the CCs are weird too, so a portable
assembler could optimize a lot, but even gcc could produce better code
and still stay within the compatible allowances. When I learnt the arch
some months ago, I did simple stuff like the recursive fibonacci
function. Asm beat gcc -O2 by a lot, but even a C-compatible function
was a lot faster, just by changing the function pro-/epilogue. That's sad.
All it takes for a portable assembler would be mechanisms for structs
(or even only vectors of 32bit words) and continuation calls (i.e.
goto/jump with arguments). I think that would be it. Everything else,
including a saner C (and from there ++, Java, you name it), could be
layered on this. I'm just too lazy to do it, I guess.
But C is very portable, yes (in fact much more portable than The Great
Java).
[1] I mean that a C function might use storage even if it's not needed
at the time, like in:
{ BigStruct bs; foo(); bar(&bs); }
While foo() (which might be a complex recursive call) is running, the
stack shouldn't waste space for bs. What's unrelated: in typical
gcc-output (x86+PPC), every single function even does stuff like
decrementing the stack pointer by 32, and then incrementing it by
another -32 (yes, this could be a single instruction). It does this for
functions that have no or only small space requirements, in the order of
under 20 bytes. Alignment would make this 32 bytes maybe, but gcc often
makes a function use 80 and more. This eats stack space and L1-cache I
guess, especially for recursion, again.")
Kay Schluehr
(defun addn (n)
#'(lambda (x)
(+ x n)))
This is correct LISP-syntax if You bear in mind LISPs powerwull macro
language...
I think Guido and python-dev are very carefull in adding new power to
Python. They have to balance the needs for powerfull language features
on the one hand, simplicity on the other hand. That this relation
drifts towards more power and more complexity since Python 2.2. is a
correct observation, but You probably may have notized that the number
of large projects using Python as their primal language is growing. The
boundary between that what was formerly called "systems programming"
and "scripting" is blurred ( if Your mindset reduces
"systems-programming" on the availability of pointers You certainly
don't have any problems with the common public prejudices ).
> The real problem with Python is that it has been very successful as a
> scripting language in the static-typing/C/C++ world. Those
> programmers, instead of adapting their evil ways to Python, and
> realizing the advantages of a dynamic language, are influencing
> Python's design and forcing it into the static-typing mold. Python is
> going the C++ way: piling feature upon feature, adding bells and
> whistles while ignoring or damaging its core design.
Maybe You should explain what You regard as Pythons "core design", what
belongs to the core and what to the periphery? Otherwise Your statement
seems to be plain emotional.
> The new 'perlified' syntax for decorators, the new static type bonds
> and the weird decision to kill lambda instead of fixing it are good
> examples that show that Python is going the wrong way.
My hypothesis about lambda: lambda will be trashed because it is an
alien in the language. It is impure. Trashing it is an expression of
Pythons rassism. There is no way of "doing it right" without exceeding
it's power and making it less controlable. When Guido once stated that
the generator way of doing things is Pythons future it was also a
renouncement of lambda. Compared with this ideological orientation the
introduction of the @-syntax is a minor sacrilege on syntax esthetics -
though this special character may hurd the souls of the believers more
that everything else introduced into the language.
Kay
Matthias
> Brandon J. Van Every <try_vanevery_a...@yahoo.com> wrote:
> > Python's main disadvantage IMO is it's slow. I'm doing 3D graphics and game
> > AI, so slow matters to me. I want something compiled. I've seen little
> > compelling proof of concept in those problem domains. 3D, in particular,
> > always relies on some underlying C++ engine. Also game AI is a "roll my
> > own" problem, not a communal problem.
>
> It's not THAT slow. For example there's a VoIP software written in
> Python and a SIP server too with Stun and UPnP support.
About two years ago I tried to port code analyzing satellite images to
python. It was 1000 times (no typo!) slower than the C++ version.
When I prototyped a new algorithm in Python, I started the program,
then re-wrote the same algorithm in C++. I stopped doing that when I
realized that it took the Python program longer to complete on a
sample data set than me writing a C++ program, compile and execute.
Python fans told me just to write "the few speed-critical lines" as an
C extension. Unfortunately, these were the same lines that I had to
change all the time. So no productivity boost from that. (I also
disliked that I had to do my own reference counting in the C
extensions.)
> python fast enough? Most of the times yes. When it is not, anyway, there
> are many and confortable ways to make it faster: Pyrex, psyco, swig,
> pyasm, ctypes and so on.
This large number of workarounds just shows that there's a real
problem with speed.
Personally, I tried psyco (nice, but on my data 2x speedup only), swig
(not simple enough at that time), some C-inlining tool (cool, but why
not do it right in C). After that I returned to C++ and Matlab.
Python's kind of nice, very easy to teach, with tons of libraries.
But boy can it be slow...
John Thingstad
> Python's kind of nice, very easy to teach, with tons of libraries.
> But boy can it be slow...
Yes. Integer computation can be outrageously slow.
Did you try numpy? It's one forgiving feature for scientific computation.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
ole....@cern.ch
Kay> (defun addn (n)
Kay> #'(lambda (x)
Kay> (+ x n)))
Is that a real question or are you making a rhetorical point here?
Kay> This is correct LISP-syntax if You bear in mind LISPs powerwull macro
Kay> language...
It's indeed correct CL syntax, but I don't see much macro usage in there.
Try (mapcar (addn 4) (list 1 2 3))...
Ole
Förster vom Silberwald
==
About two years ago I tried to port code analyzing satellite images to
python. It was 1000 times (no typo!) slower than the C++ version.
When I prototyped a new algorithm in Python, I started the program,
then re-wrote the same algorithm in C++. I stopped doing that when I
realized that it took the Python program longer to complete on a
sample data set than me writing a C++ program, compile and execute.
==
If that hadn't been done already (I have a hard time to follow google
discussion under the new scheme): please could you name the timings. Do
you speak of hours, or seconds when refering to "1000 times slower"?
As a scientist and Python hater and Bigloo admirer I would be
interested in your figures.
Förster vom Silberwald
PS: I wonder why Matlab/C++ gave you the boost but Python/C++ did not.
PSS: What prevents you from using CommonLisp/C++ for analyzing
satellite data?
mau...@gmail.com
> Looks like the BDFL is planning to take lambda, reduce, filter, and
> map out of Python in the next big rev of Python (so called Python
> 3000):
>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
Ok. No problem. Then most hackers will take out Python of their
toolbox...
Python wants to be Java or Visual Basic? Then it will be used only by
the
people of Visual Basic IQ level...
Matthias
> Matthias Mar 15, 2:45 am wrote:
> ==
> About two years ago I tried to port code analyzing satellite images to
> python. It was 1000 times (no typo!) slower than the C++ version.
>
> When I prototyped a new algorithm in Python, I started the program,
> then re-wrote the same algorithm in C++. I stopped doing that when I
> realized that it took the Python program longer to complete on a
> sample data set than me writing a C++ program, compile and execute.
> ==
>
> If that hadn't been done already (I have a hard time to follow google
> discussion under the new scheme): please could you name the timings. Do
> you speak of hours, or seconds when refering to "1000 times slower"?
Exactly. Seconds to minutes for C++ and several hours for Python. I
don't have the timings at my fingertips, but I did do them and the
1000 is accurate.
> PS: I wonder why Matlab/C++ gave you the boost but Python/C++ did not.
It's the libs.
Matlab is an ugly language with extremely nice libraries. The
libraries (for visualization, optimization, statistics in my case)
make up for the design errors in the language. I don't love it, but
it feels very productive. ;-)
But the main reason for Matlab is that it's the lingua franca in the
field. Everyone uses it. Many cool tools are available for it. I
don't want to spend my time re-implementing in another language stuff
readily available for Matlab.
> PSS: What prevents you from using CommonLisp/C++ for analyzing
> satellite data?
To start with: At the time I made the decision there was no simple way
to load an image/picture into the CL implementation of my choice
(cmucl).
Sure, I could implement this, and visualization, a good syntax for
arrays, fast & accurate numerics, etc. But that's not what I'm paid
for. And that's not what I want to do with my time. And frankly, I
don't believe that at the end the time invested to re-implement,
debug, document, and maintain all that stuff would pay off in
super-increased productivity. Of course, other people feel
differently and make different decisions. Fine with me.
Serge Orlov
> On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel
<pe...@gigamonkeys.com>
> wrote:
>
> >Looks like the BDFL is planning to take lambda, reduce, filter, and
> >map out of Python in the next big rev of Python (so called Python
> >3000):
> >
> > <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
>
> and reduce and substitute them by some syntactic sugar that uses them
> implicitly. That's ok, and not a big deal.
>
> It will also get rid of lambda, and it's not a great loss, since
> python's version is so limited that it's almost useless. Besides,
> given the syntactic sugar used to replace map, reduce and filter,
> there's no real need for lambda in the most usual cases.
>
> The real problem with Python is that it has been very successful as a
> scripting language in the static-typing/C/C++ world. Those
> programmers, instead of adapting their evil ways to Python, and
> realizing the advantages of a dynamic language, are influencing
> Python's design and forcing it into the static-typing mold. Python is
> going the C++ way: piling feature upon feature, adding bells and
> whistles while ignoring or damaging its core design.
You're wrong about design: http://www.artima.com/intv/pyscale.html
Quoting Guido: The first sound bite I had for Python was, "Bridge
the gap between the shell and C." So I never intended Python to be
the primary language for programmers.
>
> The new 'perlified' syntax for decorators, the new static type bonds
> and the weird decision to kill lambda instead of fixing it are good
> examples that show that Python is going the wrong way. What used to
> be a cool language will soon be an interpreted C/C++ without any
> redeeming value. A real pity...
Yeah, that was a good time. After a nice bridge between the shell
and C was built they never ceased piling feature upon feature and
kept adding bells and wristles.
Serge.
Valentino Volonghi aka Dialtone
> Exactly. Seconds to minutes for C++ and several hours for Python. I
> don't have the timings at my fingertips, but I did do them and the
> 1000 is accurate.
This is way too much IMHO. There is a package called numarray that is
exactly used to work on satellite images from hubble space telescope.
http://www.stsci.edu/resources/software_hardware/numarray
> But the main reason for Matlab is that it's the lingua franca in the
> field. Everyone uses it. Many cool tools are available for it. I
> don't want to spend my time re-implementing in another language stuff
> readily available for Matlab.
Surely Matlab has a lot of good libraries optimized for this. But there
is plenty of packages to do a lot of the computations you need. For
example: matplotlib, numarray or Numeric, the scipy package and many
more like biopython (which has nothing to do with this particular
field).
Albert Reiner
> It's indeed correct CL syntax, but I don't see much macro usage in there.
defun?
Albert.
Valentino Volonghi aka Dialtone
> Ok. No problem. Then most hackers will take out Python of their
> toolbox...
I doubt this will happen only because they removed lambda, reduce,
filter and company.
> Python wants to be Java or Visual Basic? Then it will be used only by
> the
> people of Visual Basic IQ level...
This is offensive, and plain false, but if it makes you more comfortable
to disqualify your statements in this way then I cannot stop you from
going on.
Förster vom Silberwald
==
Exactly. Seconds to minutes for C++ and several hours for Python. I
don't have the timings at my fingertips, but I did do them and the
1000 is accurate.
It's the libs.
Matlab is an ugly language with extremely nice libraries. The
libraries (for visualization, optimization, statistics in my case)
make up for the design errors in the language. I don't love it, but
it feels very productive. ;-)
==
In my field everyone uses IDL. However, I have never used it.
If I had to use some special functions I would try to make a binding
from Bigloo to the gnu scientific library.
It would be nice to have a place where to look up basic functions
written in plain simple C. The problem often with bindings: it is damn
hard. I wrote my own binding to the plotting library DISLIN. But I
would get stuck if I had to start writing a binding to lets say the R
language for statistics. The basic layout of the R language functions
in C is complicated.
I think it often depends on the individual whether he uses something
different than the mainstream. For example Python has been cheerled
quite a lot by F. Dubois in the journal "Computing in Science and
Engineering". As I understand it: Python is predestined for steering
code.
I for one steer legacy radiative transfer codes in Fortran by means of
Bigloo. I couldn't think of another way as to use Bigloo for pre- and
post-processing my tasks. I couldn't even think programming in Scheme
without adding some basic types:
--
(define
(add-vec::vector vec1::vector vec2::vector x::bint)
....)
--
Förster vom Silberwald
mau...@gmail.com
Valentino Volonghi aka Dialtone wrote:
> > Ok. No problem. Then most hackers will take out Python of their
> > toolbox...
>
> I doubt this will happen only because they removed lambda, reduce,
> filter and company.
Sure, it is just a small part of the major Python development trend.
Trend leading to another one Visual Basic...
> > Python wants to be Java or Visual Basic? Then it will be used only
by
> > the
> > people of Visual Basic IQ level...
>
> This is offensive, and plain false,
This can't be directly concluded from the referred GvR quote, but from
the other sources it is clean that he is going to "simplify" the
language
as much as possible (e.g. - remember the tail recursion issue).
Brandon J. Van Every
> "Brandon J. Van Every" <try_vanevery_a...@yahoo.com>
> wrote:
>
>> I will wager 0 game artists touch lisp code. Would love to hear any
>> anecdotes to the contrary, even in hobbyist open source development.
>
> Perhaps they don't talk about it, because if the competitors uses it,
> too, they would lost an advantage, but there are some known stories:
>
> http://groups.google.com/groups?selm=lak7reuqel.fsf%40buzz.in-fusio.com
Naughty Dog is well known in the game industry for having used their
homespun Game Object Assembly Lisp. The question is, did their artists
touch it? Another question is, how similar to Common Lisp is it, from the
artist's point of view? Did Naughty Dog add any features to make it easier
for artists to manipulate?
Square is interesting for using straight up ACL (correct assumption?)
Again, what did the artists touch?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
Matthias
> Matthias <no...@spam.pls> wrote:
> > Exactly. Seconds to minutes for C++ and several hours for Python. I
> > don't have the timings at my fingertips, but I did do them and the
> > 1000 is accurate.
>
> This is way too much IMHO. There is a package called numarray that is
> exactly used to work on satellite images from hubble space telescope.
It's also too much in my opinion. I used numpy, I think. But each
time I lead an actual Python function operate on the image things
slowed down tremendously.
> Surely Matlab has a lot of good libraries optimized for this. But there
> is plenty of packages to do a lot of the computations you need. For
> example: matplotlib, numarray or Numeric, the scipy package and many
> more like biopython (which has nothing to do with this particular
> field).
Thanks for telling me what I need.
Brandon J. Van Every
>
> Ok. No problem. Then most hackers will take out Python of their
> toolbox...
> Python wants to be Java or Visual Basic? Then it will be used only by
> the people of Visual Basic IQ level...
That strikes me as naked, unfounded prejudice. The vast majority of Python
code is not relying on being fancy brainy brilliant.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
James Graves
> Peter Seibel <pe...@gigamonkeys.com> wrote:
>
> > Looks like the BDFL is planning to take lambda, reduce, filter, and
> > map out of Python in the next big rev of Python (so called Python
> > 3000):
> >
> > <http://www.artima.com/weblogs/viewpost.jsp?thread=98196>
>
>Basically, it says that it will get rid of the explicit map, filter
>and reduce and substitute them by some syntactic sugar that uses them
>implicitly. That's ok, and not a big deal.
>
>It will also get rid of lambda, and it's not a great loss, since
>python's version is so limited that it's almost useless. Besides,
>given the syntactic sugar used to replace map, reduce and filter,
>there's no real need for lambda in the most usual cases.
It is my opinion that this is a natural consequence of infix notation,
deep operator precedence heirarchy, and consequently no macro system.
With Lisp, you have the good, solid, general constructs. And if you
need syntactic sugar (like WHEN, for example), you can just build
it up using macros.
So with Python 3000, you're going to end up with a language just as big
as CL, but without the most fundamental building blocks. Ah well, to
each his own.
My Road to Lisp was long and twisty. For a while it covered some Python
territory. But I started look into where exactly the interesting bits
of Python came from. And here I am. Though I've still got a lot to
learn.
James Graves
Valentino Volonghi aka Dialtone
> This can't be directly concluded from the referred GvR quote, but from
> the other sources it is clean that he is going to "simplify" the
> language
> as much as possible (e.g. - remember the tail recursion issue).
Simplyfing a language is a good choice. Complex constructs like
descriptors or metaclasses are always there, but having a small core
language with a good standard library is a respectable choice, and I
would say this is the choice that lisp developers made with macros.
In python you don't want to use recursion because function calls are
very expensive compared to other languages.
Also list comprehensions are almost always faster and more flexible than
any combination of filter and map because of particular bytecode
optimizations in list comprehensions. Lately generator expressions have
been added to the language to allow lazy list construction.
mau...@gmail.com
Valentino Volonghi aka Dialtone wrote:
>
> > This can't be directly concluded from the referred GvR quote, but
from
> > the other sources it is clean that he is going to "simplify" the
> > language
> > as much as possible (e.g. - remember the tail recursion issue).
>
> Simplyfing a language is a good choice. Complex constructs like
> descriptors or metaclasses are always there, but having a small core
> language with a good standard library is a respectable choice, and I
> would say this is the choice that lisp developers made with macros.
True. And you have to select a correct, orthogonal core. Lambda is a
best possible base for such a core.
> In python you don't want to use recursion because function calls are
> very expensive compared to other languages.
No. GvR said that "recursion is too complicated". And, for tail
recursion
you don't have to bother about the function call efficiency.
> Also list comprehensions are almost always faster and more flexible
than
> any combination of filter and map because of particular bytecode
> optimizations in list comprehensions. Lately generator expressions
have
> been added to the language to allow lazy list construction.
Good. Now why they can't use all this brilliant stuff as a backend for
a functional constructions compilation?
Peter Lewerin
> Maybe You can answer my question what this simple LISP function does ?
It obviously returns a function adding n to the function's parameter,
n being bound into the functions's closure during the call to ADDN.
It's simple and straightforward.
> This is correct LISP-syntax if You bear in mind LISPs powerwull macro
> language...
Actually, this suffices:
(defun addn (n)
(lambda (x)
(+ x n)))
And Lisp's "macro language" isn't involved at all here.
Michael Hoffman
> "Kay Schluehr" <kay.sc...@gmx.net> wrote
>
>>Maybe You can answer my question what this simple LISP function does ?
>
> It obviously returns a function adding n to the function's parameter,
> n being bound into the functions's closure during the call to ADDN.
> It's simple and straightforward.
This is off-topic for comp.lang.python. Follow-ups set.
--
Michael Hoffman
Brandon J. Van Every
>
> So with Python 3000, you're going to end up with a language just as
> big as CL, but without the most fundamental building blocks. Ah
> well, to each his own.
Preventing people from building things from scratch is probably an
industrial advantage. Look how fragmented the Lisp world is.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"witch-hunt" - (noun) (Date: 1885)
1: a searching out for persecution of persons accused
of witchcraft
2: the searching out and deliberate harassment of
those (as political opponents) with unpopular views
- witch-hunter (noun)
- witch-hunting (noun or adjective)
mau...@gmail.com
Brandon J. Van Every wrote:
> > Ok. No problem. Then most hackers will take out Python of their
> > toolbox...
> > Python wants to be Java or Visual Basic? Then it will be used only
by
> > the people of Visual Basic IQ level...
>
> That strikes me as naked, unfounded prejudice. The vast majority of
Python
> code is not relying on being fancy brainy brilliant.
Sure. But everybody coding in python knows, that if they'll need
something
a bit more complicated then simple script glue, the language will allow
them to do this with a little afford. Now, without this nice functional
constructions, it will become a pure scripting glue-oriented language,
with the same target problem domain as VBA.
Jacek Generowicz
> Jacek Generowicz wrote:
> > Aaaargh, don't remind me. It pissed me off so much when I read in on
> > Friday, that I didn't want look at Python all day ...
>
> Why look at Python at all?
Because I get paid to do so.
Because it is so much better than so many of the alternatives.
Because, for a certain kind of programmer (the kind I have to cater
for) it is a very good solution.
> That's Python. They might have nicer ad-hoc solutions than the
> C-dialects, but the whitespaces: uuuh.
While the whitespace has it's problems, it actually solves some
problems to. At a certain level, I think it is an excellent idea. And
my job involves catering for that level.
Valentino Volonghi aka Dialtone
> Good. Now why they can't use all this brilliant stuff as a backend for
> a functional constructions compilation?
Probably because it's easy to write a map implementation using list
comprehensions or generator expressions in your personal library.
def map(fun, list):
return [fun(x) for x in list]
def lazy_map(fun, list):
return (fun(x) for x in list)
the same goes for the other functional constructs.
Valentino Volonghi aka Dialtone
> them to do this with a little afford. Now, without this nice functional
> constructions, it will become a pure scripting glue-oriented language,
> with the same target problem domain as VBA.
This is utterly false. Since python has not removed any of the
functionality that those constructs provide (and I would bring some
evidence to support such a high flying statement).
mau...@gmail.com
Valentino Volonghi aka Dialtone wrote:
> > Good. Now why they can't use all this brilliant stuff as a backend
for
> > a functional constructions compilation?
>
> Probably because it's easy to write a map implementation using list
> comprehensions or generator expressions in your personal library.
>
> def map(fun, list):
> return [fun(x) for x in list]
>
> def lazy_map(fun, list):
> return (fun(x) for x in list)
>
> the same goes for the other functional constructs.
The most important is an anonymous functions (lambda). Without them
everything else is useless...
Pascal Costanza
> Simplyfing a language is a good choice. Complex constructs like
> descriptors or metaclasses are always there, but having a small core
> language with a good standard library is a respectable choice, and I
> would say this is the choice that lisp developers made with macros.
You think that it's a good idea to remove lambda but keep metaclasses?
Weird.
> In python you don't want to use recursion because function calls are
> very expensive compared to other languages.
>
> Also list comprehensions are almost always faster and more flexible than
> any combination of filter and map because of particular bytecode
> optimizations in list comprehensions. Lately generator expressions have
> been added to the language to allow lazy list construction.
Does this mean that the Python language design is driven by their
implementors' lack of ability to implement it efficiently?
Pascal
El Pitonero
> The real problem with Python is ... Python is
> going the C++ way: piling feature upon feature, adding bells
> and whistles while ignoring or damaging its core design.
I totally agree.
Look at a recent thread "Compile time evaluation (aka eliminating
default argument hacks)"
where people coming from C++ or other typical programming languages
would do:
x = 1
def _build_used():
y = x + 1
return x, y
def f(_used = _build_used()):
x, y = _used
print x, y
instead of:
x=1
def f():
y=x+1
global f
def f(x=x, y=y):
print x, y
f()
It is easy to see that people have been molded into thinking one way
(declaration of functions, legacy from staticly typed languages),
instead of viewing code also as object that you can tweak.
Valentino Volonghi aka Dialtone
> You think that it's a good idea to remove lambda but keep metaclasses?
> Weird.
lambda was the weird thing in python, not metaclasses.
Metaclasses and descriptors all fit very well inside the new object
model that was added in python 2.2 lots of years ago.
In python lambda is usually replaced with a nested function like this:
def _(result):
return myFun(result[0], result[1])
d = a_function_that_returns_a_deferred_object()
d.addCallback(_)
Using a lambda would have been like:
d = a_function_that_returns_a_deferred_object()
d.addCallback(lambda result: myFun(result[0], result[1]))
I agree, it is shorter, but it's _NOT_ anything that you can't live
without, and most beginners just don't understand lambda.
> Does this mean that the Python language design is driven by their
> implementors' lack of ability to implement it efficiently?
No, that means that it was my opinion, and Guido stated something
different. My opinion is based on my experience with python, this
explains why it is tidied to implementation choices in current CPython.
Fernando
wrote:
>Maybe You can answer my question what this simple LISP function does ?
>
>(defun addn (n)
> #'(lambda (x)
> (+ x n)))
The same as
def addn(n):
def fn(x):
return n + x
return fn
>This is correct LISP-syntax if You bear in mind LISPs powerwull macro
>language...
defun is a macro but I don't think that's what you mean...
Ulrich Hobelmann
> Ulrich Hobelmann <u.hob...@web.de> writes:
>>Why look at Python at all?
>
>
> Because I get paid to do so.
Oh, for a job I wouldn't mind Python at all. Most jobs force you to
Java and C, so that's a rather good deal ;)
> Because it is so much better than so many of the alternatives.
If the above two are the alternatives, yes. (and if you need certain
libraries, I guess, too)
Ulrich Hobelmann
> very expensive compared to other languages.
Which is about the worst design+implementation decision one could ever
make for a language!
Remember the first programming languages (yes, you should use functions
for modularity even though they're dog slow) and the Guy Steele paper:
function calls don't have to be dog slow?
Ulrich Hobelmann
>
> def _(result):
> return myFun(result[0], result[1])
>
> d = a_function_that_returns_a_deferred_object()
> d.addCallback(_)
That's a lambda to me, (even though not called "lambda" and) even though
you have to bind it first. I'm relieved.
> Using a lambda would have been like:
>
> d = a_function_that_returns_a_deferred_object()
> d.addCallback(lambda result: myFun(result[0], result[1]))
>
> I agree, it is shorter, but it's _NOT_ anything that you can't live
> without, and most beginners just don't understand lambda.
Okay, the difference here is unimportant. A wouldn't care about this
little bit of syntax.
Valentino Volonghi aka Dialtone
> > In python you don't want to use recursion because function calls are
> > very expensive compared to other languages.
>
> Which is about the worst design+implementation decision one could ever
> make for a language!
It's not a design choice. Already explained in another post.
> Remember the first programming languages (yes, you should use functions
> for modularity even though they're dog slow) and the Guy Steele paper:
> function calls don't have to be dog slow?
function calls are slow compared to other lower level languages. On my
ibook 1.3Ghz it takes 5-6 microseconds to call a function with a pass
statement inside.
And recursion can be converted into iteration in many different ways.
Pascal Costanza
> Pascal Costanza <p...@p-cos.net> wrote:
>
>>You think that it's a good idea to remove lambda but keep metaclasses?
>>Weird.
>
> lambda was the weird thing in python, not metaclasses.
[...]
> I agree, it is shorter, but it's _NOT_ anything that you can't live
> without, and most beginners just don't understand lambda.
What I find weird is that your claims seem to imply that beginners do
understand metaclasses. Or why are they kept in the language while
lambda is not? This sounds all very random to me.
Do Python beginners understand metaclasses, or is this another feature
that is likely to be removed in the future?
>>Does this mean that the Python language design is driven by their
>>implementors' lack of ability to implement it efficiently?
>
> No, that means that it was my opinion, and Guido stated something
> different. My opinion is based on my experience with python, this
> explains why it is tidied to implementation choices in current CPython.
I don't understand what you are saying at all. You have different
opinions on what is more efficient? Efficiency can be measured, no need
for opinions here.
So: Is tail recursion removed because of efficiency concerns or because
beginners find it hard to understand?
Pascal
Ulrich Hobelmann
> ibook 1.3Ghz it takes 5-6 microseconds to call a function with a pass
> statement inside.
Ouch, and mine has only 800MHz!
> And recursion can be converted into iteration in many different ways.
>
But definitely not always. Also have a look at "The Swine Before Perl"
(PDF-slides) from Shriram Krishnamurti, which explains why tail
recursion is cool :)
Ulrich Hobelmann
> So: Is tail recursion removed because of efficiency concerns or because
> beginners find it hard to understand?
Excellent question, but we also have to ask it to the CL committee.
Why aren't overhead-free tail calls required? If anyone wants to keep
stack records for debugging, there could always be a flag to turn on,
but at least (tail-call guarantee) it preserves some semantics (like a
program running in constant space).
Brandon J. Van Every
>
> Do Python beginners understand metaclasses, or is this another feature
> that is likely to be removed in the future?
Python beginners don't understand anything. That's the strength of the
language, they don't *need* to understand anything. As a person posting on
comp.lang.lisp that may be an alien concept to you. All I can tell you is
that Python is not a "guru language" and isn't going to become one. The
idea that Python can only handle Visual Basic style programming is
prejudicial, but the idea that Python can replace Visual Basic is very
valid.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
Valentino Volonghi aka Dialtone
> What I find weird is that your claims seem to imply that beginners do
> understand metaclasses. Or why are they kept in the language while
> lambda is not? This sounds all very random to me.
There is a tiny difference: lambda is useless in python. Metaclasses are
the foundation of the python object model.
lambdas are only used to have inline functions. Python already has
nested scopes and nested functions/classes.
> Do Python beginners understand metaclasses, or is this another feature
> that is likely to be removed in the future?
No they don't understand metaclasses probably. But since python relies
on metaclasses for its object system they can't go away. lambdas are a
total different story.
> > No, that means that it was my opinion, and Guido stated something
> > different. My opinion is based on my experience with python, this
> > explains why it is tidied to implementation choices in current CPython.
>
> I don't understand what you are saying at all. You have different
> opinions on what is more efficient? Efficiency can be measured, no need
> for opinions here.
In current CPython there's no tail recursion, function calls are rather
expensive ==> recursion is often avoided.
This is what I meant.
Which is the opposite. An implementation detail changed the way people
write code, not the opposite (which is absurd).
> So: Is tail recursion removed because of efficiency concerns or because
> beginners find it hard to understand?
It seems Guido stated this, so yes.
Fred Gilham
> (defun addn (n)
> (lambda (x)
> (+ x n)))
>
> And Lisp's "macro language" isn't involved at all here.
(macroexpand-1 '(lambda (x) (+ x n))) => #'(LAMBDA (X) (+ X N))
Also, #' is a read-macro. Fully expanded the #'(lambda expression
would be
(function (lambda (x) (+ x n)))
Then there's the "defun" macro . . . .
:-)
--
Fred Gilham gil...@csl.sri.com
A common sense interpretation of the facts suggests that a
superintellect has monkeyed with physics, as well as with chemistry
and biology, and that there are no blind forces worth speaking about
in nature. --- Fred Hoyle
Ulrich Hobelmann
> expensive ==> recursion is often avoided.
>
> This is what I meant.
>
> Which is the opposite. An implementation detail changed the way people
> write code, not the opposite (which is absurd).
You think it's GOOD that people change their programming style to match
the limitations of a language implementation??
I don't think it's absurd to change a language's design+impl to allow
people to write code differently.
William Bland
>
> Which is the opposite. An implementation detail changed the way people
> write code, not the opposite (which is absurd).
If you really believe this, I assume you write everything in assembler?
Anything else would be changing the implementation to match the way you
write code, which is apparently absurd.
Cheers,
Bill.
Pascal Costanza
If you allow a flag to switch off tail call optimization, then that
optimiziation is by definition not a required, but an optional one.
Don't mix the levels in the discussion:
- Most CL implementations provide tail call optimization as an option.
- The ANSI CL standard doesn't require them.
- Python doesn't seem to provide them.
- Python doesn't have a standard, we're talking solely about a single
implementation. So there's no "Python standard" to require tail call
optimization or not.
Pascal
Valentino Volonghi aka Dialtone
> Anything else would be changing the implementation to match the way you
> write code, which is apparently absurd.
I don't think you fully understood what I meant.
And I don't write anything in asm.
but this has hardly anything to do with the original topic. Removing
lambda has nothing to do with the python implementation. Lambda in
python is crappy and completely useless except for inline function
definition.
Valentino Volonghi aka Dialtone
> You think it's GOOD that people change their programming style to match
> the limitations of a language implementation??
>
> I don't think it's absurd to change a language's design+impl to allow
> people to write code differently.
The world is full of languages that may or may not match your
programming style.
When I learned CL I had to learn a new programming style and so on for
every language. Every langauge has its idiomatic forms and the
programmer should learn how to write idiomatic code to gain the most out
of a particular language.
To summarize:
if learning a new style has some gains then yes, I think it's good.
Otherwise no, it is not.
James Graves
>James Graves wrote:
>>
>> So with Python 3000, you're going to end up with a language just as
>> big as CL, but without the most fundamental building blocks. Ah
>> well, to each his own.
>
>Preventing people from building things from scratch is probably an
>industrial advantage.
I believe that steering people away from building similar constructs
from scratch is a good thing. You end up different implementations
which do almost, but not quite, the same thing. And that is a hassle to
maintain.
However, trying to _prevent_ this in the language itself is too
restrictive, IMHO. Most (perhaps nearly all) of the time, I should be
using the standard constructs provided by the language base. But there
will be times and circumstances where I will want to build my own, from
the ground up.
And some of these times, that will be the Right Thing to Do, too.
>Look how fragmented the Lisp world is.
I have looked at the Lisp world. In depth. It's not as bad as it used
to be, and it is getting better day-by-day.
If you want a nice enviroment to learn programming, get DrScheme. There
are some good (free!) books out there on the 'net.
If you want to do application development, Common Lisp is where it's at,
no doubt about it. There are more and better libraries for CL these
days, and they are easier to install and manage with tools like ASDF.
Multiple open-source implementations, covering the most popular
platforms (Windows, Linux, Mac).
Cheers,
James Graves
Brandon J. Van Every
> Valentino Volonghi aka Dialtone wrote:
>> In current CPython there's no tail recursion, function calls are
>> rather expensive ==> recursion is often avoided.
>>
>> This is what I meant.
>>
>> Which is the opposite. An implementation detail changed the way
>> people write code, not the opposite (which is absurd).
>
> You think it's GOOD that people change their programming style to
> match the limitations of a language implementation??
Do you think it's good to have a language community be utterly fragmented,
like Lisp? A weakness in one respect can be a strength in another respect.
> I don't think it's absurd to change a language's design+impl to allow
> people to write code differently.
Then clearly you aren't down with the Zen Of Python. Python is about having
One, True, Clear way of doing things, at least in principle, and usually in
practice.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Trollhunt" - (n.) A searching out for persecution
of persons accused of Trolling. (c.f. witch-hunt)
Brandon J. Van Every
>
> If you want to do application development, Common Lisp is where it's
> at, no doubt about it. There are more and better libraries for CL
> these days, and they are easier to install and manage with tools like
> ASDF. Multiple open-source implementations, covering the most popular
> platforms (Windows, Linux, Mac).
Last I looked, 2 years ago?, there were no compiled, open source lisps that
ran on Windows. Has this changed?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
jayessay
> Ulrich Hobelmann wrote:
> > Valentino Volonghi aka Dialtone wrote:
> >> In current CPython there's no tail recursion, function calls are
> >> rather expensive ==> recursion is often avoided.
> >>
> >> This is what I meant.
> >>
> >> Which is the opposite. An implementation detail changed the way
> >> people write code, not the opposite (which is absurd).
> >
> > You think it's GOOD that people change their programming style to
> > match the limitations of a language implementation??
>
> Do you think it's good to have a language community be utterly fragmented,
No.
> like Lisp?
You're living 20+ years ago. What do you claim is fragmented now?
> A weakness in one respect can be a strength in another respect.
True, but in this case that is an irrelevant comment.
> > I don't think it's absurd to change a language's design+impl to allow
> > people to write code differently.
>
> Then clearly you aren't down with the Zen Of Python. Python is about having
> One, True, Clear way of doing things, at least in principle, and usually in
> practice.
Which is why Python really is a dumb language. There simply is no
such thing as "One, True, Clear way of doing things". Only some idiot
working in programming language "design" would ever even think this.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Pascal Costanza
>>Do Python beginners understand metaclasses, or is this another feature
>>that is likely to be removed in the future?
>
> No they don't understand metaclasses probably. But since python relies
> on metaclasses for its object system they can't go away.
Metaclasses are not necessary to set up an object system. There exist
enough object systems / object-oriented languages that don't expose
their metalevel. So a) if the metaclasses are not necessary and b) they
are not understood by beginners, let me ask this question again: Why are
they still part of Python?
My assumption is that sooner or later people do advanced stuff with
Python because that's inevitable. In a similar vein, lambda and other
abstractions could remain part of Python because they make programmers'
lifes easier in the long run.
So to summarize: What I find weird is that in some parts of the
language, beginners' needs are addressed and more advanced stuff is
completely elided whereas in other parts, advanced users' needs are
addressed and beginners are left behind. This looks like a very
unbalanced design to me.
I know programming languages that are either primarily designed as
teaching languages, or else as advanced programming languages for either
academic, pragmatic or domain-specific purposes. What you say gives me
the impression that Python does a little bit of everything. What's the
rationale behind this?
Pascal
Fraca7
> Last I looked, 2 years ago?, there were no compiled, open source lisps that
> ran on Windows. Has this changed?
I don't think so. I recently (about 2 months ago) started to want to learn
Lisp (didn't go far for now) and wanted to find a Windows impl, to
evaluate "cross-platformability". The only open source/free software Lisp
interpreter I found was Common Lisp under Cygwin. Not exactly win32
native. But good enough, I think.
--
One Page Principle:
A specification that will not fit on one page of 8.5x11 inch
paper cannot be understood.
-- Mark Ardis
Edi Weitz
> I don't think so. I recently (about 2 months ago) started to want to
> learn Lisp (didn't go far for now) and wanted to find a Windows
> impl, to evaluate "cross-platformability". The only open source/free
> software Lisp interpreter
Compiler, not interpreter. All available Common Lisp implementations
are compilers - one (CLISP) compiles to bytecode while all others
compile to machine code.
> I found was Common Lisp under Cygwin.
"Common Lisp" is not an implementation but a language (defined by an
ANSI standard).
You're probably talking about CLISP (which is an implementation of the
language Common Lisp) which runs on Cygwin.
> Not exactly win32 native. But good enough, I think.
Native Win32 versions of CLISP are available. And there's also ECL.
Also, if you're just learning CL it's perfectly fine to use the trial
versions of AllegroCL or LispWorks. Why do you need an open source
implementation to learn a language?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Christopher C. Stacy
In what way is the Lisp community fragmented, in your view?
Also, do you consider yourself to be in this community,
or are you looking at this from the outside?
James Graves
>>
>> If you want to do application development, Common Lisp is where it's
>> at, no doubt about it. There are more and better libraries for CL
>> these days, and they are easier to install and manage with tools like
>> ASDF. Multiple open-source implementations, covering the most popular
>> platforms (Windows, Linux, Mac).
>
>Last I looked, 2 years ago?, there were no compiled, open source lisps that
>ran on Windows. Has this changed?
Yes.
GCL compiles to C first. And it has been ported to Windows. It isn't
fully ANSI compliant yet, though they are working on that. I haven't
had to try that yet.
There's talk about a port of SBCL to Windows. But I don't know what
progress has been made on that front.
But coverage in this area (compiled CL) is a bit thin, I'll admit.
James Graves
fraca7
> On Tue, 15 Mar 2005 23:29:04 +0100, Fraca7 <fra...@free.fr> wrote:
>>I don't think so. I recently (about 2 months ago) started to want to
>>learn Lisp (didn't go far for now) and wanted to find a Windows
>>impl, to evaluate "cross-platformability". The only open source/free
>>software Lisp interpreter
> Compiler, not interpreter. All available Common Lisp implementations
> are compilers - one (CLISP) compiles to bytecode while all others
> compile to machine code.
I find it increasingly difficult to discern between an interpreter and a
compiler for a virtual machine. I guess that something that produces
"bytecode" for an actual CPU is a compiler :)
>>I found was Common Lisp under Cygwin.
> "Common Lisp" is not an implementation but a language (defined by an
> ANSI standard)
> You're probably talking about CLISP (which is an implementation of the
> language Common Lisp) which runs on Cygwin.
Indeed, I was.
>>Not exactly win32 native. But good enough, I think.
> Native Win32 versions of CLISP are available. And there's also ECL.
Didn't know about this one, I'll google it.
> Also, if you're just learning CL it's perfectly fine to use the trial
> versions of AllegroCL or LispWorks. Why do you need an open source
> implementation to learn a language?
As a matter of fact, I don't. I actually installed LispWorks on my job
PC, just to experiment. But if I'm going to write actual free software
in LISP, I'd better have it run under an OS/FS Lisp
interpreter/compiler, whatever. I always feel kind of awkward about free
software being written in a proprietary environment, like Delphi [see
Dev-C++]. Maybe it's just me.
--
Just about every computer on the market today runs Unix, except the Mac
(and nobody cares about it).
-- Bill Joy 6/21/85
Valentino Volonghi aka Dialtone
> Metaclasses are not necessary to set up an object system. There exist
> enough object systems / object-oriented languages that don't expose
> their metalevel. So a) if the metaclasses are not necessary and b) they
> are not understood by beginners, let me ask this question again: Why are
> they still part of Python?
Not being exposed to beginners is a completely different matter. And it
seems to me that you don't actually know anything of the python
philosophy. My question is: If you don't understand python, why are you
questioning its design?
> My assumption is that sooner or later people do advanced stuff with
> Python because that's inevitable. In a similar vein, lambda and other
> abstractions could remain part of Python because they make programmers'
> lifes easier in the long run.
People already wrote VERY advanced stuff in python. In the short time
I've been using CL I've never found any framework at Twisted Matrix
level for working on networking and distributed applications so well
integrated and thought out (with tons of protocols already implemented
inside the framework and lots of ready to use code for most of the
jobs). Other people would cite Zope2 and Zope3. Others would talk about
ERP5, others again about Strakt's CAPS, or google.
Let me repeat myself: lambda is completely useless in python. defining a
function for doing the very same thing that you do with a lambda takes
you only one more line.
> So to summarize: What I find weird is that in some parts of the
> language, beginners' needs are addressed and more advanced stuff is
> completely elided whereas in other parts, advanced users' needs are
> addressed and beginners are left behind. This looks like a very
> unbalanced design to me.
Nobody is required to understand metaclasses to work with python. If you
need to do advanced stuff like redefining the way classes are created
then you probably need them, and nothing will stop you from getting to
the root of the problem instead of monkey patching the behaviour of your
objects.
To me this looks like a design which doesn't confuse beginners who will
never need to know (and will probably never know) metaclasses for their
basic homeworks, but helps with advanced uses of the object model.
What's the loss received from removing lambda? Nothing.
What's the loss received from removing metaclasses exposure?
Flexibility.
I'd rather lose nothing instead of flexibility.
But you seem to give lambdas more 'power' than they deserve, and this
probably will eventually be your python ignorance. Which is like me
saying that Lisp cannot be used for big projects because it lacks
syntax, plain false since you can live without syntax, the language
helps with a lot of powerful constructs.
> I know programming languages that are either primarily designed as
> teaching languages, or else as advanced programming languages for either
> academic, pragmatic or domain-specific purposes. What you say gives me
> the impression that Python does a little bit of everything. What's the
> rationale behind this?
Python is easy to use. But it's made for 'adults who know what they are
doing', which means that doesn't prevent you from doing what you think
is better for your particular job.
Philip J. Eby also implemented a CLOS like object model using decorators
in python in less than 1500 LOC in pyprotocols.dispatch.
Is there anything weird in teaching newbies to drive with N2 under the
passenger seat in case you need it?
You are probably missing the fact that lambda is useless in python (I
repeat myself again) while metaclasses are not and it's a common
practice to give hooks to the programmer to attach to python behaviours.
HTH, cheers :)
Pascal Costanza
> Edi Weitz wrote:
>
>> On Tue, 15 Mar 2005 23:29:04 +0100, Fraca7 <fra...@free.fr> wrote:
>
>>> I don't think so. I recently (about 2 months ago) started to want to
>>> learn Lisp (didn't go far for now) and wanted to find a Windows
>>> impl, to evaluate "cross-platformability". The only open source/free
>>> software Lisp interpreter
>
>> Compiler, not interpreter. All available Common Lisp implementations
>> are compilers - one (CLISP) compiles to bytecode while all others
>> compile to machine code.
>
> I find it increasingly difficult to discern between an interpreter and a
> compiler for a virtual machine. I guess that something that produces
> "bytecode" for an actual CPU is a compiler :)
...and a CPU is an interpreter for such "bytecode". As soon as you grasp
that concept, enlightenment will follow... ;-)
Pascal
Christopher C. Stacy
> Last I looked, 2 years ago?, there were no compiled, open source
> lisps that ran on Windows. Has this changed?
GCL (formerly known as KCL and ACL) has been around since 1984,
and has been available on Windows since 2000.
ECL (another KCL derivative) has been available since about 1990.
Corman Common Lisp only runs on Windows, and has been available since 1998.
There might be others; those are off the top of my head.
I am also not counting here any Lisp implementations that
ran on Windows under the Cygwin support; just native ones.
Historically, compiled open-souce Lisp implementations
have been available since the 1960s.
All this information has been available in FAQs and
on many web pages since forever.
Ulrich Hobelmann
> If you allow a flag to switch off tail call optimization, then that
> optimiziation is by definition not a required, but an optional one.
No, the turning OFF is optional. The TCO-opt would be a requirement,
like in Scheme.
> Don't mix the levels in the discussion:
>
> - Most CL implementations provide tail call optimization as an option.
In CL TCO is optional, yes.
That might be fine, if you have the right implementation. :)
> - The ANSI CL standard doesn't require them.
> - Python doesn't seem to provide them.
That's one of its faults ;)
> - Python doesn't have a standard, we're talking solely about a single
> implementation. So there's no "Python standard" to require tail call
> optimization or not.
One implementation isn't bad necessarily, but most good languages
somehow spawn multiple implementations, maybe because they aren't
dogmatic about how everything works. (all the Schemes with different
stackful/stackless engines...)