🌐 Mailman 3 December 2000 - Python-list - python.org

Re: Python vs. PHP (& Java?)
by rturpin＠my-deja.com Jan. 4, 2001

Jan. 4, 2001

"Kemp Randy-W18971" <Randy.L.Kemp(a)motorola.com> writes: >> Can we nip language comparisons in the bud? In comp.lang.*? I doubt it. In article <mailman.978018791.20357.python-list(a)python.org>, "Alex Martelli" <aleaxit(a)yahoo.com> wrote: > In each case, there are some _facts_ that can be pointed > out, .. Yep. And some of these facts point to the danger of reasoning from natural to programming languages. People use natural language for human communication. And in almost all practical contexts, small competencies bring signficant benefit. If you can ask where the bathroom is in Japanese, the waiter, recognizing your deficiency in that tongue, but pleased that you made the attempt, will point the way. This keeps you from having to translate the Japanese equivalent of "behind the screen with the crouching tiger." Which is good, because your back teeth are afloat, and the only part your limited Japanese knows is "behind." In contrast, texts in computer languages are more studied as artifacts. "How did this work?" "Why did it stop working?" "What did the original authors intend?" They, the rascals, are no longer around to explain, take credit, or defend their honor. This kind of comprehension requires a high level of competency in the language. Knowing one-tenth of Perl is not enough to understand most Perl scripts. Computer languages have more precisely defined semantics than natural languages. The niggling details are important, such as what "[[0]*10]*3" means. Natural languages are more fluid, and it is the nuances of the tacit, multiple meaning, and almost ambiguous that are important in their competence. For these reasons, I am a great believer in small computer languages, ones that can be explained well in a book no thicker than my pinkie. The use of extentions should be recognizable, so that when you come across something you don't know, you know *what* to look up and where to find it. "One way to do everything" IS better than "many ways to do anything." Of course, being small has its hazards, if core features are omitted. That's why I am fond of saying that a language's productivity is proportional to its expressive power, and inversely proportional to its complexity. (Not that these are the only considerations.) That is why I am happy to see Guido resist the temptation to continually add new bells and whistles. People tend to focus on the benefit of expressive power, while overlooking the problem of complexity. C, Lisp, and Python are examples of languages that pack a lot of expressive power into simple packages with a small set of orthogonal concepts. C++, trying to build OO on top of C while retaining maximal compile time efficiency, grew bigger than its expressive power requires. But that set of goals is hard to achieve, and to its credit, C++ does this. Perl is overly complex for what it does. I think this was due to its syncretic history, rather than the scope of what it achieves. Like Alex, I can't imagine any task that, from a pure language viewpoint, is better done in Perl than in Python. Practical constraints, such as a company's preferred language, or which language someone already knows, could determine otherwise. Russell Sent via Deja.com http://www.deja.com/

3 6

Re: SMB Module
by Armin Steinhoff Jan. 4, 2001

Jan. 4, 2001

In article <slrn94trot.b73.mballen(a)angus.foo.net>, mballen(a)erols.com says... > >I frequent the Samba mailing list. A couple of days ago Richard Sharp >put together an smbclient.so library of client functions for SMB. SMB >is Microsoft's native file and print sharing protocol. Someone wrote a >Perl module using it. I just thought one of you guys might want to do the >same for Python. Seems only natrual since there's a nice little library >all packaged up with open(), read(), write(), ...etc all setup easy like. Makes no sense, because a SMB client mapps normaly a M$ volume to a directory tree (UNIX) or a virtual drive (M$) ... I don't see in that case any tasks for Python. Armin Python in real-time: http://sourceforge.net/projects/pyqnx

6 11

8.3 peculiarity if run w/i console
by Franz GEIGER Jan. 3, 2001

Jan. 3, 2001

If I run a script within the Python 2.0 console, the names of the files that are made by that script are all "abbreviated", e.g.: ALongFileName.txt becomes ALongF~1.TXT. If I run the script within PythonWin, the names are o.k. Does anybody know what's going on here? FYI: ActiveState Python2.0/202 on WinNT 4.0 Svr. Thanks in advance and Best regards Franz GEIGER

3 4

turtle.py bugfix & questions
by kragen＠dnaco.net Jan. 3, 2001

