Re: Python becoming less Lisp-like

"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > And does this code object know which non-local names are on an > intermediate level and which are global? Yes (from 2.2): >>> import dis >>> x = 1 >>> def f(): ... y = 2 ... def g(): ...z = 3 ...print x,y,z

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

On 16 Mar 2005 06:37:45 -0500, Carl Shapiro <[EMAIL PROTECTED]> wrote: >I have a virtually completed port of CMUCL to Win32. And, if I was >not busy organizing a Lisp conference, it would be publicly available >by now. If it's the conference I think, then the deadline for papers was about a week

Re: Python becoming less Lisp-like

Op 2005-03-22, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>: >> >>>Antoon Pardon wrote: >>> Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>: I find it odd that you start by saying you still find the

Re: Python becoming less Lisp-like

Antoon Pardon wrote: Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>: Antoon Pardon wrote: Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>: I find it odd that you start by saying you still find them very consistent and here state there is a slight inconsistency. I said that the way

Re: Python becoming less Lisp-like

Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>: >> >> I find it odd that you start by saying you still find them very >> consistent and here state there is a slight inconsistency. > > I said that the way th

Re: Python becoming less Lisp-like

Antoon Pardon wrote: Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>: I find it odd that you start by saying you still find them very consistent and here state there is a slight inconsistency. I said that the way that binding a name on a class instance always creates an instance attribute

Re: Python becoming less Lisp-like

Op 2005-03-18, Bengt Richter schreef <[EMAIL PROTECTED]>: > [ ... ] > > BTW, I would like a re-assign or find-and-rebind operation spelled ":=" which > would > make x := 123 mean look for x as if to read its value in a right hand side > expression, > (except do not look into __builtins__) and wh

Re: Python becoming less Lisp-like

Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>: >> >>>Bruno Desthuilliers wrote: >>> - if x is a class attribute of class A and a is an instance of A, a.x=anyvalue create a new instance attribute x

Re: Python becoming less Lisp-like

On Fri, 18 Mar 2005 09:16:42 -0800, Jeff Shannon <[EMAIL PROTECTED]> wrote: >Antoon Pardon wrote: >> Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>: >> >>>Bruno Desthuilliers wrote: >>> - if x is a class attribute of class A and a is an instance of A, a.x=anyvalue create a new i

Re: Python becoming less Lisp-like

Antoon Pardon wrote: Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>: Bruno Desthuilliers wrote: - if x is a class attribute of class A and a is an instance of A, a.x=anyvalue create a new instance attribute x instead of modifying A.x This is very consistent with the way that binding a nam

