What's TOTALLY COMPELLING about Ruby over Python?
Brandon J. Van Every
What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
COOL!!! ***MAN*** that would save me a buttload of work and make my life
sooooo much easier!"
As opposed to minor differences of this feature here, that feature there.
Variations on style are of no interest to me. I'm coming at this from a C++
background where even C# looks like an improvement. ;-) From 10,000 miles
up, is there anything about Ruby that's a "big deal" compared to Python?
One person mentioned Japanese documentation. I'm sure that's Totally Kewl
to the Japanese....
--
Cheers, www.3DProgrammer.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Andrew Dalke
> What's ***TOTALLY COMPELLING*** about Ruby over Python?
Nothing.
I think several people have been very explicit in saying
that Ruby has some advantages over Python, and vice versa,
that in most cases it's a wash, but that there's nothing 'TOTALLY
COMPELLING" about Ruby.
You need to acquire critical reading skills.
And this sort of post is making your troll mark almost indelible.
Andrew
da...@dalkescientific.com
Daniel Dittmar
> What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
> up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
> COOL!!! ***MAN*** that would save me a buttload of work and make my life
> sooooo much easier!"
Code blocks, although I'd rather go to the source and steal them from
Smalltalk.
Python now has most of the parts to implement code blocks, perhaps not
exactly like Smalltalk, but enough to make them useful. What is lacking
is a syntax to be able to create lambdas with multiple statements. And
perhaps a syntax without using the keyword lambda, as some people seem
to have an allergic reaction to it.
Daniel
Peter Hansen
>
> Brandon J. Van Every wrote:
> > What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
> > up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
> > COOL!!! ***MAN*** that would save me a buttload of work and make my life
> > sooooo much easier!"
>
> Code blocks, although I'd rather go to the source and steal them from
> Smalltalk.
What is it about code blocks that would let "save *me* a buttload of work
and make *my* life sooooo much easier"?
If one can't answer that, one shouldn't expect to be able to answer whatever
the heck it is Brandon has in mind (which is clearly not much), since
only he has any idea what it is he wants, and we're not even sure about that...
-Peter
Dave Brueck
> I'm realizing I didn't frame my question well.
>
> What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you
> jump up in your chair and scream "Wow! Ruby has *that*? That is SO
> FRICKIN' COOL!!! ***MAN*** that would save me a buttload of work and make
> my life sooooo much easier!"
Nothing.
-Dave
Jeff Epler
> I'm realizing I didn't frame my question well.
>
> What's ***TOTALLY COMPELLING*** about Ruby over Python?
Nobody who uses Python would believe that there's anything "totally
compelling" about Ruby. If there were, then none of the posts in
c.l.python would be by people using Python. Of course, this doesn't
mean that the newsgroup would be empty. There would still be "enlarge
the size of your Python"-type spam. And there might even be the odd
troll who would keep posting shit, trying to get the Python community
riled up. Of course, without Python users, he wouldn't have much fun,
would he, with nobody stupid enough to stand up to defend Python and
"get trolled". So even the troll should be glad that there's nothing
"totally compelling" about Ruby over Python.
Jeff
PS I'd just like to state for the record that neither Python nor Ruby
have a totally compelling advantage compared to the following languages:
BASIC
/bin/sh
BrainF**k
Forth
IBM 1180 assembler
K&R C
LOGO
make
Objective COBOL
Orthagonal*
RPG/3
WaX
WatFiv Fortran
... conversely, in 1985, about half the above did have a compelling
advantage over both Python and Ruby: they existed.
* Of course, I don't think a non-trivial program was ever written in
Orthagonal, despite the fact that it's been around since '92 or '93.
Andrew Dalke
> What is lacking
> is a syntax to be able to create lambdas with multiple statements. And
> perhaps a syntax without using the keyword lambda, as some people seem
> to have an allergic reaction to it.
How about this?
def Lambda(x, y):
z = x+y
return z
print Lambda(2,3)
;)
In more seriousness, Python makes a strong distinction betweeen statements
and expressions. Lambdas can be used in expressions, so if it includes
statements then what would would the layout look like which preserves
good Pythonic nature?
Here's one such example of defining a function for simple
numerical integration.
def integrate(fctn, start = -1.0, end = 1.0, step = 0.1):
return sum(map(fctn, range(start, end, step)))/((end - start)/step)
print integrate(fctn = def (x):
print "Evaluating at", x,
if x > 0:
y = math.cos(x)
else:
y = math.sin(x)
print "=", y
return y
})
I think Python's parser can handle this. It has a certain charm
to it as well. But if the code is more than a line or two long then
I think it should be a named function. My main complaint is that
I can't stick a 'print' in the lambda, as for debugging. Occasionally
I'll have code akin to
def print_(*args):
print " ".join(map(str, arg)))
return 1
intergrate(lambda x: print_(x) and x)
which is a workaround. But I rarely need it, prefering named
functions over unnamed ones.
Andrew
da...@dalkescientific.com
Patrick Useldinger
> What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
> up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
> COOL!!! ***MAN*** that would save me a buttload of work and make my life
> sooooo much easier!"
The simple fact that *you* are not active on c.l.ruby?
A time-saver, certainly ;-)
--
Real e-mail address is 'cHVAdm8ubHU=\n'.decode('base64')
Visit my Homepage at http://www.homepages.lu/pu/
Erik Max Francis
> I'm realizing I didn't frame my question well.
>
> What's ***TOTALLY COMPELLING*** about Ruby over Python?
comp.lang.ruby doesn't have Brandon Van Every.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ I dream things that never were and say, "Why not?"
\__/ John F. Kennedy
Istvan Albert
>>What's ***TOTALLY COMPELLING*** about Ruby over Python?
>
> comp.lang.ruby doesn't have Brandon Van Every.
LOL
Istvan.
Skip Montanaro
Brandon> I'm realizing I didn't frame my question well. What's
Brandon> ***TOTALLY COMPELLING*** about Ruby over Python? What makes
Brandon> you jump up in your chair and scream "Wow! Ruby has *that*?
Brandon> That is SO FRICKIN' COOL!!! ***MAN*** that would save me a
Brandon> buttload of work and make my life sooooo much easier!"
Apparently, not much in this crowd, otherwise most of us would have switched
to Ruby by now. Try asking the Ruby folks. They will probably be able to
come up with some answers for you.
Skip
John Roth
"Peter Hansen" <pe...@engcorp.com> wrote in message
news:3F41208F...@engcorp.com...
> Daniel Dittmar wrote:
> >
> > Brandon J. Van Every wrote:
> > > What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes
you jump
> > > up in your chair and scream "Wow! Ruby has *that*? That is SO
FRICKIN'
> > > COOL!!! ***MAN*** that would save me a buttload of work and make my
life
> > > sooooo much easier!"
> >
> > Code blocks, although I'd rather go to the source and steal them from
> > Smalltalk.
>
> What is it about code blocks that would let "save *me* a buttload of work
> and make *my* life sooooo much easier"?
It's not so much code blocks. It's that Ruby's syntax gives you one code
block for
free in every method call. And the Ruby library is organized so that the
facility
is useful, which Python's isn't (or at least, it isn't as useful.)
All of the Ruby collections implement a .each method, which is essentially
a version of the Visitor pattern. If I want to do something to every element
in a list or a dict (or any kind of collection,) all I have to do is say
something
like (using Python syntax):
collectObj.each(<method name>)
In Python, that's either a lambda (which restricts what you can do with it,)
or a named function (which is overkill a huge amount of the time.) And you
have to worry about distinctions between functions and methods. In other
words, it's a mess compared to Ruby.
Now, you can say: "We've got that with map()." Well, we've got it when
your inputs are either lists (or implement the correct protocol) but the
result is a list, it's not an internal modification to the object's state.
You can also say: we can do that with for. Well, duh. For is a
statement, not a method call.
To continue on this vein, Ruby directly implements Visitor, Observer,
Delegate and Singleton. I don't particularly like the way it does some
of them, but Python can't claim any one of the four!
Granted, you can do a clean singleton using new style classes and the
__new__() method, but (as of 2.3) it's not anywhere in the core
documentation
that I could find. Observer is simply a couple of classes. Visitor I've
discussed above, and I'll leave Delegate for the reader.
> If one can't answer that, one shouldn't expect to be able to answer
whatever
> the heck it is Brandon has in mind (which is clearly not much), since
> only he has any idea what it is he wants, and we're not even sure about
that...
It might be better to simply take the question at face value, rather than
slanging Brandon. I don't find the personalities to add anything of value
to the conversation.
John Roth
>
> -Peter
Henk Burgstra
>
> And this sort of post is making your troll mark almost indelible.
>
Brandon is not a troll. He is very serious in his quest to find a good
'alternative' language. Look him up on Google.
Regards,
Henk Burgstra
Michael Sparks
> What's ***TOTALLY COMPELLING*** about Ruby over Python?
You can create lasers using rubies I believe whereas pythons are simply
cute.
Michael.
(Since this is clearly a troll :)
Peter Hansen
>
> "Peter Hansen" <pe...@engcorp.com> wrote:
> > What is it about code blocks that would let "save *me* a buttload of work
> > and make *my* life sooooo much easier"?
>
> It's not so much code blocks. It's that Ruby's syntax gives you one code
> block for
> free in every method call. And the Ruby library is organized so that the
> facility
> is useful, which Python's isn't (or at least, it isn't as useful.)
>
> All of the Ruby collections implement a .each method, which is essentially
> a version of the Visitor pattern. If I want to do something to every element
> in a list or a dict (or any kind of collection,) all I have to do is say
> something
> like (using Python syntax):
>
> collectObj.each(<method name>)
>
> In Python, that's either a lambda (which restricts what you can do with it,)
> or a named function (which is overkill a huge amount of the time.) And you
> have to worry about distinctions between functions and methods. In other
> words, it's a mess compared to Ruby.
>
> Now, you can say: "We've got that with map()." Well, we've got it when
> your inputs are either lists (or implement the correct protocol) but the
> result is a list, it's not an internal modification to the object's state.
>
> You can also say: we can do that with for. Well, duh. For is a
> statement, not a method call.
So what you seem to be saying is that Ruby has some features which
in some cases can save some time or somewhat simplify code that when
written in Python would take slightly longer or be slightly more
complicated. (This probably underemphasizes the value you place on
such a thing, but I think that's the gist of it.)
While I do acknowledge that Python is often touted as a great solution
over other languages just because it saves time and simplifies the
resulting solutions, I'm not clear on why these few small differences
would amount to a *TOTALLY COMPELLING* reason, to anyone, to use Ruby
over Python.
-Peter
Alan Kennedy
[Snip: Some stuff about good things that Ruby does]
As someone who has never seen or written a line of Ruby, I find it
most interesting that of all the positive points being made about
Ruby, no-one has posted a single line of Ruby code.
Whenever people are making points about python, they usually post
illustrative snippets of python. Fair enough, it's a python newsgroup,
so maybe Ruby code doesn't belong.
But I am interested to read others opinions of what Ruby has/does that
python hasn't/doesn't. The support for continuations certainly sounds
interesting. Some code snippets would really help, for illustrative
purposes.
but-python-does-almost-everything-that-*i*-need-ly y'rs.
--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan
Brandon J. Van Every
> Brandon J. Van Every:
>> What's ***TOTALLY COMPELLING*** about Ruby over Python?
>
> Nothing.
>
> I think several people have been very explicit in saying
> that Ruby has some advantages over Python, and vice versa,
> that in most cases it's a wash, but that there's nothing 'TOTALLY
> COMPELLING" about Ruby.
That's the answer I was expecting to hear.
> You need to acquire critical reading skills.
No I do not. I was seeking clear verification, and I got what I was looking
for. I suggest that you need to acquire imagination skills. You can't seem
to wrap your head around legitimate reasons for asking a question.
> And this sort of post is making your troll mark almost indelible.
I'm tired of knee-jerkers like you. Welcome to my killfile!
Brandon J. Van Every
> Of course, without Python users, he wouldn't have much fun,
> would he, with nobody stupid enough to stand up to defend Python and
> "get trolled". So even the troll should be glad that there's nothing
> "totally compelling" about Ruby over Python.
I don't want to get sucked into an issue that I have little to no interest
in. So I will observe rhetorically: some of you people waste a *lot* of
energy on games of "who's a troll." Mabye it's time for you to establish a
c.l.p.advocacy newsgroup, to siphon those energies in a particular
direction? But hey, it's your newsgroup.
> Jeff
> PS I'd just like to state for the record that neither Python nor Ruby
> have a totally compelling advantage compared to the following
>
> K&R C
Even as one who hasn't converted to Python yet, that statement is clearly
insane.
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes
>> you jump up in your chair and scream "Wow! Ruby has *that*? That
>> is SO FRICKIN' COOL!!! ***MAN*** that would save me a buttload of
>> work and make my life sooooo much easier!"
>
> The simple fact that *you* are not active on c.l.ruby?
> A time-saver, certainly ;-)
I wonder how large my c.l.p killfile is now?
Brandon J. Van Every
Erik has been in my killfile forever, from other newsgroups. I even had to
put him back in after letting him out. I thought a year would have been
enough, but apparently not.
> LOL
>
> Istvan.
So, you're guilty by association. Goodbye!
Brandon J. Van Every
> On Mon, 18 Aug 2003, Brandon J. Van Every wrote:
>> What's ***TOTALLY COMPELLING*** about Ruby over Python?
>
> You can create lasers using rubies I believe whereas pythons are
> simply cute.
Cute.
> Michael.
> (Since this is clearly a troll :)
I'm tired of repeating the sincerity of my questions to people who can't
imagine what a valid question might look like. Anyone who thinks the
question is "so clearly" a troll, doesn't have the analytical imagination to
be useful to me on Python subjects in general. So, welcome to my killfile.
Patrick Useldinger
> I wonder how large my c.l.p killfile is now?
Humour is a sign of intelligence; being able to joke about oneself even
more so. Try it!
Lyle Johnson
> As someone who has never seen or written a line of Ruby, I find it
> most interesting that of all the positive points being made about
> Ruby, no-one has posted a single line of Ruby code.
There are a lot of folks in the Ruby community writing good introductory
material, with good code samples and such; two of the best authors are
Dave Thomas and Andy Hunt (of the "The Pragmatic Programmer" fame).
Their book, "Programming Ruby", is a must read for new Ruby programmers
and is available on-line here:
http://www.rubycentral.com/book/index.html
If you skim the first few chapters you should get a good feel for how
Ruby is similar to and different from other programming languages, such
as Python.
> But I am interested to read others opinions of what Ruby has/does that
> python hasn't/doesn't. The support for continuations certainly sounds
> interesting. Some code snippets would really help, for illustrative
> purposes.
To answer the last part first, see:
http://www.rubygarden.org/ruby?Continuations
for some information about continuations in Ruby.
For the first part, and the theme of this thread in general, I would
agree with some other posters who've noted that if you're just looking
for a "features shootout" between Python and Ruby, it's probably a draw.
I have zero interest in participating in that kind of discussion, for
the same reasons I don't discuss choices of text editors, Linux
distributions or GUI toolkits with close friends ;) But if you think you
might find Ruby interesting, give it a shot for a short while. As with
Python, most experienced programmers can pick it up very quickly,
usually within a few hours' time.
Hope this helps,
Lyle
John J. Lee
[...]
> It's not so much code blocks. It's that Ruby's syntax gives you one
> code block for free in every method call.
I don't know what that means. Care to explain a bit more?
[...]
> All of the Ruby collections implement a .each method, which is essentially
[...]
> like (using Python syntax):
>
> collectObj.each(<method name>)
[...]
> You can also say: we can do that with for. Well, duh. For is a
> statement, not a method call.
I don't understand. Why does this matter?
I guess you could implement this in Python if you had a burning
desire, using __metaclass__ (caveat: never having had such a desire,
I've never used metaclasses, so I may be wrong).
> To continue on this vein, Ruby directly implements Visitor, Observer,
> Delegate and Singleton. I don't particularly like the way it does some
> of them, but Python can't claim any one of the four!
[...]
And so...?
John
Erik Max Francis
> Erik has been in my killfile forever, from other newsgroups. I even
> had to
> put him back in after letting him out. I thought a year would have
> been
> enough, but apparently not.
There's been at least four of five times where Brandon has claimed to
have put me in his killfile; he keeps "forgetting." Not that that is
terribly surprising coming from someone who is so fond of telling people
about the contents of his killfile.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ I want a martini that could be declared a disaster area.
\__/ Capt. Benjamin "Hawkeye" Pierce
Bruno Desthuilliers
>
>>Brandon J. Van Every:
>>
>
>>And this sort of post is making your troll mark almost indelible.
>
>
> I'm tired of knee-jerkers like you. Welcome to my killfile!
>
Lol ! A certified troll killfiling regular posters ! At this point, it
becomes something like Mastery - with a great 'M'.
Bruno
PS : Brandon, please make my day and tell me : did I won my place in
your killfile too ?-)
Doug Tolton
<newsg...@jhrothjr.com> wrote:
>It might be better to simply take the question at face value, rather than
>slanging Brandon. I don't find the personalities to add anything of value
>to the conversation.
Clearly you haven't followed c.l.p for long, otherwise you wouldn't
make a statement like this. Brandon is *constantly* trolling this
newsgroup with inflammatory and/or contradictory statements.
Seriously do a search using google groups for Brandon Van Every in
comp.lang.python. Your statement is innappropriate take in full
context.
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
Bruno Desthuilliers
LOL 2
Bruno
(yes, I want to be in Brandon's killfile. It's the new game on clp :
being in Brandon's killfile. Just imagine what will happen when every
clp regulars will be in Brandon's kill file...)
Bruno Desthuilliers
> Michael Sparks wrote:
>
>>On Mon, 18 Aug 2003, Brandon J. Van Every wrote:
>>
>>>What's ***TOTALLY COMPELLING*** about Ruby over Python?
>>
>>You can create lasers using rubies I believe whereas pythons are
>>simply cute.
>
>
> Cute.
>
>
>>Michael.
>>(Since this is clearly a troll :)
>
>
> I'm tired of repeating the sincerity of my questions to people who can't
> imagine what a valid question might look like. Anyone who thinks the
> question is "so clearly" a troll, doesn't have the analytical imagination to
> be useful to me on Python subjects in general. So, welcome to my killfile.
>
I too think and cry out loud that you are a troll. I'm I in your
killfile, now ? (c'mon, Brandon, make my day).
Bruno
Arnaldo Riquelme
Bottom line is that people that uses Python have a better sex life than
those that use other languages.
That is ***TOTALLY COMPELLING*** enough for me to use Python.
--ajr
> I'm realizing I didn't frame my question well.
>
> What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you
jump
> up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
> COOL!!! ***MAN*** that would save me a buttload of work and make my life
> sooooo much easier!"
>
> As opposed to minor differences of this feature here, that feature there.
> Variations on style are of no interest to me. I'm coming at this from a
C++
> background where even C# looks like an improvement. ;-) From 10,000
miles
> up, is there anything about Ruby that's a "big deal" compared to Python?
>
> One person mentioned Japanese documentation. I'm sure that's Totally Kewl
> to the Japanese....
Doug Tolton
wrote:
>"Brandon J. Van Every" wrote:
>
>> I'm realizing I didn't frame my question well.
>>
>> What's ***TOTALLY COMPELLING*** about Ruby over Python?
>
>comp.lang.ruby doesn't have Brandon Van Every.
That has got to be the best point in favor of Ruby I've seen so far.
sism...@hebmex.com
>
> There's been at least four of five times where Brandon has claimed to
> have put me in his killfile; he keeps "forgetting." Not that that is
> terribly surprising coming from someone who is so fond of
> telling people about the contents of his killfile.
>
Oohh!! Now you're REALLY gonna get it!
He's gonna REALLY REALLY gonna put you in his killfile!
...maybe!
;-)
-gustavo
pd: Next week on National Enquirer: BRANDON'S KILLFILE!!
Advertencia:La informacion contenida en este mensaje es confidencial y
restringida, por lo tanto esta destinada unicamente para el uso de la
persona arriba indicada, se le notifica que esta prohibida la difusion de
este mensaje. Si ha recibido este mensaje por error, o si hay problemas en
la transmision, favor de comunicarse con el remitente. Gracias.
Andrew Dalke
> All of the Ruby collections implement a .each method, which is essentially
> a version of the Visitor pattern. If I want to do something to every
element
> in a list or a dict (or any kind of collection,) all I have to do is say
> something like (using Python syntax):
>
> collectObj.each(<method name>)
Does that mean 'apply the method to each element of my
collection?'? Does it return a new container or modify things
in-place? Is it applied recursively?
Does it work on strings? Are characters in Ruby also strings?
If so, and if .each is recursive, what's the bottom case?
> And you
> have to worry about distinctions between functions and methods. In other
> words, it's a mess compared to Ruby.
Where does that distinction come into play? A method is a bound
function, kinda like a curried function with self.
I find C++ methods more confusing, because a reference to a
class method is unbound, when I almost always want it bound.
> Now, you can say: "We've got that with map()." Well, we've got it when
> your inputs are either lists (or implement the correct protocol) but the
> result is a list, it's not an internal modification to the object's state.
Ahh. Are strings in Ruby mutable or immutable? ... Yup,
looks like it's mutable. From the FAQ
def downer(string)
string.downcase!
end
a = "HELLO"
downer(a)
puts a #=> "hello"
In which case it makes more sense for this in Ruby than in
Python, since
"ABCDEFG".each(f)
can't do that much unless f modifies state, either as a bound
method or tweaking global variable.
Given that rather fundamental difference, an each method
in Python + code blocks wouldn't be any more powerful
than a for statement. The following is possible
def each(container, f):
for i, x in enumerate(container):
container[i] = f(container[i])
but then it requires the container be indexable, which
is stronger than just being iterable.
How do Ruby's associative arrays work when the string used
as the key is mutated in-place? Is it copy-on-write?
> To continue on this vein, Ruby directly implements Visitor, Observer,
> Delegate and Singleton. I don't particularly like the way it does some
> of them, but Python can't claim any one of the four!
The Python approach to a Singleton is called a 'Borg' class.
Described by Alex Martelli, it looks like
>>> class Borg:
... shared_state = {}
... def __init__(self):
... self.__dict__ = Borg.shared_state
...
>>> x1 = Borg()
>>> x1.a = "Albuquerque"
>>> x2 = Borg()
>>> x2.a
'Albuquerque'
>>>
The other way to get singletons is with a factory function,
which under Python wouldn't look different than a normal
constructor. I looked at some Java code recently and
wanted to suggest a factory implementation only to realized
that would require a lot of 'new' removals.
> Granted, you can do a clean singleton using new style
> classes and the __new__() method,
See Alex's discussion at
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531
as for why singleton (so that 'x1 is x2') is less important
than many consider. Though I know I can't recall needed a
singleton for my code. Maybe I have a different code style?
I've noticed a tendency of mine towards functional programming...
Anyway, others consider Borg a workaround for Python's
until-2.3 unability to support singletons, as with
http://mail.python.org/pipermail/python-list/2002-April/096382.html
As for Observer, etc., I know they are simple classes so I
don't consider them all that important as a differentiator.
> It might be better to simply take the question at face value, rather than
> slanging Brandon. I don't find the personalities to add anything of value
> to the conversation.
Despite my best attempts, I find it almost impossible to slag someone
without including information to back up my view. Eg, I thought my
numbers and trends of mentions of other programming languages was
pretty interesting, but I guess it was of no value to you. :(
Andrew
da...@dalkescientific.com
JZ
couldn't (rationally) use objects or references in Perl, so it has
Perl-ish syntax, which I don't think is very helpful (someday I may
learn it, but Python continues to be far more compelling to me)"
Bruce Ecklel http://mindview.net/FAQ/FAQ-008
JZ
couldn't (rationally) use objects or references in Perl, so it has
Perl-ish syntax, which I don't think is very helpful (someday I may
learn it, but Python continues to be far more compelling to me)"
Bruce Eckel http://mindview.net/FAQ/FAQ-008
John Roth
I don't know either. I do know of several posters on the XP
lists, however, who have switched from Python to Ruby, and
I doubt that it was corporate pressure in any of their cases.
If you're interested (which most of the posters here are not -
I'm certainly not) you might check with them. I'm sure Phlip, for
one, would be more than happy to say why he switched, and what
made the difference.
John Roth
>
> -Peter
John Roth
"Doug Tolton" <dto...@yahoo.com> wrote in message
news:e7l2kv8itrmaair87...@4ax.com...
I've been on c.l.py for around two years. Your statement
is rude and assumes things you have not bothered to check
out.
There is a very simple rule for dealing with trolls, which most
usenet newbies learn sooner or later. If you think someone is
trolling, simply ignore them. Don't answer their posts, don't
comment on them, don't even give them the gratification of
a reply that says: "plonk!" Just killfile them and quit wasteing
bandwidth. You've got better things to do with your time than
maintaining an interaction that you find aggrevating.
John Roth
Andrew Dalke
> in. So I will observe rhetorically: some of you people waste a *lot* of
> energy on games of "who's a troll." Mabye it's time for you to establish
a
> c.l.p.advocacy newsgroup, to siphon those energies in a particular
> direction? But hey, it's your newsgroup.
Search all c.l.py for my posts. The first was 1995/09/11, and Google
says I made 1,160 posts in the last 8 years. Only two ever use the
word troll.
And I never said you were a troll. I said that you were labeled a
troll ("your troll mark"), and you ain't done nothing to wash it off.
> Even as one who hasn't converted to Python yet, that statement is clearly
> insane.
Why the demand that we raise coils^H^H^H^H^Harms against the
incursion of C# / Ruby/ etc. when you youself, in the months since
you first posted here, can't make a firm decision for yourself?
Me:
> > You need to acquire critical reading skills.
> No I do not. I was seeking clear verification, and I got what I was
looking
> for. I suggest that you need to acquire imagination skills. You can't
seem
> to wrap your head around legitimate reasons for asking a question.
As I pointed out in your previous thread, the reasons you stated were
not legitimate. You have not corrected my misconceptions in your
follow-ups it so I remain unconvinced otherwise.
Andrew
da...@dalkescientific.com
John Roth
"Andrew Dalke" <ada...@mindspring.com> wrote in message
news:bhrmk0$hi7$1...@slb0.atl.mindspring.net...
> John Roth
> > All of the Ruby collections implement a .each method, which is
essentially
> > a version of the Visitor pattern. If I want to do something to every
> element
> > in a list or a dict (or any kind of collection,) all I have to do is say
> > something like (using Python syntax):
> >
> > collectObj.each(<method name>)
>
> Does that mean 'apply the method to each element of my
> collection?'? Does it return a new container or modify things
> in-place? Is it applied recursively?
I think that's something that each object which implements .each
needs to specify.
> > And you
> > have to worry about distinctions between functions and methods. In other
> > words, it's a mess compared to Ruby.
>
> Where does that distinction come into play? A method is a bound
> function, kinda like a curried function with self.
Ruby doesn't have functions in the sense that Python does. Since
a module is treated as a class without instances, module level
functions are class methods: they have the module itself as the instance.
I find this to be a conceptually cleaner way of handling the
issue.
> I find C++ methods more confusing, because a reference to a
> class method is unbound, when I almost always want it bound.
Well, in C++, there is no class object to bind it to. I think that's
a difficulty in C++, but then, I don't use the language.
The major difference is in program expressiveness.
As I said, a For statement is a statement, while .each
is an expression, even when followed by a code block.
There's a considerable difference in the way the program
is laid out, which makes a difference in how easy it is to
determine what is being done.
> How do Ruby's associative arrays work when the string used
> as the key is mutated in-place? Is it copy-on-write?
I believe that's true for strings: they're used enough that there's
a special provision for them. For other objects, it's up to the
object type to maintain its hash value properly, or to the
application to rehash the dictionary.
I don't really consider this to be the best policy, though.
I like the Python solution better, though: solve the problem
by not allowing mutable values as keys.
> > To continue on this vein, Ruby directly implements Visitor, Observer,
> > Delegate and Singleton. I don't particularly like the way it does some
> > of them, but Python can't claim any one of the four!
> The Python approach to a Singleton is called a 'Borg' class.
I knew I should have said: "And don't tell me about Borg.
It's a bloody hack that never should have been invented,
and should be quietly buried at the crossroads with a stake
through its heart now that it's possible to do it properly."
And I have said it before, on this newsgroup, in fact.
> The other way to get singletons is with a factory function,
> which under Python wouldn't look different than a normal
> constructor. I looked at some Java code recently and
> wanted to suggest a factory implementation only to realized
> that would require a lot of 'new' removals.
Well, yes. You've always been able to do that, and
the Ruby mechanism is basically a class function. The
thing that the __new__() method (and Borg, to give it
its due) does that neither the factory function nor the
alternate constructor does is use the proper convention
for creating the instance: that is, the class's name.
That means that if you want to convert it from a singleton,
you've got a greater chance of having code you don't have
to touch.
> Despite my best attempts, I find it almost impossible to slag someone
> without including information to back up my view. Eg, I thought my
> numbers and trends of mentions of other programming languages was
> pretty interesting, but I guess it was of no value to you. :(
I found it interesting, but not to the point. If there is one,
it's simply a question of whether any of the differences are
significant enough so someone who knows one language would
consider switching to another one. Google searches won't tell
you that, only looking for people who've made that switch
will tell you.
And I doubt if you'll find them on this newsgroup. That's the
one problem I have with Brandon's questions. If I wanted
to find out whether someone considered Ruby to be sufficiently
better than Python to switch, I'd look on the Ruby newsgroup,
not this one.
I'm basically taking it from the viewpoint of whether there's
anything in Ruby that I think would be good in Python, which
is a question that might interest people on this NG.
John Roth
>
> Andrew
> da...@dalkescientific.com
>
>
Brandon J. Van Every
> [Erik Max Francis]
>>
>> There's been at least four of five times where Brandon has claimed to
>> have put me in his killfile; he keeps "forgetting." Not that that is
>> terribly surprising coming from someone who is so fond of
>> telling people about the contents of his killfile.
Erik, every time you have ever been "responded to," it's been an indirect
quote. You have been in my killfile, and off my radar, for at least a year
if not longer. Sometimes I forget you exist. But every once in awhile I
see your name, quoted, in the groups I participate in. Sometimes I'll
respond to a point you have made, that someone else has followed up to, if
it's a sufficiently interesting point. But you'll notice I never sustain
any debate with you, let alone respond to your muckraking drivel. Notice,
in the present instance, that there is no direct response to your quip about
c.l.r being more useful because I'm not in it. I learned about it
secondhand.
> Oohh!! Now you're REALLY gonna get it!
>
> He's gonna REALLY REALLY gonna put you in his killfile!
>
> ...maybe!
>
> ;-)
>
> -gustavo
>
> pd: Next week on National Enquirer: BRANDON'S KILLFILE!!
And if I continue to killfile all your fellow gremlins, I may yet reach a
time when I never even know. Goodbye, gustavo!
Brandon J. Van Every
>
> PS : Brandon, please make my day and tell me : did I won my place in
> your killfile too ?-)
Yes you did. Goodbye!
Brandon J. Van Every
>> without including information to back up my view. Eg, I thought my
>> numbers and trends of mentions of other programming languages was
>> pretty interesting, but I guess it was of no value to you. :(
>
> I found it interesting, but not to the point. If there is one,
> it's simply a question of whether any of the differences are
> significant enough so someone who knows one language would
> consider switching to another one.
The conclusion around here is pretty ironclad. From a Python standpoint,
Ruby does not matter. And from a technical standpoint, I am not shocked.
Python is already "more exotic" than mainstream industry knows it needs.
Ruby attempts to be "more exotic" than Python. At some point, exoticism is
not what one needs.
> Google searches won't tell
> you that, only looking for people who've made that switch
> will tell you.
>
> And I doubt if you'll find them on this newsgroup. That's the
> one problem I have with Brandon's questions. If I wanted
> to find out whether someone considered Ruby to be sufficiently
> better than Python to switch, I'd look on the Ruby newsgroup,
> not this one.
Actually, I didn't think of looking for converts. Rather, I thought of
looking for language wonks who are knowledgeable about Python + other
languages, who had been through their own analysis of the pros and cons
already. And I found some.
But, I will try your idea because it's a good one. Get your marshmellows
out for c.l.p, "Why did you switch from Python to Ruby?"
Erik Max Francis
> Erik, every time you have ever been "responded to," it's been an
> indirect
> quote. You have been in my killfile, and off my radar, for at least a
> year
> if not longer. Sometimes I forget you exist. But every once in
> awhile I
> see your name, quoted, in the groups I participate in.
Brandon (gotta love that; direct address to someone he's "killfiled"),
adults use killfiles so that they don't have to see posts they've
decided, for whatever reason, that they wish not to read anymore. If
you really wanted to killfile me to avoid reading my posts, you'd adjust
your killfile to toss emails that were in response to me, or at least
show the self-restraint not to read -- and respond! -- to them.
It's clear enough from your behavior in this group (and in other groups
over the years; there's nothing new here) that you say, "Welcome to my
killfile" in order to somehow feel superior over people who really
couldn't give a crap who is in your killfile or isn't. Announcing to
the world who is in your killfile and who isn't is just childish and
stupid. Replying to people who are supposed to be in your killfile to
tell them they are, in fact, in your killfile, is just beyond stupid.
> But you'll notice I never
> sustain
> any debate with you, let alone respond to your muckraking drivel.
Man alive!
> Notice,
> in the present instance, that there is no direct response to your quip
> about
> c.l.r being more useful because I'm not in it. I learned about it
> secondhand.
But you still felt it necessary to mention it, huh?
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ All the people in his neighborhood turn around and get mad and sing
\__/ Public Enemy
Ben Finney
> "Brandon J. Van Every" wrote:
>> Erik, every time you have ever been "responded to," it's been an
>> indirect quote.
>
In this instance, as in all others, Brandon responded to your comment as
seen in someone else's post.
> adults use killfiles so that they don't have to see posts they've
> decided, for whatever reason, that they wish not to read anymore. If
> you really wanted to killfile me to avoid reading my posts, you'd
> adjust your killfile to toss emails that were in response to me, or at
> least show the self-restraint not to read -- and respond! -- to them.
Brandon accesses comp.lang.python via Usenet, not email. His
X-Newsreader header shows he is using Outlook Express. I don't know of
any newsreaders that can allow you to filter on the person(s) to whom
the current post is responding -- nor any email clients with the
facility, for that matter.
The "References" header could theoretically allow you get that
information, but it would be expensive to do so for every message,
especially in long-running threads.
Seeing second-hand comments (as quoted by others) from people in one's
killfile is a hazard of Usenet.
--
\ "Truth: Something somehow discreditable to someone." -- Henry |
`\ L. Mencken |
_o__) |
Ben Finney <http://bignose.squidly.org/>
Aahz
Ben Finney <bignose-h...@and-benfinney-does-too.id.au> wrote:
>
>Brandon accesses comp.lang.python via Usenet, not email. His
>X-Newsreader header shows he is using Outlook Express. I don't know of
>any newsreaders that can allow you to filter on the person(s) to whom
>the current post is responding -- nor any email clients with the
>facility, for that matter.
>
>The "References" header could theoretically allow you get that
>information, but it would be expensive to do so for every message,
>especially in long-running threads.
Supposedly gnus and slrn do that, though.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz
Erik Max Francis
> Seeing second-hand comments (as quoted by others) from people in one's
> killfile is a hazard of Usenet.
Of course. And it's easily avoided with the tiniest bit of
self-restraint.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ No man is more cheated than the selfish man.
\__/ Henry Ward Beecher
Ben Finney
> Ben Finney wrote:
>> Seeing second-hand comments (as quoted by others) from people in one's
>> killfile is a hazard of Usenet.
>
> Of course. And it's easily avoided with the tiniest bit of
> self-restraint.
Uh, no. Seeing them isn't amenable to self-restraint -- you can only
exercise that *after* seeing them.
--
\ "Consider the daffodil. And while you're doing that, I'll be |
`\ over here, looking through your stuff." -- Jack Handey |
Erik Max Francis
> Uh, no. Seeing them isn't amenable to self-restraint -- you can only
> exercise that *after* seeing them.
It's not hard to not read messages from an individual person, with or
without a killfile. Even when the messages are sitting right in front
of you. If you truly don't want to read someone's posts, it's easy to
not read them.
David Eppstein
wrote:
> In article <slrnbk3c1i.2nv.b...@rose.localdomain.fake>,
> Ben Finney <bignose-h...@and-benfinney-does-too.id.au> wrote:
> >
> >Brandon accesses comp.lang.python via Usenet, not email. His
> >X-Newsreader header shows he is using Outlook Express. I don't know of
> >any newsreaders that can allow you to filter on the person(s) to whom
> >the current post is responding -- nor any email clients with the
> >facility, for that matter.
> >
> >The "References" header could theoretically allow you get that
> >information, but it would be expensive to do so for every message,
> >especially in long-running threads.
>
> Supposedly gnus and slrn do that, though.
MT-Newswatcher has no problem with filtering on References:
I use it to make sure I see replies to my own messages,
but I have a distinctive string on the user side of my message-ID's.
Brandon doesn't seem to, but does seem to use a distinctive host:
ID-203719.news.uni-berlin.de.
Googling for that, it seems that the only other stuff you would lose by
killfiling references containing that hostname would be his six-way
crossposts to alt.atheism, alt.politics.bush, alt.fan.noam-chomsky,
soc.culture.iraq, soc.culture.jewish, soc.culture.russian, and
soc.history.war.misc... Some people are still saying he isn't a troll?
--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science
Andrew Dalke
> The "References" header could theoretically allow you get that
> information, but it would be expensive to do so for every message,
> especially in long-running threads.
"expensive"? How? Say 10,000 messages with about 200 messages.
A linear scan is fast enough these days, and it's easy enough to
merge the message ids into a lookup table.
Andrew
da...@dalkescientific.com
Brandon J. Van Every
>
> Googling for that, it seems that the only other stuff you would lose
> by killfiling references containing that hostname would be his six-way
> crossposts to alt.atheism, alt.politics.bush, alt.fan.noam-chomsky,
> soc.culture.iraq, soc.culture.jewish, soc.culture.russian, and
> soc.history.war.misc... Some people are still saying he isn't a troll?
What are you talking about? I've never initiated any such crosspost. I
simply hit (R)eply Group because I, like most people, am too lazy to massage
newsgroup headers all day long. Do I respond to trolls in political forums?
You bet your ass I do. As far as I'm concerned, you've already accepted the
nature of the beast subscribing to such a forum. Your job is to entertain
yourself, and spread something that's truth rather than complete bullshit.
I also don't spend a lot of time in such forums, it's an occasional
dalliance of mine. If you're thorough and fair-minded in your analysis of
my posting habits, you'll discover that fact.
Peter Hansen
The world will be a very quiet, happier place.
-Peter
Ganesan R
> LOL 2
I am not a clp regular (mostly a lurker), but I also wanna play. *please*
;-).
Ganesan
--
Ganesan R
Alex Martelli
...
> than many consider. Though I know I can't recall needed a
> singleton for my code. Maybe I have a different code style?
> I've noticed a tendency of mine towards functional programming...
Good program designers rarely NEED singletons -- even when they
tend towards object-oriented rather than functional programming.
Kent Beck's superb "Test-Driven Development by example" book
(Addison-Wesley, highly recommended to everybody!) has this to
say on the subject, as part of an excellent though brief survey
of useful design patterns:
"""
Singleton
How do you provide global variables in languages without global variables?
Don't. Your program will thank you for taking the time to think about
design instead.
"""
This is ALL that Kent's book says on the subject -- and, really, it
SHOULD be all that NEEDS to be said.
The concept of a language that ENCOURAGES you to disregard Kent Beck's
advice, and use Singleton instead of "taking the time to think about
design", is truly appalling.
Alex
Bruno Desthuilliers
Easy : answer to any post from Brandon, singing 'Brandon is a troll, is
a troll, is a troll' !-)
Bruno
Phlip
> lists, however, who have switched from Python to Ruby, and
> I doubt that it was corporate pressure in any of their cases.
>
> If you're interested (which most of the posters here are not -
> I'm certainly not) you might check with them. I'm sure Phlip, for
> one, would be more than happy to say why he switched, and what
> made the difference.
>
> John Roth
Hi, JR!
I got paid to research in Python, for a while, and started using Ruby
as a hobby project on the side - http://flea.sf.net
Python blocks, collections, and indentation all suck, but so do C++
equivalents, and I still use the latter as a hobby language, too.
If you were to instrument my physical responses and typing rate while
coding using Python and Test Driven Development, and compare them to
my responses using Ruby, you'd get close to assessing the subjective
reason I ain't going back.
And I would be interested to see such a comparison between Ruby and
Smalltalk. I can't use the latter, but I suspect Ruby exceeds its
expressiveness, but without the weird syntax.
To reveal objective reasons would lead to tired old threads like this
one. I could never write a paragraph expressing why Ruby is better, or
why this is not a personal taste thing.
The /Programming Ruby/ book says, "Ruby stays out of your way". I know
Python tried to be like that too, but it left in so many little
irritations.
Finally, my TFUI book will use Ruby for its core samples, but
generally written as expressively as possible, so that Pythonics and
others can read it.
I consider this a great improvement over similar books that use that
abomination Java. The elegant simplicity of C++ and the blazing speed
of Smalltalk!
Jeremy Dillworth
(sorry, post got long too)
DISCLAIMER: I don't have time at work to read this entire thread.
DISCLAIMER 2: Something I might find totally compelling, someone else
might think is trivial, or even stupid, to each his own.
I've used Python for a couple of years at my job for many projects,
including CGI's, "glue" scripts, a CVS tool, and one or two GUI apps
to allow internal users to stop asking me to do things I was doing
for them with quick one-off shell-scripts.
I read the "Pick Axe" book. My one-sentence impression of Ruby
has been: "Prettier core language (a few significant warts have
been fixed as of 1.8), needs more stable libraries."
I find the "Prettier core language" compelling.
For example, say you want a static method:
In Python:
class A:
def static_meth(a, b):
return a + b
static_meth = staticmethod(static_meth)
I don't like that something has to be done at the end of the
method to make it static. It could be bad if it were done at
the end of the class, away from the method, someone might think
the omission of self was an error, correct it, and then you'll
have a problem.
In Ruby it's:
class A
def A.static_meth(a, b)
return a + b
end
end
Random observations:
I like that Ruby's interpreter enforces specific naming rules for
constants, globals, instance variables, etc. This shows in the
Ruby libraries. In Python's libraries classes might be upper or
lower case (lowercase denotes those implemented in C), Ruby has
had no reason to distinguish what classes are implemented in, since
they're all treated the same (ie you can inherit, and you always
could, in Python this is a recent improvement).
Ruby's licensing seems to be a mess. Some of the interpreter
source is LGPL, some is Artistic or GPL (letting you choose). Not
a problem in most cases, but I like Python's licensing much better.
Ruby's C API looks cleaner and more comprehensible to me. Though
Boost.Python looks like it wraps Python's C API just as cleanly...
I don't see any mature/stable GUI frameworks I like for Ruby. I
think they just started wxRuby. I don't like Fox Ruby's windows
look on Linux. Tk is kinda OK, but I think it was kind of silly
that they prefixed classes with a Tk, when Ruby supports
namespaces perfectly well via modules (maybe fixed in 1.8?). As for
Ruby GNOME/GTK, I don't trust GTK+ on windows (I want a GUI
toolkit that works on Windows, Linux, and Mac OS X if possible).
Ruby's not using whitespace to delimit blocks may help you
avert civil war at your shop depending on how people view the
white-space-as-syntax issue.
Ruby 1.8 has some nice improvements, but there are no books
explicitly on 1.8 yet, and I haven't seen any signs that any
are coming (yet).
Ruby's FTP library doesn't work with file-like objects (maybe
fixed in 1.8?), it works with file names... forcing you to
write to files on disk instead of perhaps dynamically generating
stuff you send to an FTP server.
Operator overloading syntax is nicer, I find:
class MyClass
def +(other)
# ...
end
end
easier on the eyes than:
class MyClass:
def __add__(self, other):
# ...
Ruby's blocks make using threading and forking pretty nice:
t = Thread.new do
# ... code to execute in another thread
end
Or
fork do
# ... fork and run this code
end
I like this better than (if memory serves):
import threading
class MyThread(threading.Thread):
def run(self):
# ... do stuff in a thread
And
import os
pid = os.fork()
if not pid:
# ... do stuff in fork here
sys.exit() # unless you want the child to carry on past the if...
I've been noticing a lot more Ruby web-sites lately. Either
I haven't been paying attention, or Ruby has gained some inertia.
Also, Ruby's collection methods are really a sight to behold.
Over a weekend, I wrote some scripts which chained together like
half a dozen method calls to manipulate a collection, and everything
worked the first time, like I expected. This happens in Python too,
but I think it happens slightly more in Ruby (maybe 90% of the time
compared to 80% w/Python).
I'm toying with the idea of writing a game engine. For this, I'm
almost certain to embed Ruby for AI scripting... since library
issues seem moot in an embedding case.
For prototyping and embedding in another app... and possibly for
"glue" scripts... Ruby would be my first choice. For large GUI
apps or maybe large web apps, I'm not convinced yet.
--- "Brandon J. Van Every" <vane...@3DProgrammer.com> wrote:
> I'm realizing I didn't frame my question well.
>
> What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
> up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
> COOL!!! ***MAN*** that would save me a buttload of work and make my life
> sooooo much easier!"
>
> As opposed to minor differences of this feature here, that feature there.
> Variations on style are of no interest to me. I'm coming at this from a C++
> background where even C# looks like an improvement. ;-) From 10,000 miles
> up, is there anything about Ruby that's a "big deal" compared to Python?
>
> One person mentioned Japanese documentation. I'm sure that's Totally Kewl
> to the Japanese....
>
> --
> Cheers, www.3DProgrammer.com
> Brandon Van Every Seattle, WA
>
> 20% of the world is real.
> 80% is gobbledygook we make up inside our own heads.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
Doug Tolton
<newsg...@jhrothjr.com> wrote:
>I've been on c.l.py for around two years. Your statement
>is rude and assumes things you have not bothered to check
>out.
>
>There is a very simple rule for dealing with trolls, which most
>usenet newbies learn sooner or later. If you think someone is
>trolling, simply ignore them. Don't answer their posts, don't
>comment on them, don't even give them the gratification of
>a reply that says: "plonk!" Just killfile them and quit wasteing
>bandwidth. You've got better things to do with your time than
>maintaining an interaction that you find aggrevating.
You're right, I did make an assumption that you were new to the group.
A lot of people who are new make posts just like you did. Saying we
shouldn't be too harsh on Brandon, after a while they realize maybe he
is just a troll.
Perhaps my post was a bit rude, I shouldn't have automatically assumed
you were new to this NG, although I am a bit baffled at hearing a long
time c.l.p reading calling Every anything but a troll. You have to
admit, that is atypical.
John Roth
The standard usenet definition of a troll is someone who posts on
a contentious (and usually off-topic) subject with the sole objective of
stiring up reactions. I've only seen two classes of reaction to his posts:
people who call him names, and people who respond to his question
in a reasonable, thoughtful, and factual manner.
That's not a troll. The questions may be ill-posed, they may not be
questions that are all that comfortable for the self-satisfied to deal
with, but questions of how Python stacks up against some other
language do go to the issue of how Python should evolve in
the future.
As I said in another subthread of this thread, there is a standard
usenet recommendation for dealing with people you think are
trolls. Simply don't respond. Don't send them any response
whatsoever. If their only purpose is to elicit responses, that
strategy won't satisfy them, and they'll eventually go away.
People are quite capable of making up their own minds about
whether or not someone is making a useful contribution to the
group, without a lot of other people running around screaming:
"The sky is falling, we've got a troll."
John Roth
Fredrik Lundh
> The standard usenet definition of a troll is someone who posts on
> a contentious (and usually off-topic) subject with the sole objective
> of stiring up reactions.
that's a very limited definition. I prefer this one:
"An internet troll is someone who fishes for people's confidence and,
once found, exploits it"
( from http://www.teamtechnology.co.uk/troll.htm )
</F>
Jarek Zgoda
>> I am not a clp regular (mostly a lurker), but I also wanna play. *please*
>>
>> ;-).
>>
> Easy : answer to any post from Brandon, singing 'Brandon is a troll, is
> a troll, is a troll' !-)
Ugh, I cann't... I cann't see his posts, I accidentally pressed 'k'
while reading some of his writings, than accidentally few times pressed
"Enter" followed by "y" key -- of course by accident...
--
Jarek Zgoda
Registered Linux User #-1
http://www.zgoda.biz/ JID:zg...@chrome.pl http://zgoda.jogger.pl/
Bruno Desthuilliers
> Bruno Desthuilliers <bdesth...@removeme.free.fr> pisze:
>
>
>>>I am not a clp regular (mostly a lurker), but I also wanna play. *please*
>>>
>>>;-).
>>>
>>
>>Easy : answer to any post from Brandon, singing 'Brandon is a troll, is
>>a troll, is a troll' !-)
>
>
> Ugh, I cann't... I cann't see his posts, I accidentally pressed 'k'
> while reading some of his writings, than accidentally few times pressed
> "Enter" followed by "y" key -- of course by accident...
>
>
Aahz
Doug Tolton <dto...@yahoo.com> wrote:
>
>Perhaps my post was a bit rude, I shouldn't have automatically assumed
>you were new to this NG, although I am a bit baffled at hearing a long
>time c.l.p reading calling Every anything but a troll. You have to
>admit, that is atypical.
I have been very careful to not label Brandon as a troll.
Nick Vargish
> I don't know of any newsreaders that can allow you to filter on the
> person(s) to whom the current post is responding
Gnus certainly can.
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?')
Andrew Dalke
> I have been very careful to not label Brandon as a troll.
As have I.
Andrew
da...@dalkescientific.com
James Kew
news:bhrh1b$29lum$1...@ID-203719.news.uni-berlin.de...
> Jeff Epler wrote:
> > PS I'd just like to state for the record that neither Python nor Ruby
> > have a totally compelling advantage compared to the following
> >
> > K&R C
>
> Even as one who hasn't converted to Python yet, that statement is clearly
> insane.
Not at all: there are many applications in which K&R C is a more appropriate
language than Python.
Compelling advantages, yes. But "totally" compelling, no: if that were the
case it'd be Python-or-not-at-all in all cases.
James
Jeffrey P Shell
> I'm realizing I didn't frame my question well.
>
> What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
> up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
> COOL!!! ***MAN*** that would save me a buttload of work and make my life
> sooooo much easier!"
>
> As opposed to minor differences of this feature here, that feature there.
> Variations on style are of no interest to me. I'm coming at this from a C++
> background where even C# looks like an improvement. ;-) From 10,000 miles
> up, is there anything about Ruby that's a "big deal" compared to Python?
>
> One person mentioned Japanese documentation. I'm sure that's Totally Kewl
> to the Japanese....
Negative points earned by using 'frickin' and 'kewl'.
But with an earnest answer to your question - I started evaluating
Ruby about two and a half years ago. For me at the time, the "big
deals" in comparison to Python were:
A unified class hierarchy.
==========================
Python 2.2 started addressing this issue. And it's not one that
absolutely needs to be solved. But it starts making things more
consistent, and we can finally extend core types such as lists and
dictionaries, and legally write new code in C that can be subclassed
in Python.
Ruby has a different concept of modules than Python. In Ruby, a
Module is usually a class-like object that is mixed in, allowing for
multiple inheritance type functionality in a single inheritance
system. What's nice is that Ruby offers some very nice common built
in modules that you can reuse in your own classes, such as
'Comparable' (offering overloads for comparison operators),
'Enumerable' (offering a lot of Python built-in functions as methods
for collections of objects - equivalents of map(), min(), max(),
etc...), and more.
A pure pure pure OO system is a nice dream, and this feature makes
Ruby closer in it's OO offerings to Smalltalk than to Python. But I
have to admit that I actually prefer Python's module/package based
system better (I'll address this further down).
getter/setter methods for object attribute access
=================================================
This is another feature offered by Python 2.2 and later, in new style
classes. A problem that plagued Zope for a while was one didn't know
if a certain common attribute would be an attribute, or a method -
foo.title versus foo.title(). Some objects want to compute their
title, or other attributes (ie - you may store a mailbox size
attribute as bytes, but present it as megabyte to make it easier to
view/edit - so why not compute?). Since Python 2.2 now offers this
feature, which is not a critical one (just one that's quite nice),
Ruby doesn't score too many points here any more either. But it was
something that I liked when first evaluating the language.
Static/Class methods
====================
Python 2.2 and later finally allow these as well. In a pure OO system
like Ruby and Java, static method are very important when offering
what would be module-level functions in Python. Basically, they're
methods defined in a class that don't operate on an instance
(typically the 'self' in Python).
Class Methods operate on a class object instead of an instance.
Between static and class methods, for example, you can define new
constructors and place them in the class itself (not possible in older
Python or old style classes). So what Ruby, Java, Objective-C, and
other languages can offer are things like::
MyString.initFromFile(somefile)
MyString.initFromURL(someurl)
which would generate a new 'MyString' instance based on the contents
of a file or URL. Python 2.2 has caught up on this feature as well.
As others have stated - it's certainly *prettier* to define these
types of methods in Ruby, but I imagine Python will improve in this
area as time goes by. It's just nice to have these features
available.
Generators
==========
Another cool feature that Ruby had that fascinated me when I looked at
it that Python 2.2 coincidentally picked up. This is the 'yield'
keyword, and it produces a lot of opportunities for lazily generating
data to be iterated through. Again - Python 2.2 and later have this
one, so it's a moot point now. But this was something that really
excited me about Ruby when I saw it.
'blocks'
========
blocks...closures...anonymous functions. Whatever you want to call
them, Ruby employs them throughout the language. These have been
discussed en masse in this thread, I'm sure. It's no longer a deal
breaker for me. For the most part, if a lambda or list comprehension
expression don't offer me enough, writing a real named Python function
is the better route to go, in my opinion.
You can do a lot with lamda: expressions, and many parts of the system
allow them (including the re module, where you can supply a function
that takes a regex match object as its argument and do some
calculations on it).
>>> import re
>>> flan = "I'm some flan & I'm < half off."
>>> nonword = re.compile('\W')
>>> quoted = nonword.sub(lambda m:'&#%s;' % ord(m.group(0)), flan)
>>> quoted
'I'm some flan & I'm < half off.'
Of course, for any detailed function, it's still better to write a
full one:
>>> def quoter(matchobj):
... """ look up values we know names for before using ord() """
... good_values = {
... ' ': ' ', '<': '<', '>': '>', '"': '"'
... }
... match = matchobj.group(0)
... return good_values.get(match, "&#%s;" % ord(match))
...
>>> nuquoted = nonword.sub(quoter, flan)
>>> print nuquoted
I'm some flan & I'm < half off.
In-Place versus Copy
====================
There's a long running Python situation where one wants a sorted list
in the middle of an expression, for the sake of the expression only.
Python only lets you do "foo.sort()" as a statement on its own. If
you use this in an expression, it evaluates to "None", not a sorted
list. Little battles over this show up on occasion in the Python
world and have since the beginning of time.
In Ruby, there's a difference between "foo.sort" and "foo.sort!"
(parenthesis aren't required on method calls in Ruby). Ruby can use
some punctuation in its method names, and the exclamation point is
often used to indicate that this method will change the current
object. "foo.sort!" in Ruby is equivalent to "foo.sort()" in Python
(assuming 'foo' is a list).
This isn't a huge dealbreaker in favor of Ruby. It's just nice. The
use of punctuation to differentiate between inplace operations and
i'll-return-a-new-modified-copy operations is a nice one. (Ruby also
can have method names end in '?', which is often used for boolean
methods. 'foo.isEmpty?' for example.)
Ruby Issues and Python Strengths
================================
Ruby has a lot more issues for me now, and Python has some really
strong features that differentiate it. Some of these features, in
fact, go almost unnoticed because they're so smooth and make so much
sense (see coming remarks about modules).
Ruby is still more closely related to Perl than it is to Python. Ruby
uses all of those shortcut expressions that I find terrible, like $_.
Ruby uses other punctuation marks to mark what different variables,
with name, $name, @name, and @@name all being different. While it's
nice to differentiate between local, global, instance, and class
variables, all of these extra punctuation 'shortcuts' get in the way
of readability. In fact, it looks like it's quite easy to write
unreadable code in Ruby. There are just lots of punctuation marks one
has to get used to, and while it's easy to get used to them, I think
it moves Ruby away from the "executable pseudocode" that most decent
Python code can be. You wind up with statements like ``%w{@names}``
or ``print if ($. == 1)``. dollar-dot? what's that? Fortunately,
Python's general "explicit is better than implicit" design means I
never have to know.
Ruby still has too much shell-script nature inside of it. One built
in Ruby expression type is command expansion, or `foo`, where foo is a
shell command. (You can also use %x, as in %x{echo "Hello There"}).
Putting `uname -v` in your code will execute the Unix 'uname' command.
The exit status of the command is in the cheerful global variable $?.
As a result, I wonder how well Ruby works as an embedded language.
Python and its sibling Jython have been embedded in a variety of
systems to allow programmability. Some examples of this include 3D
environments (I think 'Caligari Truespace' is one of these), UML
tools, and more. In such systems, you don't want shell commands to be
run. Yet Ruby has them as first class expressions. Python places
operating system interaction into the flexible 'os' and 'os.path'
modules, and there are the newer 'popenN' modules as well for running
other processes from Python and getting the results back in. But -
it's a very key feature of Python that it is not bound strongly to the
Unix shell in any way. I don't know how much the `command` feature of
Ruby is used, but it's still troubling (to me) that it is a first
class expression.
Python has modules. I love this fact about it. It got even better
when multi-level packages were added as a core feature to the system.
I don't know why, but using ``import package.module`` or ``from
package.module import Class`` makes me so much happier than the
alternatives I see in Ruby, Perl, and PHP. But Python modules and
packages just add a nicer element to the language, and I believe that
Modula 2 and/or 3 was one of the linguistic influences on Python.
Ruby has two statements, and they just bother me. They seem to be
nowhere nearly as clean as Python modules (or even Java packages):
'load' and 'require'. And they seem to behave slightly differently.
load "filename.rb" "includes the name Ruby source file every time the
method is executed". I wonder if that's a full path expression, like
if you could do ``load "mypackage/file.rb"``, and if that expression
would fail on Windows or the classic Mac OS (or any other operating
system that uses a different path separator than Unix). Python
Modules are free of that.
require "filename" seems not to require the '.rb' extension, and seems
closer to Python's imports, but I don't think it puts anything into a
special namespace. With Python, you have to explicitly load blindly
into your namespace with the "from foo import *" syntax. But it looks
like if you do a ``require 'tk'`` command in Ruby, you're doing the
equivalent of "from tk import *".
Ruby has modules, but in a completely different sense than Python.
Modules are namespaces defined within files, which can also be used as
mix-ins to classes. While Python makes all subelement traversal use
the '.' syntax (package.module.Class, instance.someMethod, etc), Ruby,
adds more punctuation to get into modules, using the :: syntax
(NameSpace::Example::CONST or NameSpace::Example.new). Man, the more
I write, the more I really appreciate the simplicity of Python. We
will do funny things with __underscores__, but even that's pretty
consistent.
Python also has the nice feature of compiling/caching modules, which
can speed things up. I don't know if Ruby re-evaluates all code every
time you start a Ruby program up, but I haven't really seen an
equivalent to Python's '.pyc' and '.pyo' (optimized, generated when
running with the -O option in Python) files.
Ruby does have some nice things going for it, and I think that people
looking for a good object oriented Perl would be happy with it.
Personally, I think that Python is more mature, has better design
influences (Modula and ABC instead of Perl and Smalltalk). A lot of
the extraordinary features of Ruby seem to have found their way into
recent Python versions. Python's built in OS abstraction layers (the
'os' module, etc) makes it easier to write multiplatform code (made
even easier by universal newline support in Python 2.3, which helps
deal with the "'\r', '\n', or '\r\n'?" situation). Python's explicit
nature makes following code a lot easier - it's *usually* pretty easy
to tell where a name is coming from, for instance. And it does all of
this without abusing the sunday comic curse word character set
{$@#:!}. Ruby also seems to have some other implicit behaviors,
like::
def mult(n, fact)
n * fact
end
the last statement in an expression is what's returned. You *can* use
a return statement. But it's nice that Python always requires it
(otherwise, you get 'None' as a result):
def mult(n, fact):
return n * fact
it's just a nice touch. It's especially nice when you have to go into
systems like Java and you have variables being used that take a while
to process - "where's this name coming from? Oh, it's somewhere
within the class, not local!". self.doThis() is much more
understandable than just doThis(), especially when you start to stack
up namespaces.
In summary - there's nothing totally compelling about Ruby over Python
for me, especially since Python 2.2 and 2.3 have come along and
answered my own petty grievances. There are some cool features and
aspects of Ruby, to be sure, but I'm pretty happy where I am.
And Python always equals = batteries included!
92.7 times out of 103.5, there's a module that shipped with the
distribution that will do something that you need to do. Time and
again, I hear stories of "I was just about to write a whole blablabla
module when it turns out that one was already there!"
--
J.Shell
smarter_than_you
Nick Vargish <nav+...@bandersnatch.org> wrote in message news:<m3ada4x...@tanelorn.bandersnatch.org>...
Nick Vargish
> The real question here is, why haven't we all but Brandon in OUR killfiles?
When there's a stinging insect flying around the room, I like to be
able to see it.
Also, his perspective is so different from mine, I find it useful to
be reminded that there are people like him out there. It's fascinating
the way he seems to think everything needs to be a zero-sum
interaction... I mean, _why_ does anyone in the open source world have
to eat anyone else's lunch? Why is market dominance supposed to be
important to pythonistas? It's just good to be reminded that some
people really think like this -- as weird as it might seem to me.
David M. Cook
smarter_than_you wrote:
> The real question here is, why haven't we all but Brandon in OUR killfiles?
Brandon's not very interesting (or only as interesting as the spectacle of
someone behaving badly usually is), but some of the replies are.
Dave Cook
Peter Hansen
[an excellent, lengthy article contrasting Python and Ruby]
Article saved permanently. This is the only good thing to
come out of this thread so far. Thanks Jeffrey!
-Peter
Shane Hathaway
I agree. It would have taken weeks for me to figure out all of that on
my own. Get that great article posted in your weblog.
I'll note that "foo.sort" vs. "foo.sort!" issue is a very big deal for
some people. Being able to reliably distinguish between mutating and
non-mutating operations creates opportunities for transparent
parallelization. If you have some time, check out Kenton "Temporal"
Varda's comment:
http://slashdot.org/comments.pl?sid=75478&cid=6749469
and the programming language he's working on:
http://www.evlan.org/concepts.php
Shane
David Garamond
> Ruby is still more closely related to Perl than it is to Python.
I think for many people, it all boils down to this. Whoever hates Perl
will find Python more interesting. Whoever loves Perl, or uses/has used
Perl, will find Ruby more welcoming.
I for one am a Perl programmer. I have tried to use Python as much as I
could for several months but just could not get as productive as I am in
Perl. Hell, I could not even put 'if ... else ...' on the same f*cking
line! :)
> Ruby
> uses all of those shortcut expressions that I find terrible, like $_.
Ruby _does_ try hard to be a better Perl. This includes providing $_ and
many other Perl stuffs. However, the more I use Ruby over time, the less
I use those.
What I like about Ruby is that, despite it brings many features from
Perl, it still manages to be pretty clean design-wise. The features are
often layered on top of the OO system (e.g: /.../ is a shortcut for
creating a Regexp object). And they are all optional to use. Surely one
is not forced to use it. But I understand that there are people who just
can't stand the fact that those features _exist_ in the language.
> Ruby uses other punctuation marks to mark what different variables,
> with name, $name, @name, and @@name all being different. While it's
> nice to differentiate between local, global, instance, and class
> variables, all of these extra punctuation 'shortcuts' get in the way
> of readability.
Ah, but this improves readability for me. Some people might also argue
that all those underscores in Python code reduces readability. And how
many threads are lost for people complaining about having to write
'self.foo' all the time? ;-)
> Ruby still has too much shell-script nature inside of it.
Yes. And I love it :)
> in Ruby expression type is command expansion, or `foo`, where foo is a
> shell command. (You can also use %x, as in %x{echo "Hello There"}).
> Putting `uname -v` in your code will execute the Unix 'uname' command.
> The exit status of the command is in the cheerful global variable $?.
> As a result, I wonder how well Ruby works as an embedded language.
Not very badly, I think. mod_ruby, eruby, pl-ruby, jruby, ... Though the
last one is nowhere near usable as Jython right now.
> (NameSpace::Example::CONST or NameSpace::Example.new). Man, the more
> I write, the more I really appreciate the simplicity of Python. We
> will do funny things with __underscores__, but even that's pretty
> consistent.
And what's not consistent about :: for namespace separator, $ for global
vars, @ for class vars, and so on?
> Python also has the nice feature of compiling/caching modules, which
> can speed things up. I don't know if Ruby re-evaluates all code every
> time you start a Ruby program up, but I haven't really seen an
> equivalent to Python's '.pyc' and '.pyo' (optimized, generated when
> running with the -O option in Python) files.
This is a purely implementation issue, not the issue with the language
itself. Currently Ruby does not have a VM yet, so it does not have
bytecode compilation. But it will in Ruby 2.0. The current
implementation of Ruby (Ruby 1.x) is admittedly not very fast, but it's
already much faster & efficient than Python for some things (like
creating and destroying objects/classes).
> Ruby does have some nice things going for it, and I think that people
> looking for a good object oriented Perl would be happy with it.
> Personally, I think that Python is more mature, has better design
> influences (Modula and ABC instead of Perl and Smalltalk).
Ruby is also largely influenced by LISP.
> def mult(n, fact)
> n * fact
> end
>
> the last statement in an expression is what's returned. You *can* use
> a return statement. But it's nice that Python always requires it
This is also one of the thing I hate in Python :)
--
dave
Graham Fawcett
>"Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message news:<bhr44h$2903b$1...@ID-203719.news.uni-berlin.de>...
>
>
>>I'm realizing I didn't frame my question well.
>>
>>What's ***TOTALLY COMPELLING*** about Ruby over Python? What makes you jump
>>up in your chair and scream "Wow! Ruby has *that*? That is SO FRICKIN'
>>COOL!!! ***MAN*** that would save me a buttload of work and make my life
>>sooooo much easier!"
>>
>>As opposed to minor differences of this feature here, that feature there.
>>Variations on style are of no interest to me. I'm coming at this from a C++
>>background where even C# looks like an improvement. ;-) From 10,000 miles
>>up, is there anything about Ruby that's a "big deal" compared to Python?
>>
>>One person mentioned Japanese documentation. I'm sure that's Totally Kewl
>>to the Japanese....
>>
>>
>
>Negative points earned by using 'frickin' and 'kewl'.
>
>But with an earnest answer to your question - I started evaluating
>Ruby about two and a half years ago. For me at the time, the "big
>deals" in comparison to Python were:
>
An excellent answer and a great read, Jeffrey. Thanks.
-- Graham
Peter Hansen
>
> > From: Peter Hansen [SMTP:pe...@engcorp.com]
> >
> > Jeffrey P Shell wrote:
> >
> > [an excellent, lengthy article contrasting Python and Ruby]
> >
> > Article saved permanently. This is the only good thing to
> > come out of this thread so far. Thanks Jeffrey!
>
> worth a read -
> <http://groups.google.com/groups?selm=mailman.1061308473.30061.python-list%40python.org>.
Yes, you're right! Missed that one in the noise...
-Peter
Andrew Dalke
> Ah, but this improves readability for me. Some people might also argue
> that all those underscores in Python code reduces readability. And how
> many threads are lost for people complaining about having to write
> 'self.foo' all the time? ;-)
What if you had your editor expand '@' into 'self.'? (Not something
I would do.)
And how many Ruby threads are lost for people complaining about
having to write 'end' <wink>.
> > As a result, I wonder how well Ruby works as an embedded language.
>
> Not very badly, I think. mod_ruby, eruby, pl-ruby, jruby, ... Though the
> last one is nowhere near usable as Jython right now.
When I looked at Ruby a few years ago, I had concerns about
how its thread system (a platform independent/non-native) system
would interact with, say, POSIX threads or with an in-proc COM
server. I never found out the answer for that.
I also had concerns with its non-ref-count based garbage collection
for C extensions, because the C/Fortran libraries I use most often
for chemistry only pass opaque integer tokens around, and not raw
pointers, so there's no way for Ruby to know when to dealloc
things or what the proper deallocation order would be.
> And what's not consistent about :: for namespace separator, $ for global
> vars, @ for class vars, and so on?
Python gets away with doing the :: and @ with just a name and
a period.
'x' is local or global
'x.y' is the 'y' thingy in 'x', and 'x' could be a module, a class,
or an instance
So the inconsistency, from a Python view, is that the "get something
from something else" is written in different ways depending on
the source of the data.
> The current
> implementation of Ruby (Ruby 1.x) is admittedly not very fast, but it's
> already much faster & efficient than Python for some things (like
> creating and destroying objects/classes).
How is that tested? I hear that new-style classes for Python are
faster than old ones. Still, I decided to test out object creation
on a machine which has an older version of Python and of Ruby
installed.
%python -V
Python 2.2.2
%ruby --version
ruby 1.6.5 (2001-09-08) [i386-freebsd4.4]
%
%cat t.py
class Qwerty:
def __init__(self, name):
self.name = name
for i in xrange(1000000):
Qwerty("shrdlu")
%cat t.rb
class Qwerty
def initialize(name)
@name = name
end
end
for i in 0...1000000
Qwerty.new("shrdlu")
end
%time python t.py
3.303u 0.000s 0:03.42 96.4% 774+1008k 0+0io 0pf+0w
%time ruby t.rb
3.466u 0.185s 0:04.25 85.6% 5+889k 0+0io 0pf+0w
%
I deliberately chose Python code known to be slow.
Here's the faster version
%cat t.py
class Qwerty:
def __init__(self, name):
self.name = name
def main():
for i in xrange(1000000):
Qwerty("shrdlu")
main()
%time python t.py
2.929u 0.000s 0:03.36 86.9% 773+1008k 0+0io 0pf+0w
%
Faster because 'i' is in local namespace (simple offset
lookup in the list of local variables) vs. global namespace
(dictionary lookup). Deliberately chosen because I don't
know if Ruby has similar differences.
Andrew
da...@dalkescientific.com
Simon Brunning
>
> Jeffrey P Shell wrote:
>
> [an excellent, lengthy article contrasting Python and Ruby]
>
> Article saved permanently. This is the only good thing to
> come out of this thread so far. Thanks Jeffrey!
Not quite true. Nearly, but not quite. Jeremy Dillworth's post is also
worth a read -
<http://groups.google.com/groups?selm=mailman.1061308473.30061.python-list%4
0python.org>.
Cheers,
Simon Brunning
--LongSig
-----------------------------------------------------------------------
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot
accept liability for statements made which are clearly the senders own.
Nils Kassube
Smalltalk, ie. you can have a "retry" statement in your exception
handling that allows you to "try again".
Roy Smith
Nils Kassube <ni...@kassube.de> wrote:
I suppose this is nice, but does it really give you anything you
couldn't get in a slightly different way by just enclosing the whole try
construct in a loop?
while 1:
try:
do stuff
break
except:
fix the problem
If "do stuff" throws an exception, the "fix the problem" code runs and
then you try "do stuff" again. It even suffers from the same potential
infinite loop problem the Ruby version has :-)
Nils Kassube
> I suppose this is nice, but does it really give you anything you
> couldn't get in a slightly different way by just enclosing the whole try
> construct in a loop?
You are correct. The exception handling in Python is as powerful as in
Ruby. However, Ruby's way seems more beautiful to me. Another example:
in Python you have to nest multiple try/except statements, in Ruby you
can have multiple rescue blocks. It just looks better. (For my eyes.)
Christos TZOTZIOY
<newsg...@jhrothjr.com> might have written:
>All of the Ruby collections implement a .each method, which is essentially
>a version of the Visitor pattern. If I want to do something to every element
>in a list or a dict (or any kind of collection,) all I have to do is say
>something
>like (using Python syntax):
>
>collectObj.each(<method name>)
You can do similar things in Python, just wrap your collection in a
class. Check this module:
http://www.sil-tec.gr/~tzot/python/predicates.py
See the test cases after the line
if __name__ == "main":
Does this work for you? Esp. the do method.
PS I don't believe that the my final test labeled "Tricky" works, but
RSN I'm going to work on it :)
--
TZOTZIOY, I speak England very best,
Microsoft Security Alert: the Matrix began as open source.
Christos TZOTZIOY
Every" <vane...@3DProgrammer.com> might have written:
>Istvan Albert wrote:
>> Erik Max Francis wrote:
>>
>>>> What's ***TOTALLY COMPELLING*** about Ruby over Python?
>>>
>>> comp.lang.ruby doesn't have Brandon Van Every.
>
>Erik has been in my killfile forever, from other newsgroups. I even had to
>put him back in after letting him out. I thought a year would have been
>enough, but apparently not.
>
>> LOL
>>
>> Istvan.
>
>So, you're guilty by association. Goodbye!
Brandon,
I have no reason to call you names, and I won't bother pretending to be
a practical psychologist laying out my opinion about your social
interoperability; however, I will give your sense of humour a test :)
You have reported that you once in a while lose your killfile[1] because
of newsreader changes, "OS" (quotes intended to humour MS Windows)
reinstallations etc. A way to do comparisons between two languages is
to test them on practical matters. So, based on that periodical loss of
killfile, and on your keen-ness of informing your "victimfiles", I have
an idea for you.
Write a program in Python and Ruby that reproduces anytime your killfile
by googling your posts and selecting those containing a combination of
the words "killfile", "killfiling", "goodbye" and possibly "plonk!"
(don't know if you use that one); these are replies to people you
killfiled.
In the process, taste the languages. Request for support in the groups
(disabling temporarily your newly recreated killfile :). Join the
communities. Share the experience. Answer yourself your own questions
--and CC the groups in that answer!
I can't talk for Ruby, but I have lived the above for Python (and for a
long time just by lurking in the group; we're different in that, but I
don't imply I'm better than you). Ruby sounds interesting, but Python
has my heart (yes, geeks fall in love with computer languages, just like
with any other human product for which a lot of craftsmanship has been
invested).
Now, after all the sweet talk, I'll show you my true teeth (I'm a faulty
lying human sun of a beach after all) and tell you: "Stop believing
you're a leader and a lone wolf; there can't be two of us" :)
Cheer up, man. If people disappoint you, don't shut them off your
world; try charming them, for a change.
[1] It was you who reminded me the word "killfile"; I really had
forgotten about it and *plonk* etc, because c.l.py (ok, and a.h.bou)
have been the only ng's I invest time in lately...
...and PS: <me looking at the director>: "was that OK? or did I sound
too hippy? perhaps we should lose the San Francisco background and,
people, somebody stop the Ten Years track, OK??!"
Christos TZOTZIOY
>Ten Years track
and I meant Ten Years AFTER.
Christos TZOTZIOY
<bdesth...@removeme.free.fr> might have written:
>Just imagine what will happen when every
>clp regulars will be in Brandon's kill file...
"Where is everybody?"
Christos TZOTZIOY
topposted:
>The real question here is, why haven't we all but Brandon in OUR killfiles?
c.l.py and killfiles don't match.
Thankfully, the worst killfiling group I have frequented was
comp.databases.ms-access, a more-or-less friendly but more aloof group
than c.l.py.
Christos TZOTZIOY
<a...@dynacap.com> might have written:
>Bottom line is that people that uses Python have a better sex life than
>those that use other languages.
OK, who added viagra.py in the standard library? :)