Jan. 3, 2001

turtle.py, which I believe is in the standard distribution (at least of PythonWin) has a minor bug: when tracing is turned on, lines shorter than a pixel don't get drawn at all. If you're building long curves made of such lines, this is a bad thing. Here's a unidiff patch I think fixes the problem. --- turtle.py Sat Dec 30 14:24:17 2000 +++ nturtle.py Sat Dec 30 14:26:09 2000 @@ -221,6 +221,8 @@ self._canvas.coords(item, x0, y0, x, y) self._canvas.update() self._canvas.after(10) + # in case nhops==0 + self._canvas.coords(item, x0, y0, x1, y1) self._canvas.itemconfigure(item, arrow="none") except Tk.TclError: # Probably the window was closed! The range controlling the loop above is range(1, 1+nhops) instead of range(1, nhops); presumably, if it were range(1, nhops), then the last pixel's worth of drawing would be left off the line. This should now be unnecessary, as the coords() call after the loop should take care of that. Larger questions I have: is anyone using turtle.py? http://www.python.org/1.5/NEWS-152.txt says: - turtle.py is a new module for simple turtle graphics. I'm still working on it; let me know if you use this to teach Python to children or other novices without prior programming experience. But it's not mentioned anywhere else I can find --- not even under "Undocumented modules" in the library reference. Perhaps, if nobody is using it, there is no documentation, and it's buggy (although it looks pretty stable in the hour or so I played with it, I did find this one bug), we should remove it from the standard distribution. (I found it while looking for examples of the usage of Tkinter.Canvas, because there is no documentation for Tkinter in PythonWin --- not even the Tcl man pages, as far as I can tell.) -- <kragen(a)pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> Perilous to all of us are the devices of an art deeper than we possess ourselves. -- Gandalf the White [J.R.R. Tolkien, "The Two Towers", Bk 3, Ch. XI]

2 1

Komodo
by Robert L Hicks Jan. 3, 2001

Jan. 3, 2001

Has anyone tried Komodo from ActiveState yet? What are you thoughts on it? I see that a Linux beta is out now as well. Will Komodo for Linux have to have the ActiveState versions of Perl and Python to work? Bob

6 10

Newbie question ... reading modules from directories in Windows
by Peder Jakobsen Jan. 2, 2001

Jan. 2, 2001

Just a small question: I have added a "C:\Python20\sandbox" directory to my PYTHONPATH Now I'm trying to import modules from that directory whole using the interactive Python prompt, but it only works if I start python.exe in the directory where the module resides. I thought by adding the directory where the .py files exist to the Path, Python would be able to detect them??? Thanks in advance, Peder Jakobsen, Ottawa

3 2

how do i check if a file exists with python?
by Scott Hathaway Jan. 2, 2001

Jan. 2, 2001

I have searched Deja, looked in two pyton books, and searched the python.org site trying to find out this simple question. Can someone please give me the call and the module it lives in? Thanks, Scott

7 9

Q: Is there any good documentation on MAPI using Python
by Henrik M�rtensson Jan. 2, 2001

Jan. 2, 2001

Hi I would like to use the MAPI with the MS office suite programming in Python, but I'm having a little bit of a problem with finding good documentation. Does anybody have any leads? /Henrik

3 3

Casting and module "array"
by Edward C. Jones Jan. 2, 2001

Jan. 2, 2001

Is there a better way to cast arrays made from module "array"? Turning a large array into a list would seem to be slow. import array def cast(typecode, arr): return array.array(typecode, list(arr)) if __name__ == '__main__': Barr = array.array('B', [0, 1, 254, 255]) harr = cast('h', Barr) print list(harr) barr = cast('b', Barr) # Fails. I would use "astype" from Numeric (aka NumPy) instead but NumPy doesn't support unsigned short or unsigned long. Thanks, Ed Jones

2 1

Erlang (was Re: Good introduction to functional programming with Python?)
by Alex Martelli Jan. 2, 2001

Jan. 2, 2001

