By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,978 Members | 1,467 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,978 IT Pros & Developers. It's quick & easy.

Searching for the best scripting language,

P: n/a
Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?

On Saturday Slashdot ran this article on the "best" scripting
languages.
http://developers.slashdot.org/devel...id=126&tid=156

"Folks at the Scriptometer conducted a practical survey of which
scripting language is the best. While question like that is bound to
generate flamewars between the usual Perl vs PHP, Python vs Perl,
VBScript vs everything crowds, the Scriptometer survey is practical:
if I have to write a script, I have to write it fast, it has to be
small (less typing), it should allow me to either debug itself via a
debugger or just verbose output mode. sh, Perl and Ruby won the
competition, and with the difference of 1-2 points they were
essentially tied for first place... Interesting that ICFP contests
lately pronounced OCaml as the winner for rapid development."

Scriptometer site:
http://merd.sourceforge.net/pixel/la...ting-language/

Needless to say, the Ruby site was Slashdot-ed today.

What points are the Scriptometer survey missing, in regards to the
ease of use and beauty of the Python language?

Or should I convert my code base to Ruby and or OCaml? :)

Let the rabid "in defense of Python" flames begin!

-- R.J.
Jul 18 '05 #1
Share this Question
Share on Google+
41 Replies


P: n/a
Hi everybody

Richard James wrote:
What points are the Scriptometer survey missing, in regards to the
ease of use and beauty of the Python language?


Well, better look again at Guido's Tutorial, as it reads at the very
beginning:

"""
If you ever wrote a large shell script, you probably know this feeling:
you'd love to add yet another feature, but it's already so slow, and so
big, and so complicated; or the feature involves a system call or other
function that is only accessible from C
"""

The page misses completely the handling of more complex tasks than those
typically used in any shell (hey, those examples could even be realized
with a DOS batch file :-p). Python might not be the number one choice
for testing whether a file is readable, but ask them why Fedora has
chosen Python for their Anaconda OS Installer and not a shell script...

-Markus

Jul 18 '05 #2

P: n/a
Richard James wrote:
Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?

On Saturday Slashdot ran this article on the "best" scripting
languages.
http://developers.slashdot.org/devel...id=126&tid=156
"Folks at the Scriptometer conducted a practical survey of which
scripting language is the best.


"Practical surveys" are always as hilarious as practical programming, unless
one is asleep to their implications. One of the simple ones, which no doubt
formed much of the basis of this survey, always is: in which situation do I
have to type the least number of characters. For the brainless, this is a
valid test of programming excellence. Hopefully not all programmers in the
world have been reduced to such brainlessness yet.
Jul 18 '05 #3

P: n/a
On Sun, 13 Jun 2004 13:34:43 -0700, Richard James wrote:
"Folks at the Scriptometer conducted a practical survey of which
scripting language is the best. While question like that is bound to
generate flamewars between the usual Perl vs PHP, Python vs Perl,
VBScript vs everything crowds, the Scriptometer survey is practical:
if I have to write a script, I have to write it fast, it has to be
small (less typing), it should allow me to either debug itself via a
debugger or just verbose output mode. sh, Perl and Ruby won the
competition, and with the difference of 1-2 points they were
essentially tied for first place... Interesting that ICFP contests
lately pronounced OCaml as the winner for rapid development."
What points are the Scriptometer survey missing, in regards to the
ease of use and beauty of the Python language?

Or should I convert my code base to Ruby and or OCaml? :)

I recently learned ruby, merely out of curiosity. Now that I know it, I
dont write ANY shell utilities with python anymore. Ruby is a much better
choice for almost all simple administrative tasks. For larger programs,
there are times when python seems like a better choice. Python enforces
consistency and readability. In an environment where many people will be
working on the same code for an extended period of time, the benefits of
python become apparent. That isnt to say that ruby *cant* be used in
situations like that. If ruby programmers layout strict guidelines for a
project regarding style and methodology, it would be just as effective.

The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }

One of my other favorite features of ruby, is the ability to globally add
methods to base types. While I strongly feel that the ability to extend
base types is a powerful feature, I'm sure many python programmers would
disagree.
Or should I convert my code base to Ruby and or OCaml? :)


