«

Kay> Maybe You can answer my question what this simple LISP function does ?
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

>>>>> "Tim" == Tim Daneliuk <> writes:

Tim> Except that in this case, removal will also complicate code
Tim> in some cases. Consider this fragment of Tkinter logic:

Tim> UI.CmdBtn.menu.add_command(label="MyLabel",
Tim> command=lambda cmd=cmdkey: CommandMenuSelection(cmd))

Tim> Would it not be the case that, without lambda, we will need
Tim> to pollute the name space with a bunch of specialized little
Tim> functions for each and every construct like this?

You can reuse the same name for all those little functions to avoid
polluting the namespace. Choose 'L' if it gives you that cozy
lambda-ish feel.

--
Ville Vainio http://tinyurl.com/2prnb

>>>>> "Torsten" == Torsten Bronger <> writes:

>>> There would be keywords for static and class methods, no
>>> distinction between Unicode and non-Unicode

>> You couldn't do that 15 years ago because there were no Unicode
>> that time.

Torsten> I've never said that Guido was just too stupid at that
Torsten> time. I only said "but you can definitely see that it's
Torsten> the oldest one". In other words, a Ruby six years older
Torsten> than the real one would have the same problem. And who
Torsten> knows how C# looks like in 10 years.

http://c2.com/cgi/wiki?PythonVsRuby

seems to suggest that Python has better Unicode support than Ruby.

--
Ville Vainio http://tinyurl.com/2prnb

Hallöchen!

Ville Vainio <> writes:

>>>>>> "Torsten" == Torsten Bronger <> writes:
>
> >>> There would be keywords for static and class methods, no
> >>> distinction between Unicode and non-Unicode
>
> >> You couldn't do that 15 years ago because there were no Unicode
> >> that time.
>
> Torsten> I've never said that Guido was just too stupid at that
> Torsten> time. I only said "but you can definitely see that it's
> Torsten> the oldest one". In other words, a Ruby six years older
> Torsten> than the real one would have the same problem. And who
> Torsten> knows how C# looks like in 10 years.
>
> http://c2.com/cgi/wiki?PythonVsRuby
>
> seems to suggest that Python has better Unicode support than Ruby.

True. When you google for it, you read "Japanese hate Unicode".
:-/ Well, then this is an invalid example.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

Fernando wrote:
> On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel
<>
> 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.

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.

[, Tue, 15 Mar 2005 13:10:52 +0100]:
> It's indeed correct CL syntax, but I don't see much macro usage in there.

defun?

Albert.

Torsten Bronger wrote:
> (Paul Boddie) writes:
>>
>>Well, I've been using Python for almost ten years, and I've
>>managed to deliberately ignore descriptors and metaclasses quite
>>successfully. I get the impression that descriptors in particular
>>are a detail of the low-level implementation that get a
>>disproportionate level of coverage because of the "hack value"
>>they can provide (albeit with seemingly inappropriate application
>>to certain problem areas).
>
> I have exactly the same impression, but for me it's the reason why I
> feel uncomfortable with them. For example, I fear that a skilled
> package writer could create a module with surprising behaviour by
> using the magic of these constructs. I don't know Python well
> enough to get more specific, but flexibility almost always make
> confusing situations for non-hackers possible.
>
> I know that such magic is inavoidable with dynamic languages, but
> descriptors will be used almost exclusively for properties, and
> therefore I think it would have been better to hard-wire properties
> in the interpreter rather than pollute the language with this sort
> of proto-properties (aka descriptors).

Certainly descriptors in the "wrong hands" could lead to confusing,
unreadable code. But Python is a "we're all adults here" language, and
so we have to trust other coders to be responsible. There are some very
reasonable uses for descriptors which I don't believe are really
confusing, for example the lazy property recipe:

http://aspn.activestate.com/ASPN/Coo.../Recipe/363602

While writing too many descriptors is a code smell, the functionality is
there as an implementation detail of new-style classes, and I'm quite
happy that Python trusts me enough to expose this detail for when I need it.

STeVe

Fernando <> wrote:

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

"Kay Schluehr" <> 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 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.

Peter Lewerin wrote:
> "Kay Schluehr" <> 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