Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

On Apr 28, 11:49 pm, David Bolen wrote: > Vsevolod writes: > > On Apr 27, 11:31 pm, David Bolen wrote: > >> I'm curious - do you know what happens if threading is implemented as > >> a native OS thread and it's stuck in an I/O operation that is blocked? > >> How does the Lisp interpreter/runtime

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

David Bolen wrote: Vsevolod writes: On Apr 27, 11:31 pm, David Bolen wrote: I'm curious - do you know what happens if threading is implemented as a native OS thread and it's stuck in an I/O operation that is blocked? How does the Lisp interpreter/runtime gain control again in order to execut

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

Vsevolod writes: > On Apr 27, 11:31 pm, David Bolen wrote: >> I'm curious - do you know what happens if threading is implemented as >> a native OS thread and it's stuck in an I/O operation that is blocked? >> How does the Lisp interpreter/runtime gain control again in order to >> execute the spe

Re: Lisp mentality vs. Python mentality

Dan Sommers escreveu: Yes, I agree: Python and Lisp are extremely dynamic languages. I *can* redefine map, reduce, +, and other operators and functions, but I know better. When is the last time you examined someone else's code, and asked them what their "map" function did (in Lisp or in Pyth

Re: Lisp mentality vs. Python mentality

On Tue, 28 Apr 2009 02:00:22 -0300, namekuseijin wrote: > Dan Sommers wrote: >> On Mon, 27 Apr 2009 07:57:00 +0300, Ciprian Dorin, Craciun wrote: >>> I agree with your opinion about keeping the abstraction layers >>> shallow, but in my view high-order and helper functions do not >>> comprise a

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

In article <9a827369-b36f-4a86-870a-e5a505e34...@q33g2000pra.googlegroups.com>, Vsevolod wrote: >On Apr 27, 8:18 pm, a...@pythoncraft.com (Aahz) wrote: >> >> If you want to talk about Python and problems you're running into, you >> should start a new thread. > >I'm not at that level of proficien

Re: Lisp mentality vs. Python mentality

Dan Sommers wrote: On Mon, 27 Apr 2009 07:57:00 +0300, Ciprian Dorin, Craciun wrote: I agree with your opinion about keeping the abstraction layers shallow, but in my view high-order and helper functions do not comprise a new abstraction layer. For example in Lisp, using map, reduce (fold),

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

On Apr 27, 11:31 pm, David Bolen wrote: > I'm curious - do you know what happens if threading is implemented as > a native OS thread and it's stuck in an I/O operation that is blocked? > How does the Lisp interpreter/runtime gain control again in order to > execute the specified function? I guess

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

On Apr 27, 8:18 pm, a...@pythoncraft.com (Aahz) wrote: > That's because there's no response to make; the original post was a joke, > and trying to have a serious discussion about it rarely excites people. In every joke there's a grain of truth. And usenet is precisely for that thing -- discussions

Re: Lisp mentality vs. Python mentality