Ruby and Python really have a lot in common. The one you use should
ultimately be based on your style and how you feel about programming. If
you like lots of mutability, lots of functional idioms, and inline regular
expressions, switch to ruby! If not, stick with python.

I'm an ardent OCaml advocate. Anyone who uses c++ should have their head
examined. OCaml is a fast, statically typed, object oriented language with
type inference, pattern matching, automatic memory management, and
inherent parametric polymorphism (you dont need templates!). Native
compilers AND dynamic interpreters are available. It even comes with an
interactive top-level like python does. OCaml programs typically run
faster than comparable c++ programs, and they take significantly less time
to write. OCaml has a built-in list type, and it comes with all the usual
list manipulation functions (map and filter). OCaml is somewhat difficult
to learn however. If you have the intellectual capacity and the time
required to learn a challenging language, learn OCaml. Additionally, I
should mention that OCaml libraries can easily be integrated with python
programs via pycaml. I use OCaml instead of C to write python extensions.

--SegPhault
Jul 18 '05 #4

P: n/a
In article <2c**************************@posting.google.com >,
rm******@yahoo.com (Richard James) wrote:
Scriptometer site:
http://merd.sourceforge.net/pixel/la...ting-language/

Needless to say, the Ruby site was Slashdot-ed today.


Scriptometer seems heavily biased towards conciseness of code.
Needless to say, that's not why we use and love Python...

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science
Jul 18 '05 #5

P: n/a
rm******@yahoo.com (Richard James) wrote in message news:<2c**************************@posting.google. com>...
Needless to say, the Ruby site was Slashdot-ed today.


This has nothing to do with ./
The site was hacked and corrupted two weeks ago and since this time
one a stub is online.
Jul 18 '05 #6

P: n/a
Ryan Paul <se*******@sbcglobal.net> wrote in message news:<pa****************************@sbcglobal.net >...
Ruby and Python really have a lot in common. The one you use should
ultimately be based on your style and how you feel about programming. If
you like lots of mutability, lots of functional idioms, and inline regular
expressions, switch to ruby! If not, stick with python.


Or if you need real multithreading and WxPython. This are IMHO the
reasons not to switch to ruby. The python implementation is
technically much better. And the python libraries are still much
better then ruby.

As the person behind "http://www.python-ide.com" and
"http://www.ruby-ide.com" i can tell you that otherwise the language
are almost the same. For example from the 18000 lines of code for the
debugger about 2000 lines are different for this two languages.

But look yourself. A weekend should be enough for a python programmer
to learn ruby.
Jul 18 '05 #7

P: n/a
Richard James wrote:
What points are the Scriptometer survey missing, in regards to the
ease of use and beauty of the Python language?


Everything. It's definitely one of the most useless side-by-side
comparisons I've ever seen.

The program lengths criterion is ridiculous. It rewards Perl for
using unreadable line noise.

(Since when does Perl have an interactive interpretter?)
--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon
Jul 18 '05 #8

P: n/a
Ryan Paul wrote:
....
required to learn a challenging language, learn OCaml. Additionally, I
should mention that OCaml libraries can easily be integrated with python
programs via pycaml. I use OCaml instead of C to write python extensions.


do you have examples? i could only get it to work the other way round.
graham
Jul 18 '05 #9

P: n/a
Richard James wrote:
Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?


Everyone knows that any scripting language shootout that doesn't show
Python as the best language is faulty by design.

regards Max M
Jul 18 '05 #10

P: n/a
Richard James wrote:
Let the rabid "in defense of Python" flames begin!


I will defend python from a different perspective namely that of handicapped usability. Python doesn't contain a whole lot of "modem line noise" characters and with the help of python mode in emacs, does a lot of the indentation properly. So all in all, it minimizes hand use which minimizes physical pain.
I suspect that a blind user would also have greater ease using and working with python for the same reason. modem line noise characters and, funny spelling mixed case are the three biggest impediments to usability by handicapped people.

