Re: Is Python really a scripting language?
On Dec 14, 3:15 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Dec 14, 2:48 pm, Chris Mellon [EMAIL PROTECTED] wrote: On Dec 14, 2007 2:09 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Dec 11, 10:34 pm, Terry Reedy [EMAIL PROTECTED] wrote: Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. When you buy a new car, which is more important, the styling or what's under the hood? snip That's for the whole sequence, not a single term! 25.67 MINUTES compared to 17.65 HOURS! So, sure, some languages compile to .exe programs. In the trade, we call that polishing a turd. While I agree with the sentiment, surely this can't be a good example of F#s general performance? Of course. They example was deliberately chosen to make F#'s BigInt library look as bad as possible. I would expect .NET code to smoke stock (non-Psycoed) Python in this benchmark. Probably. It just so happens that the example chosen is typical of _my_ number theory research and I was toying with the idea of converting my Collatz Conjecture function library to F#. And that would take a lot of work since F# doesn't have anywhere near the functionality of gmpy. There isn't even a BigInt.mod function for cryin' out loud, let alone stuff like GCD or modular inverse, critical to my research. Sure, I could write my own Extended Euclidean Algorithm, but now that I now that F# is just a Volkswagen with a fiberglass shell that looks like a Ferrari, there isn't much point, eh? And don't even get me started about the stupid stuff, like having TWO different type of Big Rationals. One's more efficient than the other, they say. So why two? The less efficient one has functions not implemented in the other. And F# is strongly typed, so you can't use BigRational methods with BigNum types. And they have all sorts of conversion methods for to/from ints, strings, bigints, etc. Guess which conversions they don't have? BigRational - BigNum, of course. MAybe I'll check it out again in the future after it has gone through several revisions. Since F# is a caml derivative, you may want to look at OCaml. Though, I've never used OCaml for any kind of heavy number-crunching, so maybe it has even worse library support; can't say. Ps. The two types are probably for boxed and unboxed versions, q.v. this article, about half- way down: http://msdn.microsoft.com/msdnmag/issues/1200/dotnet/ Regards, Jordan -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Sat, 15 Dec 2007 01:59:16 +, Steven D'Aprano wrote: In any case, I would say that your exercise is the Wrong Way to go about it. A task as simple as produce PDF output from this file shouldn't need access to the internals of the OpenOffice GUI application. The Right Way (in some Ideal World where OO wasn't so stupid) would be some variation of: oowriter --print some.doc | ps2pdf Can be done this way… :: soffice -invisible macro:///Standard.MyConversions.SaveAsPDF(some.doc) …if you write a small macro in StarBasic for the conversion. Full story: http://www.xml.com/pub/a/2006/01/11/from-microsoft-to-openoffice.html Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Steven D'Aprano [EMAIL PROTECTED] (SD) wrote: SD I have repeatedly argued in the past that we do ourselves a disservice by SD describing Python as an interpreted language. Python is compiled. It has SD a compiler. It even has a built-in function compile. It's just not SD compiled to *machine code* -- but with even machine code often running on SD a virtual machine in the CPU(s), the distinction is far less important SD now than it was when Sun described Java as a compiled language despite SD the lack of JIT compilers. The above is not a description of the language but of an implementation. Albeit the currently major implementation. But it could be that in the future python would be compiled to machine code. That wouldn't change the language. -- Piet van Oostrum [EMAIL PROTECTED] URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
John Nagle [EMAIL PROTECTED] (JN) wrote: JN There's CORBA, for example, and in theory JN you can script OpenOffice and Gnome via CORBA. But nobody does that. JN Exercise: write a Python program to convert a .doc file to a .pdf JN file by invoking OpenOffice via CORBA. At least in theory, this is JN possible. All the necessary parts supposedly exist. Somebody JN tried back in 2003, but gave up. See JN http://mail.python.org/pipermail/python-list/2003-April/198094.html; [Nitpicking] Scripting Openoffice.org (!) is with UNO, not Corba. -- Piet van Oostrum [EMAIL PROTECTED] URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
John Nagle wrote: Yes. One of the basic design flaws of UNIX was that interprocess communication was originally almost nonexistent, and it's still not all that great. It's easy to run other programs, and easy to send command line parameters, but all you get back is a status code, plus console-type output. The UNIX world might have been quite different if, when you ran a subprocess, at the end you got return values for the command line parameters (argv/argc) and the environment back. Then programs would behave more like big subroutines. But all you get back is a status code, so running programs from a script tends to be a somewhat blind one-way process. not if you use pickle. the example below is not complete and I need to fix it to not raise privileges if name is None but it is complete enough to give you an idea. the parent uses spawn_sub to send data to/from child. child uses read_input/write_output to move data from/to the parent. I should convert it to something like json to make it possible to work with other languages. class process_handler (object): def read_input (self): get the input from standard and can convert to Python object pickle_input = sys.stdin.read() real_object = pickle.loads(pickle_input) return real_object def write_output (self, real_object, err_object = None): errors to standard error, output to standard out, objects in pickled form pickled_error = pickle.dumps(err_object) sys.stderr.write(pickled_error) pickled_output = pickle.dumps(real_object) sys.stdout.write(pickled_output) def spawn_sub(self, cmd_list,stuff_in, run_as=None): command_list is just that, a list of the command and all of its arguments. stuff_in is the string sent to the sub process via standard in stuff_out is the string returned from the sub process via standard out error_stuff is the string returned from standard error. stuff_out and error_stuff are returned as a tuple run_as is the user name you want to run as. This uses a trick with sudo to enable privilege escalation this is an example of a bad escalation specification in sudoers. It's sometimes bad because it doesn't restrict who can use the command. If you are trying to run a program as a common but different user (such as www-data because you need to share a database with a Web server, the badness is measured in terms of what data said program can change or reveal. If the access cannot be exploited, then they should be okay. Unfortunately, in almost every circumstance where privilege escalation techniques are useful, there is an exploit waiting to happen. be careful. ALL ALL = (www-data) NOPASSWD: /home/esj/vacation_scan.py # syslog.syslog(subprocess args %s%str(cmd_list)) p = subprocess.Popen(cmd_list, shell=False, bufsize=4000, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True) # always pickle what passes through even if it is a None pickle_in = pickle.dumps(stuff_in) (pickled_output, pickled_error) = p.communicate(pickle_in) stuff_output = pickle.loads(pickled_output) error_stuff = pickle.loads(pickled_error) # syslog.syslog( stuff_output %s, error_stuff %s%( stuff_output, error_stuff)) return (stuff_output, error_stuff) -- Speech-recognition in use. It makes mistakes, I correct some. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Eric S. Johansson wrote: John Nagle wrote: Yes. One of the basic design flaws of UNIX was that interprocess communication was originally almost nonexistent, and it's still not all that great. It's easy to run other programs, and easy to send command line parameters, but all you get back is a status code, plus console-type output. The UNIX world might have been quite different if, when you ran a subprocess, at the end you got return values for the command line parameters (argv/argc) and the environment back. Then programs would behave more like big subroutines. not if you use pickle. That assumes both programs were designed to intercommunicate that way. Most UNIX applications aren't. There's no accepted standard on how UNIX programs should intercommunicate, other than the 1970s technology of piping human-readable strings around. Yes, there are marshalling systems, of which Python's Pickle is one. But there's no standard interprocess call system. And Pickle is only a marshalling system, not a full IPC system. There's no resource location system. (Where's the browser process? Where's the database back-end?) Both Gnome and OpenOffice use CORBA. But they use incompatible versions, and you have to have a CORBA ORB running for that to work. There's OpenRPC, which isn't used much any more. There's System V IPC, which isn't used much. There are XML-based systems. There's REST, JSON, and similar approaches. None of these approaches ever got the kind of widespread use that OLE did in the Microsoft world. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
John Nagle wrote: Eric S. Johansson wrote: John Nagle wrote: Yes. One of the basic design flaws of UNIX was that interprocess communication was originally almost nonexistent, and it's still not all that great. It's easy to run other programs, and easy to send command line parameters, but all you get back is a status code, plus console-type output. The UNIX world might have been quite different if, when you ran a subprocess, at the end you got return values for the command line parameters (argv/argc) and the environment back. Then programs would behave more like big subroutines. not if you use pickle. That assumes both programs were designed to intercommunicate that way. Most UNIX applications aren't. There's no accepted standard on how UNIX programs should intercommunicate, other than the 1970s technology of piping human-readable strings around. Yes, there are marshalling systems, of which Python's Pickle is one. But there's no standard interprocess call system. And Pickle is only a marshalling system, not a full IPC system. There's no resource location system. (Where's the browser process? Where's the database back-end?) I apologize if this gets you a bit cranky but I think you're conflating a few interprocess communications issues. I know I didn't fully articulate what I had been doing and I apologize. As your description above shows, there are multiple types of interprocess communications. My example shows how it's possible to make two cooperatively designed programs act as if they are communicating via a remote procedure call across a parent-child process boundary. Yes, other marshaling systems may be useful across multiple language environments. I wasn't concerned about that. I had to get a job done so I used pickle. when it comes right down to it, IPC systems are hard to do right. http://birrell.org/andrew/papers/ImplementingRPC.pdf is a pretty good reference for how to do it for our PCs. Also, the definition of right, depends on the communications medium used. For example, if the application is using pipes with sub processes, what I wrote is a workable implementation especially if you need to deal with privilege escalation. If you're talking over sockets or some equivalent communications channel, then yes, you need some form of resource location as well as handling methods exposure and resolution on both server and client side. But even if you have all of these items, you're still not out of the woods. There's a fundamental issue of reliability in the face of this complexity. I've written some code with psycho and, this is not meant as a slam against psycho, but the resource location subsystem was causing more problems than I care to deal with so I eliminated it from my project by hard coding certain essential bits of information. Both Gnome and OpenOffice use CORBA. But they use incompatible versions, and you have to have a CORBA ORB running for that to work. There's OpenRPC, which isn't used much any more. There's System V IPC, which isn't used much. There are XML-based systems. There's REST, JSON, and similar approaches. None of these approaches ever got the kind of widespread use that OLE did in the Microsoft world. All of these examples are great examples of overly complex IPC mechanisms. while the complexity may be necessary if you are going to handle 99% of all cases, the complexity makes it more difficult to document functionality in a comprehensible way. complexity reduces take up because it's too much work to figure out and use especially if it's a one-shot job. I believe it's fairly clear that a very simple IPC mechanism could handle a significant majority of project needs while making IPC functionality accessible to more developers. XML RPC almost achieves that except for its functional call orientation. But, I'm not a waste any more breath on what ifs because there's way too much technological alpha male behavior to ever build a simple common infrastructure component for IPC (or almost any other widely usable components for that matter). ---eric -- Speech-recognition in use. It makes mistakes, I correct some. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Dec 14, 2007 2:07 AM, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 10:43:18 +0100, Bruno Desthuilliers [EMAIL PROTECTED] declaimed the following in comp.lang.python: I still wait to see any clear, unambiguous definition of scripting language. Which one are you refering to here ? Strangely, once you leave the realm of shell languages (DCL, JCL, bash, etc.) I can think of only ONE language that I'd consider a true scripting language... ARexx on the Amiga, as it could address any application that created a compatible ARexx message port. This meant one could write ARexx programs that could, by changing the address, send application native commands to an application, retrieve returned data, and then send that data to a second application using its native commands. No hassle with subprocess spawning or pipe I/O blocking... Applescript works in a very similar way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Chris Mellon wrote: On Dec 14, 2007 2:07 AM, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 10:43:18 +0100, Bruno Desthuilliers [EMAIL PROTECTED] declaimed the following in comp.lang.python: I still wait to see any clear, unambiguous definition of scripting language. Which one are you refering to here ? Strangely, once you leave the realm of shell languages (DCL, JCL, bash, etc.) I can think of only ONE language that I'd consider a true scripting language... ARexx on the Amiga, as it could address any application that created a compatible ARexx message port. This meant one could write ARexx programs that could, by changing the address, send application native commands to an application, retrieve returned data, and then send that data to a second application using its native commands. No hassle with subprocess spawning or pipe I/O blocking... Applescript works in a very similar way. Yes. One of the basic design flaws of UNIX was that interprocess communication was originally almost nonexistent, and it's still not all that great. It's easy to run other programs, and easy to send command line parameters, but all you get back is a status code, plus console-type output. The UNIX world might have been quite different if, when you ran a subprocess, at the end you got return values for the command line parameters (argv/argc) and the environment back. Then programs would behave more like big subroutines. But all you get back is a status code, so running programs from a script tends to be a somewhat blind one-way process. The UNIX world now has various forms of interprocess communication, but none of them is as pervasive as Microsoft OLE and its successors on Microsoft platforms. There's CORBA, for example, and in theory you can script OpenOffice and Gnome via CORBA. But nobody does that. Exercise: write a Python program to convert a .doc file to a .pdf file by invoking OpenOffice via CORBA. At least in theory, this is possible. All the necessary parts supposedly exist. Somebody tried back in 2003, but gave up. See http://mail.python.org/pipermail/python-list/2003-April/198094.html; John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Dec 11, 10:34 pm, Terry Reedy [EMAIL PROTECTED] wrote: Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. When you buy a new car, which is more important, the styling or what's under the hood? Take, for example, Microsoft's slick new language F#. Wikipedia F# (pronounced F Sharp) is a multi-paradigm programming language, targeting the .NET Framework, that encompasses functional programming as well as imperative object-oriented programming disciplines. It is a variant of ML and is largely compatible with the OCaml implementation. /Wikipedia Sounds pretty sexy, eh? And programs compile to .exe files, none of that byte-code interpretation nonsense. But you would never buy a car without taking a test drive, right? So we can fire up the F# Interactive (Console) and put it in gear. #time;; -- Timing now on open Math;; Time 0.046875 let mutable Z = 0I;; val mutable Z : bigint Time 0.156250 Z - Z + (BigInt.pow 3I 123295I) * (BigInt.pow 2I 0I);; val it : unit = () Time 0.515625 About a half second to compute a number with 58827 decimal digits. OTOH, that was only the first of 123296 terms. The time to compute the full sequence is 0.515625*123296 seconds or 17.65 hours. If it takes that long for a compiled .exe to run, just imagine how long a lowly, byte-code interpreted language would take! But wait... ...we don't have to imagine, we can take the Python out for a test drive also. import collatz_functions import time sv = collatz_functions.build_sv(19,19,100,1541095) def Big_Z(sv): Z = 0 e2 = 0 e3 = len(sv) - 1 t0 = time.time() for v in sv: Z += 3**e3 * 2**e2 e3 -= 1 e2 += v t1 = time.time() print (t1-t0)/60,'minutes' Big_Z(sv) 25.677583 minutes Hold on... That's for the whole sequence, not a single term! 25.67 MINUTES compared to 17.65 HOURS! So, sure, some languages compile to .exe programs. In the trade, we call that polishing a turd. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Dec 14, 2007 2:09 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Dec 11, 10:34 pm, Terry Reedy [EMAIL PROTECTED] wrote: Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. When you buy a new car, which is more important, the styling or what's under the hood? snip That's for the whole sequence, not a single term! 25.67 MINUTES compared to 17.65 HOURS! So, sure, some languages compile to .exe programs. In the trade, we call that polishing a turd. While I agree with the sentiment, surely this can't be a good example of F#s general performance? I would expect .NET code to smoke stock (non-Psycoed) Python in this benchmark. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Dec 14, 2:48 pm, Chris Mellon [EMAIL PROTECTED] wrote: On Dec 14, 2007 2:09 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Dec 11, 10:34 pm, Terry Reedy [EMAIL PROTECTED] wrote: Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. When you buy a new car, which is more important, the styling or what's under the hood? snip That's for the whole sequence, not a single term! 25.67 MINUTES compared to 17.65 HOURS! So, sure, some languages compile to .exe programs. In the trade, we call that polishing a turd. While I agree with the sentiment, surely this can't be a good example of F#s general performance? Of course. They example was deliberately chosen to make F#'s BigInt library look as bad as possible. I would expect .NET code to smoke stock (non-Psycoed) Python in this benchmark. Probably. It just so happens that the example chosen is typical of _my_ number theory research and I was toying with the idea of converting my Collatz Conjecture function library to F#. And that would take a lot of work since F# doesn't have anywhere near the functionality of gmpy. There isn't even a BigInt.mod function for cryin' out loud, let alone stuff like GCD or modular inverse, critical to my research. Sure, I could write my own Extended Euclidean Algorithm, but now that I now that F# is just a Volkswagen with a fiberglass shell that looks like a Ferrari, there isn't much point, eh? And don't even get me started about the stupid stuff, like having TWO different type of Big Rationals. One's more efficient than the other, they say. So why two? The less efficient one has functions not implemented in the other. And F# is strongly typed, so you can't use BigRational methods with BigNum types. And they have all sorts of conversion methods for to/from ints, strings, bigints, etc. Guess which conversions they don't have? BigRational - BigNum, of course. MAybe I'll check it out again in the future after it has gone through several revisions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Terry Reedy wrote: Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. One of the nicest thing of python is that when coworkers say that,we prefer (java |.net). I can always say, oh no problem there is a python interpreter for that. Python can be used as a scripting language, yes, also OO wise or procedural and whatever more. So for me it is quite logical to use a language that gives me the advantage to go from quick and dirty to full fledged unit tested programming in whatever programming paradigm is hot these days. Python might still lack a bit on the GUI side, but I believe this is not a problem of python but mere to the interpretation of GUI. GUI is still an art in it's early stage. Python is in my view a liberal programming language, it has power, simplicity while containing flexibility and it doesn't preach whatever programming paradigm. So yes Python can shoot you in the foot in ways you could never imagined before, but remember it is you who held the barrel that way, and remind yourself, with other languages you probably weren't able to build the gun anyway. So which of these is better is your choice. -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Fri, 14 Dec 2007 10:26:54 -0800, John Nagle wrote: Yes. One of the basic design flaws of UNIX was that interprocess communication was originally almost nonexistent, and it's still not all that great. It's easy to run other programs, and easy to send command line parameters, but all you get back is a status code, plus console-type output. The UNIX world might have been quite different if, when you ran a subprocess, at the end you got return values for the command line parameters (argv/argc) and the environment back. Then programs would behave more like big subroutines. But all you get back is a status code, so running programs from a script tends to be a somewhat blind one-way process. I'm not entirely convinced that's a flaw. True, it makes certain things more difficult, but in my opinion it has one *major* advantage that outweighs that a thousand times: it encourages developers to build small programs that do one thing well, rather than huge everything-including- the-kitchen-sink monstrosities. When you're limited to a status code plus stdout, the tendency is write simple programs that behave more or less like a function: do one thing with the minimum number of options, using (conceptually) a single entry point and a single exit point. Because it is hard to expose the internal workings of your program, encapsulation follows naturally. When you have rich inter-application communication, there is (it seems to me) a tendency to write programs that behave more or less like BASIC with goto: you can jump in to and out of them anywhere. Because it is easier to expose the internal workings of your program, encapsulation is harder. (Naturally all of the above are generalizations. One can write monstrous Unix programs too, and I need give no examples as they are so well known.) The UNIX world now has various forms of interprocess communication, but none of them is as pervasive as Microsoft OLE and its successors on Microsoft platforms. There's CORBA, for example, and in theory you can script OpenOffice and Gnome via CORBA. But nobody does that. Exercise: write a Python program to convert a .doc file to a .pdf file by invoking OpenOffice via CORBA. At least in theory, this is possible. All the necessary parts supposedly exist. Somebody tried back in 2003, but gave up. See http://mail.python.org/pipermail/python-list/2003-April/198094.html; That thread contains two posts. There's no indication that the person gave up, or if he did, why he gave up. In any case, I would say that your exercise is the Wrong Way to go about it. A task as simple as produce PDF output from this file shouldn't need access to the internals of the OpenOffice GUI application. The Right Way (in some Ideal World where OO wasn't so stupid) would be some variation of: oowriter --print some.doc | ps2pdf That is, tell OO to render the document into Postfix, which is then sent to another program to convert it into a PDF. Even for more complicated tasks, the Right Way is: encapsulate, encapsulate, encapsulate. Unfortunately, apps using inter-app communication tend to do the opposite. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On 15 Des, 02:59, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: oowriter --print some.doc | ps2pdf encapsulate, encapsulate. Unfortunately, apps using inter-app communication tend to do the opposite. That pipe is a form of IPC as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Doug Morse a écrit : ottop-post corrected/ot But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. although perhaps not a part of the definition of scripting languages per se, I still wait to see any clear, unambiguous definition of scripting language. Which one are you refering to here ? (snip) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Terry Reedy a écrit : Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Then ask them what's a scripting language exactly... or download this, print it and put it on the wall near your desktop: http://apipes.blogspot.com/2005/01/choose-python.html Whenever I hear a comment like that I can feel myself boiling inside. As far as I'm concerned, anyone (I mean, anyone pretending to be a programmer) being ignorant enough to ask such a question ranks high in my bozo list. Don't waste time with bozos. I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. Indeed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Bruno Desthuilliers wrote: As far as I'm concerned, anyone (I mean, anyone pretending to be a programmer) being ignorant enough to ask such a question ranks high in my bozo list. Don't waste time with bozos. Alan Kay said it well enough without using words like pretending, ignorant and bozo :) http://acmqueue.com/modules.php?name=Contentpa=showpagepid=273 It's worth a read. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Marco Mariani a écrit : Bruno Desthuilliers wrote: As far as I'm concerned, anyone (I mean, anyone pretending to be a programmer) being ignorant enough to ask such a question ranks high in my bozo list. Don't waste time with bozos. Alan Kay said it well enough without using words like pretending, ignorant and bozo :) Probably. But I do like using these words, and having the opportunity to use them three in a same post really made me happy !-) http://acmqueue.com/modules.php?name=Contentpa=showpagepid=273 It's worth a read. Whenever I'll get a couple minutes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Neil Cerutti a écrit : On 2007-12-13, Steven D'Aprano [EMAIL PROTECTED] wrote: I have repeatedly argued in the past that we do ourselves a disservice by describing Python as an interpreted language. Python is compiled. It has a compiler. It even has a built-in function compile. It's just not compiled to *machine code* -- but with even machine code often running on a virtual machine in the CPU(s), the distinction is far less important now than it was when Sun described Java as a compiled language despite the lack of JIT compilers. When folks say Python is an interpreted language I think they mean it informally--they just mean you have to run an interpreter to execute it. How often do you hear that Java is an interpreted language ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On 2007-12-13, Steven D'Aprano [EMAIL PROTECTED] wrote: I have repeatedly argued in the past that we do ourselves a disservice by describing Python as an interpreted language. Python is compiled. It has a compiler. It even has a built-in function compile. It's just not compiled to *machine code* -- but with even machine code often running on a virtual machine in the CPU(s), the distinction is far less important now than it was when Sun described Java as a compiled language despite the lack of JIT compilers. When folks say Python is an interpreted language I think they mean it informally--they just mean you have to run an interpreter to execute it. *How* it's translated is irrelevent to the *informal* meaning. And I'd further argue that the informal meaning is the only one that makes any sense. Formally: hasattr(Language, 'iterpreted') False hasattr(Implementation, 'interpreted') True ;-) -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Neil Cerutti [EMAIL PROTECTED] writes: On 2007-12-13, Steven D'Aprano [EMAIL PROTECTED] wrote: I have repeatedly argued in the past that we do ourselves a disservice by describing Python as an interpreted language. Python is compiled. It has a compiler. It even has a built-in function compile. It's just not compiled to *machine code* -- but with even machine code often running on a virtual machine in the CPU(s), the distinction is far less important now than it was when Sun described Java as a compiled language despite the lack of JIT compilers. When folks say Python is an interpreted language I think they mean it informally--they just mean you have to run an interpreter to execute it. *How* it's translated is irrelevent to the *informal* meaning. And I'd further argue that the informal meaning is the only one that makes any sense. Many people still talk about lisp as interpreted despite the fact that there have been compilers (that compile to machine code) for decades. I'm not sure it's really a property of a language, rather of an implementation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On 2007-12-13, Bruno Desthuilliers [EMAIL PROTECTED] wrote: Neil Cerutti a écrit : On 2007-12-13, Steven D'Aprano [EMAIL PROTECTED] wrote: I have repeatedly argued in the past that we do ourselves a disservice by describing Python as an interpreted language. Python is compiled. It has a compiler. It even has a built-in function compile. It's just not compiled to *machine code* -- but with even machine code often running on a virtual machine in the CPU(s), the distinction is far less important now than it was when Sun described Java as a compiled language despite the lack of JIT compilers. When folks say Python is an interpreted language I think they mean it informally--they just mean you have to run an interpreter to execute it. How often do you hear that Java is an interpreted language ? The difference is the p-code factor. Python's p-code is (generally) internal only. We could fool more people if we forced them to create .pyc files before executing the code. ;-) -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On 13 Des, 02:19, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: I have repeatedly argued in the past that we do ourselves a disservice by describing Python as an interpreted language. Python is compiled. It has a compiler. It even has a built-in function compile. Python is compiled to bytecode. Python's bytecode is interpreted. Does that make Python interpreted or compiled? I could not care less. The terms 'scripting language' and 'interpreted language' have somewhat different meanings. 'Scripting language' typically means a language used for one of: - Shell scripts - Automation macros in a larger application - Code embedded in a web page - CGI Python, Perl, Lisp and Visual Basic are certainly used as scripting languages in some settings. But that does not mean it is the only thing they can be used for. On the other hand, JavaScript and Bourne shell have little use except as scripting languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Thu, 13 Dec 2007 10:32:23 -0800, sturlamolden wrote: On 13 Des, 02:19, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: I have repeatedly argued in the past that we do ourselves a disservice by describing Python as an interpreted language. Python is compiled. It has a compiler. It even has a built-in function compile. Python is compiled to bytecode. Python's bytecode is interpreted. If you want to be pedantic, machine-code is interpreted by the CPU. Does that make Python interpreted or compiled? I could not care less. Sadly, many people who shouldn't, do. Instead of asking Is Python fast *enough* for my task? they ask Is Python fast?, and then compound it by assuming that since it's interpreted it obviously must be slow. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Bruno Desthuilliers wrote: http://acmqueue.com/modules.php?name=Contentpa=showpagepid=273 An interesting quote from that: If you combine Simula and Lisp—Lisp didn’t have data structures, it had instances of objects—you would have a dynamic type system that would give you the range of expression you need. Sounds like AK is talking about Python here and doesn't know it... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Dec 12, 4:34 am, Terry Reedy [EMAIL PROTECTED] wrote: Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. It depends on your definition of scripting language, I guess. Python it byte-compiled and run in an interpreter. Much like how Java is run, only the compilation of python scripts is usually hidden from the user. You could argue that python is no more of a scripting language then Java. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Wed, 12 Dec 2007 08:35:40 -0800, oj wrote: On Dec 12, 4:34 am, Terry Reedy [EMAIL PROTECTED] wrote: Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. It depends on your definition of scripting language, I guess. Python it byte-compiled and run in an interpreter. Much like how Java is run, only the compilation of python scripts is usually hidden from the user. You could argue that python is no more of a scripting language then Java. I have repeatedly argued in the past that we do ourselves a disservice by describing Python as an interpreted language. Python is compiled. It has a compiler. It even has a built-in function compile. It's just not compiled to *machine code* -- but with even machine code often running on a virtual machine in the CPU(s), the distinction is far less important now than it was when Sun described Java as a compiled language despite the lack of JIT compilers. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
although perhaps not a part of the definition of scripting languages per se, one aspect of them is that they are often used to glue a wide variety of other components together. perl's initial and continued success is in no small part to all the wrappers and interfaces it has to all sorts of other software components and applications. part of python's utility, IMHO, is the ease with which it can be used, like perl, to glue together a lot of disparate parts. But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Doug Morse wrote: although perhaps not a part of the definition of scripting languages per se, one aspect of them is that they are often used to glue a wide variety of other components together. perl's initial and continued success is in no small part to all the wrappers and interfaces it has to all sorts of other software components and applications. part of python's utility, IMHO, is the ease with which it can be used, like perl, to glue together a lot of disparate parts. But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. I'm with Doug on this. Python *is* a scripting language which is a *good* thing. It's their perceptions of what scripting languages are capable of that are out-of-date. - Paddy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
The term scripting language is a pretty misunderstood one these days. I hold the opinion that what it is supposed to mean can, today, apply to any language. C, even, is a scripting language. All any of our software today is doing is calling out to some other component and simply acting as a script for what these other parts should do. In that respect, what does it matter what language you're controlling the exact same libraries from? Well, now what matters is how easily that language makes it to do so. Selling other developers to new languages can be difficult. There is a lot of stigma to taking steps outside what they think of as the norm. Showing them what you can do in a scripting language is the first step. Remind them that Python is a bytecode compiled language over a virtual machine, just like the Java you're already using. On Dec 11, 2007, at 7:24 PM, Ron Provost wrote: OK, I don't mean to start any sort of war or flaming or anything here but I really need to discuss this with other afficionados of Python - I know none other than myself. I'm a software developer. Where I work, the dominant development language is Java with some mostly-legacy C/C++ software. In places where I don't need to directly integrate with our Java suite of apps, the first thing I ask is, do you mind if I do that in Python? in several cases I was given approval after demonstrating stuff I've already done (These people giving approval are generally not very technical). Now, I've also shown my applications (both work related and my own projects) to other developers at work. Some of the applications I've written are quite sophisticated. I have software which uses pymedia to playback media files and Tkinter/Tix apps with quite-good (infact called very professional looking by a few coworkers) GUIs. Apps that process thousands of records of data in less than a second, and an application I developed which launches our suite of Java applications (previously everything needed to be launched by hand with lots of command-line parameters). Configurations (that specify which apps and which command line parameters) can be created, edited, deleted, saved and loaded. In addition, once the suite of applications is running, my application continues to monitor all the processes (many of which don't have GUIs). The application alerts the user if an app appears to start taking over memory or %CPU (Our app suite is extremely large and complex) and allows a user to selectively terminate apps. It's incredibly useful and I've gotten nothing but complements on the app. But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. While many call Python a scripting language, I acutally use it as a full- fledged programming language. To me a scripting language is sort of like a shell language where I may process output of one app, feed it into another, etc. That is, a scripting language (by my definition) pulls apps together. I don't use python like that (in fact, after my suite launching app I feel subprocess is very immature). What's so different from python generating .pyc files and executing them from javac producing .class files which you then run on java? I've been in the Python world since version 2.3 final was released, so I don't know a lot about the history of Python. Was Python originally more like a scripting language and the culture of refering to it as scripting has just stuck? I would like to see the Python world get away from the script term, perhaps starting in Python 3.x. Ron -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. -- http://mail.python.org/mailman/listinfo/python-list