On Mon, 27 Apr 2009 07:57:00 +0300, Ciprian Dorin, Craciun wrote: > On Mon, Apr 27, 2009 at 2:14 AM, Dan Sommers > wrote: >> Also from the Zen:  flat is better than nested.  One of the aspects of >> flatter call trees and object hierarchies is that I hit the bottom >> (language features or the s

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

David Bolen writes: > I'm curious - do you know what happens if threading is implemented as > a native OS thread and it's stuck in an I/O operation that is blocked? > How does the Lisp interpreter/runtime gain control again in order to > execute the specified function? I guess on many POSIX-ish >

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

Vsevolod writes: > "This should be used with caution: it is implementation-defined > whether the thread runs cleanup forms or releases its locks first." > This doesn't mean deprecated. It means: implementation-dependent. For > example in SBCL: "Terminate the thread identified by thread, by > caus

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

In article <22272831-8d11-42d6-a587-9a2ab4712...@p6g2000pre.googlegroups.com>, Vsevolod wrote: > >Yet there was no response to my point, that the original example was >not realistically depicting the Lisp world, while more characteristic >of the Python one. That's because there's no response to

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

On Apr 27, 7:16 pm, a...@pythoncraft.com (Aahz) wrote: > Did you see my comment about Java? This particular issue has little to > do with Python. I won't disagree that what you're describing is > sometimes a problem in the Python community, but you're picking the > wrong issue to claim its releva

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

In article <42cebb2b-0361-416c-8932-9371da50a...@y6g2000prf.googlegroups.com>, Vsevolod wrote: > >As well I'd like to outline, that, IMO, your answer exhibits the >common attitude among pythonistas: everything should be done in one >true way, which is the best option (and that is how it's impleme

Re: Lisp mentality vs. Python mentality

On Apr 24, 11:06 pm, Carl Banks wrote: > In answering the recent question by Mark Tarver, I think I finally hit > on why Lisp programmers are the way they are (in particular, why they > are often so hostile to the "There should only be one obvious way to > do it" Zen). > > Say you put this task to

Re: Lisp mentality vs. Python mentality

Carl Banks writes: > > > Presumably you have to protect objects to share them?  There you go: > > > anytime you try to acquire a lock have the thread check to see whether > > > to abort. > > > > Normally, acquiring a lock doesn't require running code in other > > threads, at least in the uncontend

Re: Lisp mentality vs. Python mentality

Scott David Daniels wrote: I don't remember who, but something famously said, in effect: Debugging is hard, maybe twice as hard as writing the code in the first place. Unless you are one of those nonexistent few He would be the K in K&R. -- http://mail.python.org/mailman/listinfo/pyth

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

On Mon, Apr 27, 2009 at 11:55 AM, Vsevolod wrote: > > As well I'd like to outline, that, IMO, your answer exhibits the > common attitude among pythonistas: everything should be done in one > true way, which is the best option (and that is how it's implemented > in the current version of the langu

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

On Apr 27, 2:17 pm, "Richard Brodie" wrote: > "Vsevolod" wrote in message > > news:42cebb2b-0361-416c-8932-9371da50a...@y6g2000prf.googlegroups.com... > > > There's a common unification library -- bordeaux-threads -- > > that abstracts away implementation specifics. It's API includes > > the func

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

"Vsevolod" wrote in message news:42cebb2b-0361-416c-8932-9371da50a...@y6g2000prf.googlegroups.com... > There's a common unification library -- bordeaux-threads -- > that abstracts away implementation specifics. It's API includes > the function destroy-thread. Which is deprecated, like the Jav

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

On Apr 27, 3:20 am, a...@pythoncraft.com (Aahz) wrote: > In article > <793a5176-ec2d-4ffd-b1e7-762077733...@v35g2000pro.googlegroups.com>, > > Vsevolod wrote: > >On Apr 26, 6:28 pm, a...@pythoncraft.com (Aahz) wrote: > > >> The problem is that thread-killing (in the literal sense) doesn't work.

Re: Lisp mentality vs. Python mentality

On Mon, Apr 27, 2009 at 2:14 AM, Dan Sommers wrote: > On Sun, 26 Apr 2009 12:30:40 +0300, Ciprian Dorin, Craciun wrote: > >> On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis" >> wrote: > >>> No, the problem is that you are using way too many functions, that do >>> too little. The problem with t

Re: Lisp mentality vs. Python mentality

On Apr 26, 3:03 pm, Paul Rubin wrote: > Carl Banks writes: > > Which is "communicating with the rest of the program periodically". > > > Presumably you have to protect objects to share them?  There you go: > > anytime you try to acquire a lock have the thread check t

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

In article <793a5176-ec2d-4ffd-b1e7-762077733...@v35g2000pro.googlegroups.com>, Vsevolod wrote: >On Apr 26, 6:28 pm, a...@pythoncraft.com (Aahz) wrote: >> >> The problem is that thread-killing (in the literal sense) doesn't work. >> Unlike processes, there's no thread-environment encapsulation at

Re: Lisp mentality vs. Python mentality

On Sun, 26 Apr 2009 05:07:25 -0700, bearophileHUGS wrote: > Paul Rubin: >> Arnaud Delobelle: >> > Do you mean imap(comp, a, b)? >> >> Oh yes, I forgot you can do that.  Thanks. > > That works and is nice and readable: > > > import operator > from itertools import imap > > def equal_sequences(a

Re: Lisp mentality vs. Python mentality

On Sun, 26 Apr 2009 12:30:40 +0300, Ciprian Dorin, Craciun wrote: > On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis" > wrote: >> No, the problem is that you are using way too many functions, that do >> too little. The problem with that is then that you have to give names >> to all the functio

Re: Lisp mentality vs. Python mentality

Scott David Daniels writes: > But precisely because of that sharing the thread may be in the middle > something that "must complete" -- no with-statement locking will get > unlocked, no "finally:" clauses in code in the standard library, no > ... -- there is just too much that goes wrong when a th

Re: Lisp mentality vs. Python mentality

Carl Banks writes: > Which is "communicating with the rest of the program periodically". > > Presumably you have to protect objects to share them? There you go: > anytime you try to acquire a lock have the thread check to see whether > to abort. Normally, acquiring a lock doesn't require runnin

Re: Lisp mentality vs. Python mentality

Paul Rubin wrote: Carl Banks writes: Say you are running a thread and you want the power to be able to kill it at any time. The thread is either communicating with the rest of the program periodically, or it isn't. If it is, then there are ample opportunities to tell the thread to terminate i

Re: Lisp mentality vs. Python mentality

Carl Banks writes: > Say you are running a thread and you want the power to be able to kill > it at any time. The thread is either communicating with the rest of > the program periodically, or it isn't. If it is, then there are ample > opportunities to tell the thread to terminate itself. If it

Re: Lisp mentality vs. Python mentality

On Apr 26, 2:38 pm, Paul Rubin wrote: > Carl Banks writes: > > Say you are running a thread and you want the power to be able to kill > > it at any time.  The thread is either communicating with the rest of > > the program periodically, or it isn't.  If it is, then t

Re: Lisp mentality vs. Python mentality

On Apr 26, 5:40 am, Vsevolod wrote: > On Apr 25, 9:06 am, Carl Banks wrote: > > Carl Banks, who might be exaggerating > > > ...a little. > > I think you're exaggerating. Go ask this question in c.l.l and the > first answer you'll get is mismatch. What could have made you think I was exaggerating

Re: Lisp mentality vs. Python mentality

In article , Scott David Daniels wrote: > >I don't remember who, but something famously said, in effect: > Debugging is hard, maybe twice as hard as writing the code in > the first place. Unless you are one of those nonexistent few > who always write correct programs from the word go

Re: Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

On Apr 26, 6:28 pm, a...@pythoncraft.com (Aahz) wrote: > The problem is that thread-killing (in the literal sense) doesn't work. > Unlike processes, there's no thread-environment encapsulation at the OS > level, which means that things don't get cleaned up properly. Even Java > has mostly given up

Re: Lisp mentality vs. Python mentality

Travis wrote: I've noticed that every one of you is wrong about programming. Since I can't say it effectively, here's someone who can: http://www.youtube.com/watch?v=XHosLhPEN3k That's the answer. Hmm, perhaps it was the answer by the time that song was written? ;) cool anyway... :) -- http:/