I would love to have an IDE (to tie into another thread) which would work well with speech recognition. There is already a project (voice coder) which has built a lot of the infrastructure necessary to do so but it (in my opinion) is hampered by the one-way nature of that integration. I believe for handicapped accessibility to programming environments to be truly useful there needs to be a two-way integration where the IDE reveals information about the application so that appropriate grammars and symbols will be revealed and made speakable.

---eric
Jul 18 '05 #11

P: n/a
In article <9h*****************@fe2.columbus.rr.com>,
Carl Banks <im*****@aerojockey.invalid> wrote:
Jul 18 '05 #12

P: n/a
Ryan Paul wrote:
The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }


This is proof of something, I'm sure, but for me it's simply another
indication that (a) Ruby is more like Perl than it is like Python,
(b) unreadable code can be written in any language, and (c) I
really don't mind using 15 lines to write something if it means
the resulting code can readily be understood.

Thanks for reinforcing my lack of interest in switching to Ruby. :-)

-Peter
Jul 18 '05 #13

P: n/a
Peter Hansen wrote:
Please don't take that code snippet as an example of Ruby but more as evidence
of a bad programmer, as you said "unreadable code can be written in any
language" and Paul Ryan has just proved it.

Take it this way, if someone showed you some badly written Python would that put
you off Python?
Jul 18 '05 #14

P: n/a
Peter Hickman wrote:
Take it this way, if someone showed you some badly written Python would
that put you off Python?


I'm waiting to see anyone succeed at writing Python code that badly.
I'd argue that it's not possible, unless one is deliberately trying
to make Python look bad.

(Note: I'm not saying people don't write really poor Python code,
or even code that looks awful. I am saying that I don't think
even the worst that I've seen would actually have made me say
"Ugh, Python must suck!" as a result, if I didn't already know
what Python was really like.)

-Peter
Jul 18 '05 #15

P: n/a
Peter Hansen wrote:
I'm waiting to see anyone succeed at writing Python code that badly.
I'd argue that it's not possible, unless one is deliberately trying
to make Python look bad.


True, Python's indenting goes a long way to discourage the one line merchants.
Jul 18 '05 #16

P: n/a
In article <ou********************@powergate.ca>,
Peter Hansen <pe***@engcorp.com> wrote:
Ryan Paul wrote:
The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }


This is proof of something, I'm sure, but for me it's simply another
indication that (a) Ruby is more like Perl than it is like Python,
(b) unreadable code can be written in any language, and (c) I
really don't mind using 15 lines to write something if it means
the resulting code can readily be understood.

Jul 18 '05 #17

P: n/a
Show me a programming environment where lines of code per minute is
the most important coding metric, and I'll show you a place where I
would refuse to write code.

Do those guys come from some kind of scripting sweat shop? "Hurry it
up, those scripts have to be on the streets of Hong Kong by Tuesday!"
(Apologies to the Simpsons.)

That's my feeling about the Scriptometer "practical survey". I'll
stand by my statement if you want to substitute "terseness" for "lines
of code per minute".

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #18

P: n/a
On 2004-06-13, Richard James <rm******@yahoo.com> wrote:
Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?
Nope. This study is bogus on one large account.

[ following lines from the 'study' ] if I have to write a script, I have to write it fast, it has to be
small (less typing)


It holds as paramount the lest amount of typing possible. While there is
a good argument that less is more, esp. when comparing something like Java vs.
Python there is a point where that trend reverses itself. IE, 8-10 lines to
do a "hello world" is a little too verbose. On the other hand boiling complex
logic and processing down to a barely comprehensible mess does nothing for
long-term stability, maintainability or, indeed, even short-term programming.

While this guy argues that less typing means faster scripts I'd wager than
in many cases where things are boiled into one liners more time is taken
debugging simple to spot errors if the script were expanded out a bit. In
short his basic premise is flawed. He starts out saying that one of the most
important factors is typing.

I've worked in shell and Perl. Haven't worked in Ruby yet. I still
prefer Python because, even though I am typing a little more (actually, in
some cases a little less[1]) I am coding faster ovarall because I'm trying to
do it right, not tight.
[1] In reality my Perl code was often slightly larger than my Python code
because I refused to use certain Perlisms. My coding practice in Perl was far
more rigid than the language allowed. This was so I could have some chance of
being able to read and modify my code at a later date. Could I have whipped
out tons of tight little one-liners in my Perl code and made it shorter than
my Python code? Sure. Did I want to? Hell no.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Jul 18 '05 #19

