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 a Lisp and a Python programmer: Come up with > a good, generic, reusable way to compare two lists. What are their > respective trains of thought? > > 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 good, sound programming practice in mind when they wrote > it? Of course not. Let's be real here, we have to implement this by > hand. > > (defun lists-are-equal (a b) >(or (and (not a) (not b)) >(and (= (car a) (car b)) (lists-are-equal (cdr a) (cdr b > > There, much better than the standard function, and better yet, it's in > the *absolute minimal form possible*. There is no way to express list > comparison in a more reduced form. It's almost erotic how awesome it > is. I'm---whoa, ok, I'm getting a little excited now, settle down. > Well, come to think of it, that's really not that good. First of all > it's a function. I mean, it just sits there and does nothing till you > call it. How boring is that? It can't react to the current > situation. Plus it compares all lists the same way, and that is > really inefficient. Every list compare is a new problem. Different > lists need different comparative strategies. This function simply > won't do. I need a macro that can intelligently compile the right > list compare methodology in. For instance, if we want to compare two > lists that are known at compile time, we don't want to waste time > comparing them at runtime. No, the macro must detect constant > arguments and special case them. Good start. Now, we have to > consider the conditions this comparison is being done under. If the > user is passing the result of a sort to this macro, it's almost > certain that they are trying to see whether the lists have the same > elements. We can do that a lot more efficiently with a countset. So > let's have the macro check to see if the forms passed to it are all > sort calls. Better yet, let's check for my own powerful sort macro. > Hmm. Wait... I think my 4600-line sort macro already checks its > calling context to see if its results are being fed to a list > comparison. I'll have to refactor that together with this macro. Ok, > good, now I am sure other users will eventually want to customize list > comparison for their own use, after all every list comparison is > different and I can't possibly anticipate all of them. A user needs > to be able to adapt to the situation, so it's vitally important to > create a plug-in infrastructure to give them that flexibility. Now, > what about exceptions, there's a millions ways to deal with that... > > ...and so on until eyelids can no longer stay open > > Python programmer: > > a == b. Next question. > > 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. But, from the other point of view your exaggeration makes sense: Lisp unlike Python, IMO, is the language, where it's pleasant to program not only applications, but the internals as well. So some people may find interest in reprogramming what's already there. In lisp programmer's mentality it's good to know, that you have that ability. 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 in Lisp (in which I'd definitely be able to solve this problem by extending the library), but I don't see an obvious solution, which will stay inside the language: I have to either use the shell or stick to the limited set of provided options and skew my program design to work with them. Any other suggestions? P.S. Btw the other issue with CL's mismatch is that it provides a possibility to use any test and keyword extraction function. Best regards, Vsevolod Dyomkin -- http://mail.python.org/mailman/listinfo/python-list
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 on thread-killing. The only way to kill threads > safely is to have them terminate themselves. Your other option is to use > multiple processes. Well, somehow, in Lisp it's not a problem. :) Cheers, Vsevolod -- http://mail.python.org/mailman/listinfo/python-list
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. > >> 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 on thread-killing. The only way to kill threads > >> safely is to have them terminate themselves. Your other option is to use > >> multiple processes. > > >Well, somehow, in Lisp it's not a problem. :) > > Does Lisp even have OS-level threads? What Lisp are you using, on what > OS? Are they perhaps Erlang-style cooperative threads instead? > -- > Aahz (a...@pythoncraft.com) <*>http://www.pythoncraft.com/ > > "If you think it's expensive to hire a professional to do the job, wait > until you hire an amateur." --Red Adair Different Lisp implementations provide different solutions. SBCL provides OS-level threads (on Linux), which I personally use, while CMUCL offers green threads. Allegro, LispWorks, Clozure CL, Sceineer CL and ECL as well have threading, but I don't use them, so won't speak, which implementation of threading they have. There's a common unification library -- bordeaux-threads -- that abstracts away implementation specifics. It's API includes the function destroy- thread. 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 language). As of PEP-20: "There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch." And if someone disagrees -- he just doesn't understand... Cheers, Vsevolod -- http://mail.python.org/mailman/listinfo/python-list
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 function destroy-thread. > > Which is deprecated, like the Java one. It's not hard to provide > a kill thread call, if you don't mind it having undefined semantics. "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 causing it to run sb-ext:quit - the usual cleanup forms will be evaluated". And it works fine. Best regards, Vsevolod -- http://mail.python.org/mailman/listinfo/python-list
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 relevance. OK, I'm not a big expert in Python. That was just the thing, that was important to me recently. I won't claim, that it's regularly a problem with Python, although from reading Guido's blog I get that impression. (Well, I understand, that's how BDFLs should behave :) 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. Best regards, Vsevolod -- http://mail.python.org/mailman/listinfo/python-list
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. Even of stupid jokes. ;) > 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 proficiency with the language. I believe most of my technical problems are connected with lack of knowledge or experience, not the language's features. While conceptual problems seem futile to discuss. There's another saying: "when in Rome do as the Romans do" Best regards, Vsevolod -- http://mail.python.org/mailman/listinfo/python-list
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 on many POSIX-ish > environments, internally generating a SIGALRM to interrupt a system > operation might work, but it would likely have portability problems. We're arguing to the old argument, who knows better, what the programmer wants: language implementor or the programmer himself. AFAIK, Python community is on former side, while Lisp one -- on the later. As always, there's no right answer. Best regards, Vsevolod -- http://mail.python.org/mailman/listinfo/python-list
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 gain control again in order to > >> execute the specified function? I guess on many POSIX-ish > >> environments, internally generating a SIGALRM to interrupt a system > >> operation might work, but it would likely have portability problems. > > > We're arguing to the old argument, who knows better, what the > > programmer wants: language implementor or the programmer himself. > > AFAIK, Python community is on former side, while Lisp one -- on the > > later. As always, there's no right answer. > > Note I wasn't trying to argue anything, I was actually interested in > how the behavior is handled in Lisp? Do you know how the Lisp > implementation of threads you spoke about handles this case? > > E.g., can the Lisp implementation you are familiar with actually kill > such a thread blocked on an arbitrary external system or library call? > > -- David The behavior up to some detail is described here: http://www.sbcl.org/manual/Threading.html Overall, if this issue comes up important, it is possible to either get the more detailed explanation from the developers, poke in the source code or implement the needed behavior yourself. Basically, you can't know the precise semantics and corner cases of all the language and implementation constructs you use (especially, when speaking about libraries, which threading definitely is both in lisp and python). Moreover, in this case thread-killing semantics is largely defined by the underlying system (if we are talking about native threads), and those systems (like Unix) somehow happen to function :), or can be defined arbitrarily, if we consider green threads. So the answer, that it can be only poorly specified, IMO, is just an indulgence from implementing the operation. Best regards, Vsevolod -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about PyPI and 'easy_install'
On Feb 24, 10:38 pm, makoto kuwata <[EMAIL PROTECTED]> wrote: > Hi, > > I have a trouble around PyPI and easy_install. > > I have developed OSS (Tenjin) and registered it to > PyPI.http://pypi.python.org/pypi/Tenjin/0.6.1 > > But I can't install it by 'easy_install' command. > Hi! I`m think this patch is helpful for you ---BEGIN PATCH--- --- setup.py.orig 2007-10-23 03:54:18.0 +0400 +++ setup.py2008-02-26 14:08:44.66000 +0300 @@ -6,12 +6,10 @@ import sys, re -if len(sys.argv) > 1 and sys.argv[1] == 'egg_info': -from ez_setup import use_setuptools -use_setuptools() -from distutils.core import setup +from ez_setup import use_setuptools +from setuptools import setup -name = 'pyTenjin' +name = 'Tenjin' version = '0.6.1' author = 'makoto kuwata' email= '[EMAIL PROTECTED]' ---END PATCH--- PS Thank you for excellent job. -- Vsevolod Balashov http://vsevolod.balashov.name -- http://mail.python.org/mailman/listinfo/python-list