Re: Lisp mentality vs. Python mentality

Ciprian Dorin, Craciun wrote: On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis" wrote: From your comments I understand that the only problem with my code proposal are the function names... No, the problem is that you are using way too many functions, that do too little. The problem with

Re: Lisp mentality vs. Python mentality

Paul Rubin wrote: namekuseijin writes: return (len(a) == len(b)) and not any(not comp(*t) for t in (zip(a, b))) plus the zip call enclosed in parentheses got turned into an iterator. zip in python 2.x always makes a list. You want itertools.izip. You could also use itertools.starmap.

Re: Lisp mentality vs. Python mentality

> So if I'm reading right you are saying something in the lines: > "using too many functions is bad just because it is unreadable and > non-understandable to average (could I say mediocre?) programmers"... No, this style is also unreadable to advanced programmers, in particular when you fail t

Re: Lisp mentality vs. Python mentality

On Apr 25, 9:36 am, John Yeung wrote: > > Ultimately, Lisp is first and foremost academic (Scheme especially so) > while Python is first and foremost practical.  I think Paul Graham's > essays on Lisp exemplify the Lisp mentality. > Oh, you mean Blub? http://www.paulgraham.com/avg.html ;-) --

Re: Lisp mentality vs. Python mentality

On Apr 26, 10:52 am, Scott David Daniels wrote: > Travis wrote: > > ... I've noticed that every one of you is wrong about programming. > > Since I can't say it effectively, here's someone who can: > >http://www.youtube.com/watch?v=XHosLhPEN3k > > > That's the answer. > > That is a wonderful link.