P: n/a
ll*****@web.de (Lothar Scholz) wrote in message news:<6e**************************@posting.google. com>...
rm******@yahoo.com (Richard James) wrote in message news:<2c**************************@posting.google. com>...
Needless to say, the Ruby site was Slashdot-ed today.


This has nothing to do with ./
The site was hacked and corrupted two weeks ago and since this time
one a stub is online.


This info was from an early post on comp.lang.ruby

http://groups.google.com/groups?dq=&...comp.lang.ruby

And it was corrected to reflect that the Ruby site is "down for
maintenance".

Maybe they need to use Zope? :)

And it's /. :)
Jul 18 '05 #20

P: n/a
On 14 Jun 2004 11:39:08 -0700, rm******@yahoo.com (Richard James)
wrote:

And it was corrected to reflect that the Ruby site is "down for
maintenance".

Maybe they need to use Zope? :)

And it's /. :)


No this posting is as wrong as yours.

The site is down since 29. May 2004 and all data will be manually
reviewed before the services go back online. The RAA is back since
7.Juni 2004, the other services will follow.

Jul 18 '05 #21

P: n/a
Peter Hansen <pe***@engcorp.com> wrote in message news:<ou********************@powergate.ca>...
Ryan Paul wrote:
The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }


This is proof of something, I'm sure, but for me it's simply another
indication that (a) Ruby is more like Perl than it is like Python,
(b) unreadable code can be written in any language, and (c) I
really don't mind using 15 lines to write something if it means
the resulting code can readily be understood.

Thanks for reinforcing my lack of interest in switching to Ruby. :-)

-Peter


Well back in my day, in '75, "Real men" programmed in Intel binary
machine codes without using those "sissy" Assembly language
mnemonics...

I think the value of maintainable code far outweighs cute one line
coding tricks...

And no matter how close to the hardware it made you feel, I really
don't miss those #%$@ front panel switches! :)

-- R.J.
Jul 18 '05 #22

P: n/a
Richard James wrote:
Well back in my day, in '75, "Real men" programmed in Intel binary
machine codes without using those "sissy" Assembly language
mnemonics...
You used *binary*?! Ah, luxury....
I think the value of maintainable code far outweighs cute one line
coding tricks...

And no matter how close to the hardware it made you feel, I really
don't miss those #%$@ front panel switches! :)

-- R.J.

Jul 18 '05 #23

P: n/a
In article <9u********************@powergate.ca>,
Peter Hansen <pe***@engcorp.com> wrote:
Richard James wrote:
Well back in my day, in '75, "Real men" programmed in Intel binary
machine codes without using those "sissy" Assembly language
mnemonics...


You used *binary*?! Ah, luxury....


Yeah, right. When I started out, they only let us use zeros. You had
to pay your dues for a few years before they started letting you use any
ones.
Jul 18 '05 #24

P: n/a
Ryan Paul wrote:
The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }

Oh boy. I believe this untested Python code does what you want, also
one line, also wrapped in the name of "clarity."

for f in dict([(__import__('re').sub(r"\.\d+[\d.-]*$","",x),None)
for fn in ("*.rar.*","*.r[0-9][0-9].*")
for x in __import__('glob').glob(prefix+fn)]):
__import__('os').system("cat %s.* > %s" % (sesc(f),sesc(f)))

This would take about 7 lines in well-written Python, not 15.
bad-code-can-be-written-in-any-language-ly yr's,

--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon
Jul 18 '05 #25

P: n/a
Cameron Laird wrote:
In article <9h*****************@fe2.columbus.rr.com>,
Carl Banks <im*****@aerojockey.invalid> wrote:
.
.
.
(Since when does Perl have an interactive interpretter?)

.
.
.
Long time <URL:
http://phaseit.net/claird/comp.lang....teractive.html >.