Re: Python becoming less Lisp-like

Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>: > Bruno Desthuilliers wrote: > >> A few examples: > [...] >> - to get the length of a sequence, you use len(seq) instead of seq.len() >> - to call objects attributes by name, you use [get|set]attr(obj, name >> [,value]) instead of obj.[get|s

Re: Python becoming less Lisp-like

Paul Boddie wrote: > The principal advantage of the property function was to permit the > definition of "active" attributes without having a huge > "if...elif...else" statement in the __getattr__ method. So the > motivation was seemingly to externalize the usually simple logic in > __getattr__ so

REPOST: Re: Python becoming less Lisp-like

> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> 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 sai

REPOST: Re: Python becoming less Lisp-like

> "Tim" == Tim Daneliuk <[EMAIL PROTECTED]> 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: CommandMenuSelect

Re: Python becoming less Lisp-like

Jeff Shannon <[EMAIL PROTECTED]> wrote: > Because they may get stuck maintaining code that uses those features. > Now, I'm generally in agreement with you -- in general, Python > features that aren't straightforward (e.g. metaclasses) are clearly > advanced features and aren't likely to be in

Re: Python becoming less Lisp-like

Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>: > news.sydney.pipenetworks.com wrote: > >> More in relation to the original topic, why can't people just ignore >> features they don't understand and may never use directly. > > Because they may get stuck maintaining code that uses those fe

Re: Python becoming less Lisp-like

Kay Schluehr schrieb: Some people refused properties in Python for exactly this reason. Defining somewhat like: def _get_X(self): return self._X def _set_X(self,X): self._X = X X = property(_get_X, _set_X ) in a Java-style fashion is indeed awfull and clumsy and that people dismiss such boi

Re: Python becoming less Lisp-like

"Kay Schluehr" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > Some people refused properties in Python for exactly this reason. > Defining somewhat like: > > def _get_X(self): > return self._X > > def _set_X(self,X): > self._X =3D X > > X =3D property(_get_X, _set_

Re: Python becoming less Lisp-like

Mike Meyer <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > The real problem is that newbies won't know which features are "meta" > features best left to experts, and which features are ok for everyday > programmers to use. I think the original contributor to this thread was f

Re: Python becoming less Lisp-like

> "Mike" == Mike Meyer <[EMAIL PROTECTED]> writes: Mike> The real problem is that newbies won't know which features Mike> are "meta" features best left to experts, and which features Mike> are ok for everyday programmers to use. I suppose that a typical lazy newbie will just skip

Re: Python becoming less Lisp-like

Jeff Shannon wrote: news.sydney.pipenetworks.com wrote: More in relation to the original topic, why can't people just ignore features they don't understand and may never use directly. Because they may get stuck maintaining code that uses those features. Now, I'm generally in agreement with you

Re: Python becoming less Lisp-like

On Wed, 16 Mar 2005 16:35:57 -0600, Mike Meyer wrote: > The real problem is that newbies won't know which features are "meta" > features best left to experts, and which features are ok for everyday > programmers to use. > > We recently saw a thread (couldn't find it in google groups) where > some

Re: Python becoming less Lisp-like

[EMAIL PROTECTED] (Paul Boddie) writes: > Steven Bethard <[EMAIL PROTECTED]> wrote in message news:<[EMAIL > PROTECTED]>... >> >> 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 trus

Re: Python becoming less Lisp-like

news.sydney.pipenetworks.com wrote: More in relation to the original topic, why can't people just ignore features they don't understand and may never use directly. Because they may get stuck maintaining code that uses those features. Now, I'm generally in agreement with you -- in general, Pytho

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

Carl Shapiro wrote: > "Brandon J. Van Every" <[EMAIL PROTECTED]> > writes: > >> Last I looked, 2 years ago?, there were no compiled, open source >> lisps that ran on Windows. Has this changed? > > I have a virtually completed port of CMUCL to Win32. [etc] Ah, so you're the brave lad I heard abou

Re: Python becoming less Lisp-like

Torsten Bronger wrote: > Hallöchen! Moin! > [First, I wanted to say "descriptors" instead of "decorators" (I > superseded my post).] > > The goal is to trigger function calls when attributes are accessed. > This is called properties in C# (and maybe in Ruby, too). Python > now also has this conc

[OT] Re: Python becoming less Lisp-like

news.sydney.pipenetworks.com said unto the world upon 2005-03-16 05:57: trust the guy to do a good job. If you don't, then you can write it yourself which means you can do exactly how you want it which again makes the whole argument mute. Anyone else having images of mimes engaged in street figh

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

"Brandon J. Van Every" <[EMAIL PROTECTED]> writes: > Last I looked, 2 years ago?, there were no compiled, open source lisps that > ran on Windows. Has this changed? I have a virtually completed port of CMUCL to Win32. And, if I was not busy organizing a Lisp conference, it would be publicly ava

Re: Python becoming less Lisp-like

Torsten Bronger wrote: HallÃchen! "news.sydney.pipenetworks.com" <[EMAIL PROTECTED]> writes: Torsten Bronger wrote: [...] 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 wit

Re: Python becoming less Lisp-like

HallÃchen! "news.sydney.pipenetworks.com" <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> [...] >> >> 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 su

Re: Python becoming less Lisp-like

Steven Bethard <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > 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. The problem is

Re: Python becoming less Lisp-like

Fernando schrieb: 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 forc

Re: Python becoming less Lisp-like

On Tue, 15 Mar 2005 03:21:48 -0800, Paul Boddie wrote: > 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

Re: Python becoming less Lisp-like

Thomas Bellman wrote: Torsten Bronger <[EMAIL PROTECTED]> wrote: Just to amplify Thomas' statements... ... And inflexibility will always make some situations horribly daunting to get out of. Powerful constructs like these can, in some cases, enable a skilled package writer to design an API that

Re: Python becoming less Lisp-like

Torsten Bronger wrote: HallÃchen! [EMAIL PROTECTED] (Paul Boddie) writes: Torsten Bronger <[EMAIL PROTECTED]> wrote: At first, I was very pleased by Python's syntax (and still I am). Then, after two weeks, I learned about descriptors and metaclasses and such and understood nothing (for the first

Re: Python becoming less Lisp-like

Bruno Desthuilliers wrote: Valentino Volonghi aka Dialtone a écrit : Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: It is actually. Ruby's syntax is mostly consistent and coherent, and there is much less special cases than in Python. I'd be glad to know which special cases are you referring to.

Re: Python becoming less Lisp-like

Bruno Desthuilliers wrote: news.sydney.pipenetworks.com a Ãcrit : 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 Pytho

Re: Python becoming less Lisp-like

Kent Johnson wrote: Steven Bethard wrote: Bruno Desthuilliers wrote: class CommandMenuSelectionCallback: def __init__(self, key): self.key = key def __call__(self): print self.key Looks like Java. When was the last time you used Java? It has no support for using classes a

Re: Python becoming less Lisp-like

Bruno Desthuilliers wrote: A few examples: [...] - to get the length of a sequence, you use len(seq) instead of seq.len() - to call objects attributes by name, you use [get|set]attr(obj, name [,value]) instead of obj.[get|set]attr(name [,value]) These are both very consistent applications of a mor

Re: Python becoming less Lisp-like

Steven Bethard wrote: Bruno Desthuilliers wrote: class CommandMenuSelectionCallback: def __init__(self, key): self.key = key def __call__(self): print self.key Looks like Java. When was the last time you used Java? It has no support for using classes as callable objects.

Re: Python becoming less Lisp-like

Martin Franklin wrote: Tim Daneliuk wrote: Except that in this case, removal will also complicate code in some cases. Consider this fragment of Tkinter logic: UI.CmdBtn.menu.add_command(label="MyLabel", command=lambda cmd=cmdkey: CommandMenuSelection(cmd)) In this cas

Re: Python becoming less Lisp-like

Torsten Bronger <[EMAIL PROTECTED]> wrote: > 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. If the b

Re: Python becoming less Lisp-like

Bruno Desthuilliers wrote: class CommandMenuSelectionCallback: def __init__(self, key): self.key = key def __call__(self): print self.key Looks like Java. When was the last time you used Java? It has no support for using classes as callable objects. __call__ would have t

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

James Graves wrote: > > But coverage in this area (compiled CL) is a bit thin, I'll admit. > But who really cares? After all, there are the mature commercial proprietary lisp compilers for those people who insist on using closedware OSes, and they've already proven they're willing to use close

Re: Python becoming less Lisp-like

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > A few examples: > - A statement is different from an expression (2 special cases instead > of one general case). > - You can't use statements in a lambda Good reason to remove lambda, let's do this asap. > - to get the length of a sequence, you u

Re: Python becoming less Lisp-like

Martin Franklin a écrit : Tim Daneliuk wrote: In-Reply-To: <[EMAIL PROTECTED]> (snip) Of course we users will complain about removals, but we'll knuckle down and take our medicine eventually ;-) Except that in this case, removal will also complicate code in some cases. Consider this fragment of Tk

Re: Python becoming less Lisp-like

Valentino Volonghi aka Dialtone a écrit : Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: It is actually. Ruby's syntax is mostly consistent and coherent, and there is much less special cases than in Python. I'd be glad to know which special cases are you referring to. A few examples: - A stateme

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

"Brandon J. Van Every" <[EMAIL PROTECTED]> writes: > 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 deri

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

Brandon J. Van Every <[EMAIL PROTECTED]> wrote: >James Graves wrote: >> >> 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. Mul

Re: compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

On Tue, 15 Mar 2005 12:25:02 -0800, Brandon J. Van Every wrote: > 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

compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

James Graves wrote: > > 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 p

Re: Python becoming less Lisp-like

Brandon J. Van Every <[EMAIL PROTECTED]> wrote: >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 prob

Re: Python becoming less Lisp-like

Fernando wrote: > 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)" ht