"Tim Peters" <tim.one(a)home.com> wrote in message news:mailman.977984412.30211.python-list@python.org... [snip] > I haven't used Erlang at all, so that makes it an excellent battlefield: no > unpleasant haggling over facts <wink>. I'll hazard a guess based on the Right! > In the absence of higher-order functions, I can believe programmers don't > have much trouble reasoning about types without declarations. They don't The _scarcity_ (not _absence_:-) of HOF in typical Erlang use may be a cultural issue (or maybe they just don't buy one all that much in its typical use cases); and from that may follow the relative lack of interest in its (existing, but 'add-on') type-inferencing possibilities. It's not hard to find examples of Erlang HOF's on the web though -- right on http://www.erlang.org/white_paper.html we get a typically simple one: """ As another an example we can write: > Adder = fun(N) -> fun(X) -> X + N end end. #Fun > G = Adder(10). #Fun > G(5). 15 """ No big fuss, and the explicit "fun(...) -> Expr end" syntax with which, it says, "function objects are introduced"... it *does* read better than 'lambda', methinks, but this is just a sugary issue, of course. Part of the 'cultural' explanation may be that not a little 'typical FP stuff' was added relatively recently to Erlang, so it's not in the book; http://www.erlang.org/doc/r7b/pdf/extensions-5.0.1.pdf summarizes the additions, though, including 'Funs'. As this doc says, """ Higher Order Functions Funs encourages us to encapsulate common patterns of design into functional forms called higher order functions. These functions not only shortens programs, but also produce clearer programs because the intended meaning of the program is explicitly rather than implicitly stated. """ and I suspect that the emphasis on 'explicitly rather than implicitly stated' may charm you enough to convince you to go easy on the author's obvious difficulty with s-endings in English verb forms with plural subjects:-). The typical example of HOF in this doc is: """ map(F, [H|T]) -> [F(H)|map(F, T)]; map(F, []) -> []. We can now express the functions double and add_one in terms of map as follows: double(L) -> map(fun(X) -> 2*X end, L). add_one(L) -> map(fun(X) -> 1 + X end, L). """ Actually, of course, 'map', along with several other typical HOF's, is exported from a 'lists' module. List comprehensions (aka 'Zermelo-Frankel', aka ZF, ones:-) are also introduced in the same docs, with rather Haskellish syntax if I may say so: > [X || X <- [1,2,a,3,4,b,5,6], integer(X), X > 3]. [4,5,6] Here, 'explicit is better than implicit' seems to have been slightly put aside -- each qualifier is either a generator, if it includes a '<-', or else a filter; Python's choice of expressing this as: >>> [X for X in [1,2,'a',3,4,'b',5,6] if type(X)==type(0) if X > 3] [4,5,6] looks more explicit to me (not necessarily more readable:-). > use the static type checker because it's more trouble than it's worth! Because the HOF's, while present, are not widely used? Maybe. > Fine by me. I must say, though, that Erlang appears to occupy an extreme > corner of the FP universe. It sure looks unique to me for its emphasis on concurrency (if there are other FP's that are similarly concurrency-oriented, I have not seen them yet). But Scheme (albeit impure) and Erlang (albeit 'culturally not highly HOF-prone') together surely make up for a substantial share of functional-programming use, and just as surely form a solid case for static-typing NOT being central to FP (just as, say, Smalltalk and Python together form a solid case for static-typing not being central to OO, no matter how much Eiffel'ers may rant otherwise:-). > I *like* the attitude of the Erlang developers. Looks like a very useful > language for its target domain. Even better, according to FAQ 5.7.11 > there's a Python binding (if you really need some higher-order functions > after all <wink>). It looks to me as if the Python/Erlang interface is based on an older (perhaps now-removed) external-functions layer of Erlang, and was only release at a '0.1' level. Still, Erlang's current external-functions approaches, http://www.erlang.org/doc/current/doc/tutorial/part_frame.html, appear to offer ample scope for such interfacing -- there's a mention of an IDL compiler, which, as usual, sounds more interesting to me than 'point-to-point' approaches to interlanguage-operation (even when one of the languages is Python!-). The barely-mentioned 'IC' IDL compiler seems to be part of OTP, the Open Telecom Platform framework for Erlang, so I'm not going to dig into this further at this time (as I don't do telecom programming:-), but, conceptually, it makes sense...!-) Alex > > if-we-don't-act-fast-i'm-afraid-python-may-lose-the-industrial- > control-market-ly y'rs - tim > >

9 12