Heh. It seems to me that, by the same reasoning, we could claim that
Python has verbose execution. Someone's obviously willing to give
Perl the benefit of the doubt here, but not Python. I smell
shenanigans.
--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon
Jul 18 '05 #26

P: n/a
On 2004-06-14, Carl Banks <im*****@aerojockey.invalid> wrote:
Ryan Paul wrote:
["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }
Oh boy. I believe this untested Python code does what you want, also
one line, also wrapped in the name of "clarity." for f in dict([(__import__('re').sub(r"\.\d+[\d.-]*$","",x),None)
for fn in ("*.rar.*","*.r[0-9][0-9].*")
for x in __import__('glob').glob(prefix+fn)]):
__import__('os').system("cat %s.* > %s" % (sesc(f),sesc(f))) This would take about 7 lines in well-written Python, not 15. bad-code-can-be-written-in-any-language-ly yr's,


Ok, see, here's the thing. I look at the Ruby code and can kind of follow
it. I look at the Python code and can kind of follow it. but in neither case
have I, in glancing here and there today, been able to decipher exactly what
is going on. Care to show the 5 line long form to see if I get that? No
explination, just curious to see if I can get it reading real code instead of
hacked up line noise.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Jul 18 '05 #27

P: n/a
Steve Lamb wrote:


On 2004-06-14, Carl Banks <im*****@aerojockey.invalid> wrote:
Ryan Paul wrote:
["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|
Dir[$prefix+fn].collect {|x|
x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|
`cat #{sesc x}.* > #{sesc x}`} }

Oh boy. I believe this untested Python code does what you want, also
one line, also wrapped in the name of "clarity."

for f in dict([(__import__('re').sub(r"\.\d+[\d.-]*$","",x),None)
for fn in ("*.rar.*","*.r[0-9][0-9].*")
for x in __import__('glob').glob(prefix+fn)]):
__import__('os').system("cat %s.* > %s" % (sesc(f),sesc(f)))

This would take about 7 lines in well-written Python, not 15.

bad-code-can-be-written-in-any-language-ly yr's,


Ok, see, here's the thing. I look at the Ruby code and can kind
of follow it. I look at the Python code and can kind of follow it.
but in neither case have I, in glancing here and there today, been
able to decipher exactly what is going on. Care to show the 5 line
long form to see if I get that? No explination, just curious to see
if I can get it reading real code instead of hacked up line noise.


Of course you can.

import glob
import os
import re

f = {}
for pattern in ("*.rar.*","*.r[0-9][0-9].*"):
for listing in glob.glob(prefix+pattern):
f[listing] = None
for filename in f:
os.system("cat %s.* > %s" % (sesc(filename),sesc(filename)))
I don't know what sesc is. I assume he had defined it elsewhere,
because he said this was only part of a script he wrote (and that's
what scares me--I can understand a throwaway one-liner looking like
this, but not a line in a script).
--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon
Jul 18 '05 #28

P: n/a
On 2004-06-14, Carl Banks <im*****@aerojockey.invalid> wrote:
Of course you can. import glob
import os
import re f = {}
for pattern in ("*.rar.*","*.r[0-9][0-9].*"):
for listing in glob.glob(prefix+pattern):
f[listing] = None
for filename in f:
os.system("cat %s.* > %s" % (sesc(filename),sesc(filename)))
Ah, grab anything with a rar extension and more (badly split usenet
binaries?) and splice them together.
I don't know what sesc is. I assume he had defined it elsewhere,


Stab in the darb based on the cat call as well as the purpose of this
snippet I would surmise "space escape". IE, escape possible spaces in the
file name so as not to flub the command line that hits the system call.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Jul 18 '05 #29

P: n/a
Carl Banks wrote:
Heh. It seems to me that, by the same reasoning, we could claim that
Python has verbose execution. Someone's obviously willing to give
Perl the benefit of the doubt here, but not Python. I smell
shenanigans.


I tried a few Google searches, even apparently reaching the page that
started this thread, but I can't see what "verbose execution" might
mean other than (a guess) a "trace" mode which prints something for
every line executed as the interpreter runs. And, if that's really
what it is, then Python does have the capability pretty easily, via
sys.settrace(). (Which I'm sure Carl knows, therefore I assume my
guess is wrong.)

-Peter
Jul 18 '05 #30

P: n/a
In article <C7********************@powergate.ca>,
Peter Hansen <pe***@engcorp.com> wrote:
Carl Banks wrote:
Heh. It seems to me that, by the same reasoning, we could claim that
Python has verbose execution. Someone's obviously willing to give
Perl the benefit of the doubt here, but not Python. I smell
shenanigans.


I tried a few Google searches, even apparently reaching the page that
started this thread, but I can't see what "verbose execution" might
mean other than (a guess) a "trace" mode which prints something for
every line executed as the interpreter runs. And, if that's really
what it is, then Python does have the capability pretty easily, via
sys.settrace(). (Which I'm sure Carl knows, therefore I assume my
guess is wrong.)

Jul 18 '05 #31

P: n/a
In article <FX*******************@fe2.columbus.rr.com>,
Carl Banks <im*****@aerojockey.invalid> wrote:
Ok, see, here's the thing. I look at the Ruby code and can kind
of follow it. I look at the Python code and can kind of follow it.
but in neither case have I, in glancing here and there today, been
able to decipher exactly what is going on. Care to show the 5 line
long form to see if I get that? No explination, just curious to see
if I can get it reading real code instead of hacked up line noise.


Of course you can.

import glob
import os
import re

f = {}
for pattern in ("*.rar.*","*.r[0-9][0-9].*"):
for listing in glob.glob(prefix+pattern):
f[listing] = None
for filename in f:
os.system("cat %s.* > %s" % (sesc(filename),sesc(filename)))
I don't know what sesc is. I assume he had defined it elsewhere,
because he said this was only part of a script he wrote (and that's
what scares me--I can understand a throwaway one-liner looking like
this, but not a line in a script).


As long as we're cleaning up code, how about

import glob, os, sets
f = Set()
for pattern in ("*.rar.*","*.r[0-9][0-9].*"):
f.update(glob.glob(prefix+pattern))
for filename in f:
os.system("cat %s.* > %s" % (sesc(filename),sesc(filename)))

Now it's not even much longer than the original unreadable mess...

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science
Jul 18 '05 #32

P: n/a
rm******@yahoo.com (Richard James) wrote:
Well back in my day, in '75, "Real men" programmed in Intel binary
machine codes without using those "sissy" Assembly language
mnemonics...


Nahh... I had a friend who not only did program straight in
hexadecimal machine code, calculated all the offsets on the fly
without any pencil/paper/calculator, more over, very often, when we
had bugs with a UV-EPROM, he would tell us: "guys, no need to change
the program, see, I can just re-wire the circuit here, put a gate
here, flip these and those switches, and done." When you can
re-program by doing it with hardware, that's "real man". It was
perhaps "sissy" to him to re-write programs and re-record the EPROM,
when he could do it straight by hardware changes in a shorter amount
of time.

(Back then, he never forgot a single telephone number, even if he
heard it only once. Some people are just born hardware geniuses.)

regards,

Hung Jung
Jul 18 '05 #33

P: n/a
Peter Hansen wrote:
Carl Banks wrote:
Heh. It seems to me that, by the same reasoning, we could claim that
Python has verbose execution. Someone's obviously willing to give
Perl the benefit of the doubt here, but not Python. I smell
shenanigans.


I tried a few Google searches, even apparently reaching the page that
started this thread, but I can't see what "verbose execution" might
mean other than (a guess) a "trace" mode which prints something for
every line executed as the interpreter runs. And, if that's really
what it is, then Python does have the capability pretty easily, via
sys.settrace(). (Which I'm sure Carl knows, therefore I assume my
guess is wrong.)

I took it to mean the same thing you did (you might note that shell
scripts are listed as having verbose execution, which pretty much can
only mean that one thing).

My point was, Perl's interactive interpretter isn't "real"; to get it,
you have to invoke the debugger, or use a little Perl program to get
the effect. Likewise, Python's verbose execution isn't "real"; you
can't get it with a simple command line argument. You have to define
a settrace function.

Yet, they list Perl as having an interactive interpretter, by Python
as not having verbose execution. Smells like a someone has an
unconscious bias here.
--
CARL BANKS http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work."
-- Parody of Mr. T from a Robert Smigel Cartoon
Jul 18 '05 #34

P: n/a
In article <FY*******************@fe2.columbus.rr.com>,
Carl Banks <im*****@aerojockey.invalid> wrote:
I took it to mean the same thing you did (you might note that shell
scripts are listed as having verbose execution, which pretty much can
only mean that one thing).

My point was, Perl's interactive interpretter isn't "real"; to get it,
you have to invoke the debugger, or use a little Perl program to get
the effect. Likewise, Python's verbose execution isn't "real"; you
can't get it with a simple command line argument. You have to define
a settrace function.

Yet, they list Perl as having an interactive interpretter, by Python
as not having verbose execution. Smells like a someone has an
unconscious bias here.


The command lines they used for getting an interactive interpreter are
listed near the bottom of the page
http://merd.sourceforge.net/pixel/la...ting-language/
for perl, the line is
perl -de 1
and the verbose execution command is
perl -d:Trace
If you know of a batteries-included and similarly easy way to get
verbose execution of some sort for Python, I suggest you send it to them
via the email link at the top of the page -- I've found them open to
feedback and suggestions.

BTW, the shell script verbose execution is "sh -x".

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science
Jul 18 '05 #35

P: n/a
Richard James wrote:
Let the rabid "in defense of Python" flames begin!


Come on, folks. Just look what "language" got the most points.
Who would not refuse to write a shellscript of more than, say, 100 lines
(except for quoting masochists)?

Reinhold

--
If a Linux distribution brought as few working software as Windows it
would be a shame. The equivalent of Windows' "complete operating system"
is called a rescue disk in the Linux world.
-- David Kastrup in de.comp.os.unix.linux.misc, translated from German
Jul 18 '05 #36

P: n/a
David Eppstein <ep******@ics.uci.edu> wrote in message news:<ep****************************@news.service. uci.edu>...
In article <FX*******************@fe2.columbus.rr.com>,
Carl Banks <im*****@aerojockey.invalid> wrote:
Ok, see, here's the thing. I look at the Ruby code and can kind
of follow it. I look at the Python code and can kind of follow it.
but in neither case have I, in glancing here and there today, been
able to decipher exactly what is going on. Care to show the 5 line
long form to see if I get that? No explination, just curious to see
if I can get it reading real code instead of hacked up line noise.


Of course you can.

import glob
import os
import re

f = {}
for pattern in ("*.rar.*","*.r[0-9][0-9].*"):
for listing in glob.glob(prefix+pattern):
f[listing] = None
for filename in f:
os.system("cat %s.* > %s" % (sesc(filename),sesc(filename)))
I don't know what sesc is. I assume he had defined it elsewhere,
because he said this was only part of a script he wrote (and that's
what scares me--I can understand a throwaway one-liner looking like
this, but not a line in a script).


As long as we're cleaning up code, how about

import glob, os, sets
f = Set()
for pattern in ("*.rar.*","*.r[0-9][0-9].*"):
f.update(glob.glob(prefix+pattern))
for filename in f:
os.system("cat %s.* > %s" % (sesc(filename),sesc(filename)))

Now it's not even much longer than the original unreadable mess...


I just noticed that I mistakenly left out the regexp in my clean code.
Where I had f[listing] = None, I should have
f[re.sub(r"\.\d+[\d.-]*$","",listing)] = None, or an extra varible.
--
CARL BANKS
Jul 18 '05 #37

P: n/a
In article <60**************************@posting.google.com >,
im*****@aerojockey.com (Carl Banks) wrote:
import glob
import os
import re

f = {}
for pattern in ("*.rar.*","*.r[0-9][0-9].*"):
for listing in glob.glob(prefix+pattern):
f[listing] = None
for filename in f:
os.system("cat %s.* > %s" % (sesc(filename),sesc(filename)))
I don't know what sesc is. I assume he had defined it elsewhere,
because he said this was only part of a script he wrote (and that's
what scares me--I can understand a throwaway one-liner looking like
this, but not a line in a script).


As long as we're cleaning up code, how about

import glob, os, sets
f = Set()
for pattern in ("*.rar.*","*.r[0-9][0-9].*"):
f.update(glob.glob(prefix+pattern))
for filename in f:
os.system("cat %s.* > %s" % (sesc(filename),sesc(filename)))

Now it's not even much longer than the original unreadable mess...


I just noticed that I mistakenly left out the regexp in my clean code.
Where I had f[listing] = None, I should have
f[re.sub(r"\.\d+[\d.-]*$","",listing)] = None, or an extra varible.


I was wondering where the import re was supposed to be used...
so the line
f.update(glob.glob(prefix+pattern))
should become
for listing in glob.glob(prefix+pattern):
f.add(re.sub(r"\.\d+[\d.-]*$","",listing)
I guess? Not so different from what you posted, after that change...

As long as we're admitting to mistakes in code, I should have used
sets.Set instead of just Set in the second line.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science
Jul 18 '05 #38

P: n/a
* Ryan Paul (2004-06-14 02:20 +0100)
I recently learned ruby, merely out of curiosity. Now that I know it, I
dont write ANY shell utilities with python anymore. Ruby is a much better
choice for almost all simple administrative tasks. For larger programs,
there are times when python seems like a better choice. Python enforces
consistency and readability. In an environment where many people will be
working on the same code for an extended period of time, the benefits of
python become apparent. That isnt to say that ruby *cant* be used in
situations like that. If ruby programmers layout strict guidelines for a
project regarding style and methodology, it would be just as effective.

The proof is in the source. This is part of a ruby program I wrote. This
snippet is actually a single 'line'. I broke it into several lines for
slightly improved readability. This single line would probably take at
least 15 lines to do in python, probably more if you wanted to do it
intelligently.

["*.rar.*", "*.r[0-9][0-9].*"].each {|fn|Dir[$prefix+fn].collect {|x|x.gsub(/\.\d+[\d.-]*$/,"")}.uniq.each {|x|`cat #{sesc x}.* > #{sesc x}`} }


If you still believe in oneliners you deserve Ruby (and Perl). I
wouldn't want to be you if you ever have to modify your code some time
in the future.

Thorsten
Jul 18 '05 #39

P: n/a
Max M wrote:
Richard James wrote:
Are we looking at the scripting world through Python colored glasses?
Has Python development been sleeping while the world of scripting
languages has passed us Pythonista's by?

Everyone knows that any scripting language shootout that doesn't show
Python as the best language is faulty by design.


loveley :-)

--
Christian Tismer :^) <mailto:ti****@stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
Jul 18 '05 #40