Re: Lisp mentality vs. Python mentality

Travis wrote: ... I've noticed that every one of you is wrong about programming. Since I can't say it effectively, here's someone who can: http://www.youtube.com/watch?v=XHosLhPEN3k That's the answer. That is a wonderful link. Thanks for sharing. --Scott David Daniels scott.dani...@acm.org -

Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

In article , Vsevolod wrote: > >And let's look at my recent experience with Python: I wanted to >implement a daemon process and stumbled at a simplest problem with >threading: neither Thread, nor Threading module provides thread- >killing possibility. Surely, I'm not so experienced in Python as i

Re: Lisp mentality vs. Python mentality

Peter Otten <__pete...@web.de> writes: > Arnaud Delobelle wrote: > >> def equal_items(iter1, iter2, key=lambda x: x): >>     iter1, iter2 = iter(iter1), iter(iter2) >>     for x, y in izip(iter1, iter2): >>         if key(x) != key(y): >>             return False >>     for x, y in izip_longest(it

Re: Lisp mentality vs. Python mentality

Arnaud Delobelle: > You don't want to silence TypeErrors that may arise from with key() when > x or y is not a Guard, as it could hide bugs in key(). So I would write > something like this: > > def equal_items(iter1, iter2, key=lambda x: x, _fill = object()): >     for x, y in izip_longest(iter1, i

Re: Lisp mentality vs. Python mentality

> "Ciprian Dorin, Craciun" (CDC) wrote: >CDC> About the compare (a, b, operator.lt) it does the same as a < b, >CDC> where a and b are lists of numbers. >>> a=[1, 2, 3] >>> b=[1, 2, 4] >>> compare (a, b, operator.lt) False >>> a < b True -- Piet van Oostrum URL: http://pietvanoostrum

Re: Lisp mentality vs. Python mentality

Arnaud Delobelle wrote: > def equal_items(iter1, iter2, key=lambda x: x): >     iter1, iter2 = iter(iter1), iter(iter2) >     for x, y in izip(iter1, iter2): >         if key(x) != key(y): >             return False >     for x, y in izip_longest(iter1, iter2): >         return False >     return

Re: Lisp mentality vs. Python mentality

Arnaud Delobelle writes: > Another way would be: > > def equal_items(iter1, iter2, key=lambda x: x): > iter1, iter2 = iter(iter1), iter(iter2) > for x, y in izip(iter1, iter2): > if key(x) != key(y): > return False > for x, y in izip_longest(iter1, iter2): >

Re: Lisp mentality vs. Python mentality

bearophileh...@lycos.com writes: > You can also use quite less code, but this is less efficient: > > def equal_items(iter1, iter2, key=lambda x: x): > class Guard(object): pass > try: > for x, y in izip_longest(iter1, iter2, fillvalue=Guard()): > if key(x) != key(y): >

Re: Lisp mentality vs. Python mentality

On Apr 25, 9:06 am, Carl Banks wrote: > In answering the recent question by Mark Tarver, I think I finally hit > on why Lisp programmers are the way they are (in particular, why they > are often so hostile to the "There should only be one obvious way to > do it" Zen). > > Say you put this task to

Re: Lisp mentality vs. Python mentality

You can also use quite less code, but this is less efficient: def equal_items(iter1, iter2, key=lambda x: x): class Guard(object): pass try: for x, y in izip_longest(iter1, iter2, fillvalue=Guard()): if key(x) != key(y): return False except TypeError

Re: Lisp mentality vs. Python mentality

I liked very much your implementation for the compare function, it is very short and at the same time readable: def compare(a, b, comp=operator.eq): return (len(a) == len(b)) and all(comp(*t) for t in zip(a, b)) But I have only one problem, it is suboptimal, in the sense that:

Re: Lisp mentality vs. Python mentality

Paul Rubin: > Arnaud Delobelle: > > Do you mean imap(comp, a, b)? > > Oh yes, I forgot you can do that.  Thanks. That works and is nice and readable: import operator from itertools import imap def equal_sequences(a, b, comp=operator.eq): """ a and b must have __len__ >>> equal_sequ

Re: Lisp mentality vs. Python mentality

On Apr 24, 11:06 pm, Carl Banks wrote: > In answering the recent question by Mark Tarver, I think I finally hit > on why Lisp programmers are the way they are (in particular, why they > are often so hostile to the "There should only be one obvious way to > do it" Zen). > > Say you put this task to

Re: Lisp mentality vs. Python mentality

On Sun, Apr 26, 2009 at 12:08 PM, "Martin v. Löwis" wrote: >>     From your comments I understand that the only problem with my code >> proposal are the function names... > > No, the problem is that you are using way too many functions, that do > too little. The problem with that is then that you

Re: Lisp mentality vs. Python mentality

Arnaud Delobelle writes: > > return (len(a) == len(b)) and all(imap(comp, izip(a, b))) > Do you mean imap(comp, a, b)? Oh yes, I forgot you can do that. Thanks. -- http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

> From your comments I understand that the only problem with my code > proposal are the function names... No, the problem is that you are using way too many functions, that do too little. The problem with that is then that you have to give names to all the functions, which then find people dif

Re: Lisp mentality vs. Python mentality

Paul Rubin writes: > namekuseijin writes: >> ... return (len(a) == len(b)) and not any(not comp(a,b) for (a,b) >> in (zip(a, b))) > > If I'm reading that correctly, I think I'd write it as: > > from itertools import imap, izip > return (len(a) == l

Re: Lisp mentality vs. Python mentality

namekuseijin writes: > Ciprian Dorin, Craciun wrote: >> On Sun, Apr 26, 2009 at 7:54 AM, Steven D'Aprano >> wrote: >> I liked very much your implementation for the compare function, it >> is very short and at the same time readable: >> >>> def compare(a, b, comp=operator.eq): >>> return

Re: Lisp mentality vs. Python mentality

namekuseijin writes: > return (len(a) == len(b)) and not any(not comp(*t) for t in > (zip(a, b))) > > plus the zip call enclosed in parentheses got turned into an iterator. zip in python 2.x always makes a list. You want itertools.izip. You could also use itertools.starmap. -- http://mail

Re: Lisp mentality vs. Python mentality

namekuseijin writes: > ... return (len(a) == len(b)) and not any(not comp(a,b) for (a,b) > in (zip(a, b))) If I'm reading that correctly, I think I'd write it as: from itertools import imap, izip return (len(a) == len(b)) and all(imap(comp, izip(a, b))) That is more concise and

Re: Lisp mentality vs. Python mentality

On Sun, 26 Apr 2009 08:52:30 +0300, Ciprian Dorin, Craciun wrote: > I liked very much your implementation for the compare function, it > is very short and at the same time readable: > >> def compare(a, b, comp=operator.eq): >> return (len(a) == len(b)) and all(comp(*t) for t in zip(a, b))

Re: Lisp mentality vs. Python mentality

Ciprian Dorin, Craciun wrote: On Sun, Apr 26, 2009 at 7:54 AM, Steven D'Aprano wrote: I liked very much your implementation for the compare function, it is very short and at the same time readable: def compare(a, b, comp=operator.eq): return (len(a) == len(b)) and all(comp(*t) for t in

Re: Lisp mentality vs. Python mentality

On Sun, Apr 26, 2009 at 8:11 AM, Steven D'Aprano wrote: > On Sat, 25 Apr 2009 10:30:56 +0200, Martin v. Löwis wrote: > >     Ok... Then what's pythonic? Please give a pythonic >     implementation... Use the builtin a==b, similar to (equal a b) >>> >>>     But how about extensibility?

Re: Lisp mentality vs. Python mentality

On Sun, Apr 26, 2009 at 7:54 AM, Steven D'Aprano wrote: > On Sat, 25 Apr 2009 10:50:50 +0300, Ciprian Dorin, Craciun wrote: > >> On Sat, Apr 25, 2009 at 10:43 AM,   wrote: >>> Ciprian Dorin, Craciun: Python way: - def eq (a, b) :     return a == b def compare

Re: Lisp mentality vs. Python mentality

Paul Rubin wrote: Python tries to be simple and pragmatic while not aiming for as heavy-duty applications as Common Lisp. Scheme is more of a research language that's way past its prime. If you like Scheme, you should try Haskell. Python has the motto "practicality beats purity". With Haskell,

Re: Lisp mentality vs. Python mentality

On Apr 25, 2:06 am, Carl Banks wrote: > In answering the recent question by Mark Tarver, I think I finally hit > on why Lisp programmers are the way they are (in particular, why they > are often so hostile to the "There should only be one obvious way to > do it" Zen). > > Say you put this task to

Re: Lisp mentality vs. Python mentality

On Sat, 25 Apr 2009 10:30:56 +0200, Martin v. Löwis wrote: Ok... Then what's pythonic? Please give a pythonic implementation... >>> Use the builtin a==b, similar to (equal a b) >> >> But how about extensibility? > > == is extensible. To compare two things for equality, use

Re: Lisp mentality vs. Python mentality

On Sat, 25 Apr 2009 10:50:50 +0300, Ciprian Dorin, Craciun wrote: > On Sat, Apr 25, 2009 at 10:43 AM, wrote: >> Ciprian Dorin, Craciun: >>> Python way: >>> - >>> def eq (a, b) : >>>     return a == b >>> >>> def compare (a, b, comp = eq) : >>>     if len (a) != len (b) : >>>         retu

Re: Lisp mentality vs. Python mentality

On Apr 25, 10:26 pm, Carl Banks wrote: > I totally disagree.  Scheme might be a pure language with no > compromises and impurities, but Common Lisp is certainly not. I can assure you that even Scheme is a language full of compromises and inconsistencies :-/ Michele, who is now writing a book a

Re: Lisp mentality vs. Python mentality

On Fri, 24 Apr 2009 23:06:30 -0700, Carl Banks wrote: > Lisp programmer: > > Well, there is a standard function called mismatch that does it, but I > can't recommend it. First of all, you don't know where that function's > been. Anyone and their mother could have worked on it, did they have >

Re: Lisp mentality vs. Python mentality

That was amusing, but that's not a question of Lisp vs Python programmers, just one of fun vs practicality. Mark Tarver is the implementor of Qi, a higher order Lisp of sorts. He's writing a compiler from Qi to Python and was learning Python along the way. He's having fun with it, not writin

Re: Lisp mentality vs. Python mentality

Paul Rubin wrote: Carl Banks writes: Python programmer: a == b. Next question. in lisp you'd use (equal a b) I see you walk both sides. :) -- http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

On Apr 25, 9:05 pm, Mark Wooding wrote: > Carl Banks writes: > > Graham, for his part, doesn't seem to appreciate that > > what he does is beyond hope for average people, and > > that sometimes reality requires average people to write > > programs. > > I think he understands that perfectly well.

Re: Lisp mentality vs. Python mentality

On Apr 25, 6:05 pm, Mark Wooding wrote: > Carl Banks writes: > > Graham, for his part, doesn't seem to appreciate that what he does is > > beyond hope for average people, and that sometimes reality requires > > average people to write programs. > > I think he understands that perfectly well.  But

Re: Lisp mentality vs. Python mentality

Carl Banks writes: > Graham, for his part, doesn't seem to appreciate that what he does is > beyond hope for average people, and that sometimes reality requires > average people to write programs. I think he understands that perfectly well. But I think he believes that the sorts of tools which

Re: Lisp mentality vs. Python mentality

On Sat, 25 Apr 2009 13:32:21 +0100, Ciprian Dorin, Craciun wrote: Should I update the __eq__ method (for str class) and break almost everything? Can I write now a == b? Should you instead, perhaps, write a case-insensitive string class, since seems to be what your data is asking for?

Re: Lisp mentality vs. Python mentality

On Sat, Apr 25, 2009 at 11:36 PM, Brett Hoerner wrote: > On Apr 25, 8:11 am, "Ciprian Dorin, Craciun" > wrote: >>     Well in fact I would have written it like: >> >> def validate_commandline(rexes, line) : >>     if not compare (rexes, line, re.match) : >>         if len (rexes) != len (line) :

Re: Lisp mentality vs. Python mentality

On Apr 25, 8:11 am, "Ciprian Dorin, Craciun" wrote: >     Well in fact I would have written it like: > > def validate_commandline(rexes, line) : >     if not compare (rexes, line, re.match) : >         if len (rexes) != len (line) : >             raise ValueError ("mismatch len") >         mismatc

Re: Lisp mentality vs. Python mentality

On Apr 25, 1:44 am, "Ciprian Dorin, Craciun" wrote: > On Sat, Apr 25, 2009 at 11:30 AM, "Martin v. Löwis" > wrote: > >     Ok... Then what's pythonic? Please give a pythonic implementation... > >>> Use the builtin a==b, similar to (equal a b) > > >>     But how about extensibility? > > [...

Re: Lisp mentality vs. Python mentality

On Apr 25, 12:36 am, John Yeung wrote: > On Apr 25, 2:06 am, Carl Banks wrote: > > > In answering the recent question by Mark Tarver, I think I finally hit > > on why Lisp programmers are the way they are (in particular, why they > > are often so hostile to the "There should only be one obvious w

Re: Lisp mentality vs. Python mentality

Hrvoje Niksic writes: > I guess you meant map(a, str.upper) == map(b, str.upper)? a and b are > lists of strings. Oh, sorry. Yes, either map(str.upper, a) == map(str.upper, b) or all(str.upper(x)==str.upper(y) for x,y in zip(a,b)) -- http://mail.python.org/mailman/listinfo/python-li

Re: Lisp mentality vs. Python mentality

Paul Rubin writes: > "Ciprian Dorin, Craciun" writes: >> A practical example: I have lists that contain strings, but I want >> to compare them in an case-insensitive way... Should I update the >> __eq__ method (for str class) and break almost everything? Can I w

Re: Lisp mentality vs. Python mentality

On Sat, Apr 25, 2009 at 4:01 PM, "Martin v. Löwis" wrote: >>     Indeed the example I've given is purely theoretical. But still, I >> could find a use case for such a thing: just imagine we are building a >> small shell-like application that reads one line (the commands), >> splits it by spaces an

Re: Lisp mentality vs. Python mentality

> Indeed the example I've given is purely theoretical. But still, I > could find a use case for such a thing: just imagine we are building a > small shell-like application that reads one line (the commands), > splits it by spaces and always expects to have 4 elements and that > each respects a

Re: Lisp mentality vs. Python mentality

On Sat, Apr 25, 2009 at 1:55 PM, "Martin v. Löwis" wrote: >>     A practical example: I have lists that contain strings, but I want >> to compare them in an case-insensitive way... > > I'd claim that this is still theoretical: what are these strings, and > why do you have lists of them that you wa

Re: Lisp mentality vs. Python mentality

> A practical example: I have lists that contain strings, but I want > to compare them in an case-insensitive way... I'd claim that this is still theoretical: what are these strings, and why do you have lists of them that you want to compare? Why don't you try to lower-case the strings in the

Re: Lisp mentality vs. Python mentality

"Ciprian Dorin, Craciun" writes: > P.P.S.: I'm just trying to see why is Python better than Lisp or > vice-versa... I would say they are almost the same: both usable for > day-to-day real world applications... Python tries to be simple and pragmatic while not aiming for as heavy-duty applicat

Re: Lisp mentality vs. Python mentality

"Ciprian Dorin, Craciun" writes: > A practical example: I have lists that contain strings, but I want > to compare them in an case-insensitive way... Should I update the > __eq__ method (for str class) and break almost everything? Can I write > now a == b? Nop... I need the loop you've just me

Re: Lisp mentality vs. Python mentality

"Ciprian Dorin, Craciun" writes: > > Use the builtin a==b, similar to (equal a b) > But how about extensibility? "a==b" is like (equal a b). "a is b" is like (eq a b). -- http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

On Sat, Apr 25, 2009 at 11:36 AM, "Martin v. Löwis" wrote: >> I don't get that impression from Lisp programmers. > > I observe a phenomenon on language fanatics, no matter what language, > but in particular for the less-than-mainstream language: the desire > to formulate trivial algorithms over an

Re: Lisp mentality vs. Python mentality

Ciprian Dorin, Craciun napisał(a): > Python way: > def compare (a, b, comp = eq) : > if len (a) != len (b) : > return False > for i in xrange (len (a)) : > if not comp (a[i], b[i]) : >return False > return True This is shorter, but I'm not sure if more pythonic: def compare(a, b, compfun

Re: Lisp mentality vs. Python mentality

On Sat, Apr 25, 2009 at 11:30 AM, "Martin v. Löwis" wrote:     Ok... Then what's pythonic? Please give a pythonic implementation... >>> Use the builtin a==b, similar to (equal a b) >> >>     But how about extensibility? > [...] > > I see that you allow for a different comparison function. I d

Re: Lisp mentality vs. Python mentality

> I don't get that impression from Lisp programmers. I observe a phenomenon on language fanatics, no matter what language, but in particular for the less-than-mainstream language: the desire to formulate trivial algorithms over and over again, just to enjoy the beauty of the result (and sometimes

Re: Lisp mentality vs. Python mentality

"Ciprian Dorin, Craciun" writes: > On Sat, Apr 25, 2009 at 11:04 AM, Paul Rubin > wrote: > > Use the builtin a==b, similar to (equal a b) > > But how about extensibility? Easily extensible. If you want types that compare in different ways, just define your new

Re: Lisp mentality vs. Python mentality

Carl Banks writes: > In answering the recent question by Mark Tarver, I think I finally hit > on why Lisp programmers are the way they are (in particular, why they > are often so hostile to the "There should only be one obvious way to > do it" Zen). That's not what the Zen says. The statement yo

Re: Lisp mentality vs. Python mentality

>>> Ok... Then what's pythonic? Please give a pythonic implementation... >> Use the builtin a==b, similar to (equal a b) > > But how about extensibility? == is extensible. To compare two things for equality, use ==. This is what Carl Banks referred in his original posting. You just *don'

Re: Lisp mentality vs. Python mentality

On Sat, Apr 25, 2009 at 11:04 AM, Paul Rubin wrote: > "Ciprian Dorin, Craciun" writes: >>     Ok... Then what's pythonic? Please give a pythonic implementation... > > Use the builtin a==b, similar to (equal a b) But how about extensibility? -- http://mail.python

Re: Lisp mentality vs. Python mentality

"Ciprian Dorin, Craciun" writes: > Ok... Then what's pythonic? Please give a pythonic implementation... Use the builtin a==b, similar to (equal a b) -- http://mail.python.org/mailman/listinfo/python-list

Re: Lisp mentality vs. Python mentality

Carl Banks writes: > Python programmer: > > a == b. Next question. in lisp you'd use (equal a b) -- http://mail.python.org/mailman/listinfo/python-list

  1   2   >