On Apr 2, 2:50 pm, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Mar 30, 2012 at 2:48 AM, Steve Howell <showel...@yahoo.com> wrote: > > I agree with you on the overall point, but I think that Python > > actually does a fine job of replacing REXX and PHP. I've used both of > > the latter (and, of course, Python). REXX and PHP are great at what > > they do, but I don't think their slight advantages over Python justify > > all the weight they carry--incompatible syntax to Python, archaic > > libraries, missing modern language features, etc. > > I think you're probably right about REXX, mainly because it's somewhat > old now. It was an awesome language when I first met it back in the > 1990s; it tied in very nicely with OS/2, it was (and is) easy to > extend and embed with C, it had excellent GUI facilities (as long as > you don't need it to be cross-platform). But today, REXX is somewhat > outclassed. I don't recommend it to people for most tasks, unless > they're actually on OS/2 (in which case they probably know it > already). Unicode support and cross-platform GUI toolkits would > probably be REXX's two biggest lacks. > > As to PHP? I don't think it's "great at what [it] [does]", frankly. At > least, it's not great at what it's often used for. PHP is adequate as > a "variant of HTML that allows scripting", but it's usually used today > as though it were a CGI script, and for that it's less than optimal. > For instance, you can't have an include file without it also being an > entry point of its own (eg someone could go > tohttp://www.example.com/common_functions.php), so you need code to > protect against that. Huge frameworks have such code peppered > throughout. > > (As a side point, I don't believe that a web server's CGI scripts > should be updated simply by writing to the disk. It's pretty easy to > get non-atomicity problems when you have a page and its include file. > There ARE other options, but I don't know of any efficient ways to do > it in Python.) > > > Python should also be a perfectly good superset of Bash Scripting > > language. (To the extent that Python isn't, there's nothing intrinsic > > about the language that prevents you from orchestrating processes.) > > Hmm... How do you pipe one command's output into another's input using > Python? It's not nearly as clean as it is in bash. >
For pipes, I'd still call out to bash. I know that's cheating, but the idea is that Python can wrap all the good parts of bash while still allowing you to use Python's more modern syntax, standard library, etc. -- http://mail.python.org/mailman/listinfo/python-list