Re: Python becoming less Lisp-like

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. Look how fragmented the

Re: Python becoming less Lisp-like

Fernando <[EMAIL PROTECTED]> wrote: > Peter Seibel <[EMAIL PROTECTED]> 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): > > > >

Re: Python becoming less Lisp-like

Torsten Bronger wrote: [EMAIL PROTECTED] (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

Re: Python becoming less Lisp-like

Fernando wrote: > On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel <[EMAIL PROTECTED]> > 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): > > > >

Re: Python becoming less Lisp-like

HallÃchen! Ville Vainio <[EMAIL PROTECTED]> writes: >> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> 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

Re: Python becoming less Lisp-like

> "Torsten" == Torsten Bronger <[EMAIL PROTECTED]> 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 sai

Re: Python becoming less Lisp-like

> "Tim" == Tim Daneliuk <[EMAIL PROTECTED]> 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: CommandMenuSelect

Re: Python becoming less Lisp-like

HallÃchen! [EMAIL PROTECTED] (Paul Boddie) writes: > Torsten Bronger <[EMAIL PROTECTED]> wrote: > >> At first, I was very pleased by Python's syntax (and still I am). >> Then, after two weeks, I learned about descriptors and >> metaclasses and such and understood nothing (for the first time >> in

Re: Python becoming less Lisp-like