P: n/a
On Mon, 14 Jun 2004 11:34:18 -0400, rumours say that Peter Hansen
<pe***@engcorp.com> might have written:
I'm waiting to see anyone succeed at writing Python code that badly.


This is a FAQ :)

http://www.python.org/doc/faq/programming.html#id19
--
TZOTZIOY, I speak England very best,
"Tssss!" --Brad Pitt as Achilles in unprecedented Ancient Greek
Jul 18 '05 #41

P: n/a
On Mon, 14 Jun 2004 15:20:43 -0400, rumours say that Roy Smith
<ro*@panix.com> might have written:
In article <9u********************@powergate.ca>,
Peter Hansen <pe***@engcorp.com> wrote:
Richard James wrote:
> Well back in my day, in '75, "Real men" programmed in Intel binary
> machine codes without using those "sissy" Assembly language
> mnemonics...


You used *binary*?! Ah, luxury....


Yeah, right. When I started out, they only let us use zeros. You had
to pay your dues for a few years before they started letting you use any
ones.


That's nothing. After four years of intensive coding and debugging,
they *might* get generous enough to provide us with a power cord for the
machine.
--
TZOTZIOY, I speak England very best,
"Tssss!" --Brad Pitt as Achilles in unprecedented Ancient Greek
Jul 18 '05 #42

This discussion thread is closed

Replies have been disabled for this discussion.