Torsten Bronger <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > > At first, I was very pleased by Python's syntax (and still I am). > Then, after two weeks, I learned about descriptors and metaclasses > and such and understood nothing (for the first time in syntax I felt > total

Re: Python becoming less Lisp-like

Carl Banks schrieb: In Python, classes aren't some magical land where the usual rules don't hold (as they are in many other languages). That's why "self." is used on class variables, for instance. A class is nothing more than a scope that uses a smittering of magic to turn it into a type. scope -

Re: Python becoming less Lisp-like

Tim Daneliuk wrote: In-Reply-To: <[EMAIL PROTECTED]> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nick Craig-Wood wrote: Torsten Bronger <[EMAIL PROTECTED]> wrote: The current snaps

Re: Python becoming less Lisp-like

HallÃchen! "Serge Orlov" <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >>> Interesting. I've never thought that. What parts strike you as >>> "patchwork"? >> >> Well, with a little bit of experience in the field of programming >> languages, you can see which elements had been added lat

Re: Python becoming less Lisp-like

Torsten Bronger wrote: > > Interesting. I've never thought that. What parts strike you as > > "patchwork"? > > Well, with a little bit of experience in the field of programming > languages, you can see which elements had been added later (ie years > after Python's creation). Properties surely wo

Re: Python becoming less Lisp-like

In-Reply-To: <[EMAIL PROTECTED]> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nick Craig-Wood wrote: > Torsten Bronger <[EMAIL PROTECTED]> wrote: > >> The current snapshot is a tra

Re: Python becoming less Lisp-like

Torsten Bronger wrote: > Steven Bethard <[EMAIL PROTECTED]> writes: > > Interesting. I've never thought that. What parts strike you as > > "patchwork"? > > Well, with a little bit of experience in the field of programming > languages, you can see which elements had been added later (ie years > a

Re: Python becoming less Lisp-like

Torsten Bronger <[EMAIL PROTECTED]> wrote: > The current snapshot is a transitional Python and thus > with some double features. The numerical types and two kinds of > classes are examples. I'm very surprised about this, because Python > is a production language, but I'm happy, too. As long

Re: Python becoming less Lisp-like

HallÃchen! Steven Bethard <[EMAIL PROTECTED]> writes: > Torsten Bronger wrote: > >> 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). > > What do you find ugly about __getattr__?

Re: Python becoming less Lisp-like

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > It is actually. Ruby's syntax is mostly consistent and coherent, and > there is much less special cases than in Python. I'd be glad to know which special cases are you referring to. Please note that you wrote "much less" which means there are prob

Re: Python becoming less Lisp-like

Torsten Bronger wrote: 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. Howe

Re: Python becoming less Lisp-like

news.sydney.pipenetworks.com a Ãcrit : 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 s

Re: Python becoming less Lisp-like

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

Re: Python becoming less Lisp-like

On Tue, 15 Mar 2005 00:01:09 +0100, Torsten Bronger <[EMAIL PROTECTED]> wrote: >> 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 >

Re: Python becoming less Lisp-like

Torsten Bronger wrote: 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). What do you find ugly about __getattr__? I looked for a new language for my hobby programming. [snip] I want to go

Re: Python becoming less Lisp-like

HallÃchen! Fernando <[EMAIL PROTECTED]> 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

Re: Python becoming less Lisp-like

On Sun, 13 Mar 2005 18:23:05 GMT, Peter Seibel <[EMAIL PROTECTED]> 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): > > Basically, it sa