What's better about Ruby than Python?

[Alex Martelli]

Re: What's better about Ruby than Python?

Heiko Wundram wrote:
...[color=blue]
> class X:
> def test(*args):
> print args
>
> X.test() # 1
> x = X()
> x.test() # 2
> X.test(x) # 3
>
> Run this, and for the first call you will get an empty tuple, while for[/color]

Wrong:
[color=blue][color=green][color=darkred]
>>> class X:[/color][/color][/color]
.... def test(*args): print args
....[color=blue][color=green][color=darkred]
>>> X.test()[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unbound method test() must be called with X instance as first
argument (got nothing instead)[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

X.test is not a function -- it's an unbound method; to call it, you
MUST therefore pass it at least one argument, and the first argument
you pass to it must be an isntance of X (or of any subclass of X).
[color=blue]
> on the instance they are associated with. If you have a predeclared
> self, only calls 2 and 3 would work, if the self parameter is just
> another parameter for the function, I can miraculously call the function
> just like it is (see call 1).[/color]

You seem to be wrongly assuming that "call 1" works, without having
tested it -- in fact, it fails in any version of Python. Therefore,
the "fact" that it works, being not a fact, cannot serve to support
"having no predeclared self" (nor any other thesis).

As for me, I have no special issue with "having to specify self" for
functions I intend to use as bound or unbound methods; otherwise I
would no doubt have to specify what functions are meant as methods
in other ways, such as e.g.

def [method] test(what, ever):
...

and since that is actually more verbose than the current:

def test(self, what, ever):
...

I see absolutely no good reason to have special ad hoc rules, make
"self" a reserved word, etc, etc. Python's choices are very simple
and work well together (for the common case of defining methods
that DO have a 'self' -- classmethod and staticmethod are currently
a bit unwieldy syntactically, but I do hope that some variation on
the often-proposed "def with modifiers" syntax, such as

def [classmethod] test(what, ever):
...

or

def test(what, ever) [classmethod]:
...

will make it past the BDFL filters in time for Python 2.4:-).


Alex

[Alex Martelli]

Re: What's better about Ruby than Python?

Asun Friere wrote:
...[color=blue]
> Ah yes, back to substance. I forgot to mention that Ruby ranges seem
> much more intuitive than Python slicing. But I think the confusion,[/color]

Having both a..b AND a...b -- one indicating a half-open range, another
indicating a closed range -- "more intuitive"? You gotta be kidding...
[color=blue]
> to the extent that confusion does exist, is because Python has one
> foot in the C-like 'n-1 indexed array' camp (in relation to ordinary
> indexing of elements), and one in the '0 is not an ordinal, but a
> point of origin,' camp (in relation to splitting). :ducks.[/color]

Python's firmly in the "always half-open" field (pioneered in print,
to the best of my knowledge, in A. Koenig's "C Traps and Pitfalls",
and -- no doubt partly thanks to Koenig's influence -- pervasive in
the C++ standard library too). Not sure where _splitting_ enters
the picture -- you mean, e.g., 'a few words'.split()? What's THAT
gotta do with intervals, or slices?


Alex

[Alex Martelli]

Re: What's better about Ruby than Python?

Alexander Schmolck wrote:
...[color=blue]
> To recap: usually, if I change a class I'd like all pre-existing instances
> to become updated (Let's say you develop your program with a running[/color]

If you CHANGE a class (mutate a class object), that does indeed happen.

You seem to have some deep level of confusion between "changing an
object" and "rebinding a name (that happened to be previously bound
to a certain object) so it's now bound to a different object".

Rebinding a name *NEVER* has any effect whatsoever on the object that
might have, by happenstance, previously bound to that name (except that,
when _all_ references to an object disappear, Python is free to make
that object disappear whenever that's convenient -- but that doesn't
apply here, since if a class object has instances it also has references
to it, one per instance).

This rule is universal in Python and makes it trivially simple to
understand what will happen in any given occasion -- just as long
as you take the minimal amount of trouble to understand the concepts
of names, objects, binding (and rebinding) and mutation. If a language
has no such clear universal rule, you're likely to meet with either
deep, complex trouble, or serious limitations with first-classness
of several kinds of objects. In Python everything is first-class,
and yet there is no substantial confusion at all.

Repeat with me: rebinding a name has just about NOTHING to do with
mutating an object. These are VERY different concepts. Until you
grasp them, you won't be a very effective programmer.
[color=blue]
> python session; you notice a mistake in a method-definition but don't want
> to start over from scratch; you just want to update the class definition
> and have this update percolate to all the currently existing instances.[/color]

I assume that by "update the class definition" you mean that you want
*necessarily* to use some:

class X: ...

statement that defines a NEW class object (which may happen to have
the same name as an existing class object -- quite irrelevant, of
course). OK, then, so arrange (easily done with some function or
editing macro, if you have a decent editor / IDE) to do the following:

oldX = X # save the existing classobject under a new temporary name

class X: ... # define a completely new and unrelated classobject

oldX.__dict__.c lear()
oldX.__bases__ = X,

# in case you also want to change the old class's name, you might:
oldX.__name__ = X.__name__ # so you're not constrained in this sense

# optionally, you can now remove the temporary name
del oldX

There. What's so hard about this? How does this fail to meet your
desiderata? Wouldn't it have been easier to ask, in the first place,
"I would like to obtain this effect, is there a Python way" (being
a BIT more precise in describing "this effect", of course!-), rather
than whining about "Python can't do this" and complaining of this as
being "unreasonab le"?

[color=blue]
> AFAIK doing this in a general and painfree fashion is pretty much
> impossible in python (you have to first track down all instances -- not an[/color]

I personally wouldn't dream of doing this kind of programming in production
level code (and I'd have a serious talk with any colleague doing it -- or
changing __class__ in most cases, etc). But depending on one's development
style and usage it may perhaps be helpful. If I did that often, of course,
I would ensure that the simple function:

def updateClass(old Class, newClass):
oldClass.__dict __.clear()
oldClass.__base s__ = newClass,
oldClass.__name __ = newClass.__name __

was automatically loaded at entry in the interactive environment (see e.g.
the PYTHONSTARTUP environment variable for doing this in the usual text-mode
interactive interpreter).
[color=blue]
> I think this sucks big time, because it greatly devalues the interactive
> programming experience for certain tasks, IMHO, but maybe I'm just missing
> something since typically nobody complains.[/color]

I don't think the fact that nobody complains is strongly connected to the
fact that most Python users grasp the possibility of updating a class by
modyfying its __dict__ etc; indeed, one great thing about Python is that
most users typically tend to SIMPLICITY rather than "cleverness " -- if they
wanted to modify a class X's method Y they'd code it as a function F and
then simply do X.Y=F -- extremely simple, rapid, effective, and no need
to much with redoing the whole 'class' statement (a concept I personally
find quite terrible). Rarely does one want to modify an existing class
object any more 'deeply' than by just redoing a method or two, which this
utterly simple assignment entirely solves -- therefore, no real problem.

If your style of interactive programming is so radically different from
that of most other Pythonistas, though, no problem -- as you see, if you
put some effort in understanding how things work (particularly the
difference between *MODIFYING AN OBJECT* and *REBINDING A NAME*), Python
supports you with power and simplicity in MOST (*NOT* all) metaprogramming
endeavours.

If you DO want total untrammeled interactive and dynamic metaprogramming
power, though, *THEN* that's an area in which Ruby might support you
even better -- for example, this Python approach would *NOT* work if
oldClass was for example str (the built-in string class -- you CANNOT
modify ITS behavior). Personally, for application programming, I much
prefer clear and well-defined boundaries about what can and what just
CANNOT change. But if you want EVERYTHING to be subject to change, then
perhaps Ruby is exactly what you want. Good luck with keeping track
of what names are just names (and can be freely re-bound to different
objects) and which ones aren't (and are more solidly attacked to the
underlying objects than one would expect...).


Alex

[Alex Martelli]

Re: What's better about Ruby than Python?

Doug Tolton wrote:
...[color=blue]
> abstractions and better programmer productivity. Why not add Macro's
> allowing those of us who know how to use them and like them to use
> them. If you hate macros, or you think they are too slow, just don't
> use them.[/color]

"No programmer is an island"! It's not sufficient that *I* do not use
macros -- I must also somehow ensure that none of my colleagues does,
none of my clients which I consult for, nobody who posts code asking
for my help to c.l.py or python-help -- how can I possibly ensure all
of this except by ensuring that macros ARE NOT IN PYTHON?! "Slow" has
nothing to do with it: I just don't want to find myself trying to debug
or provide help on a language which I cannot possibly know because it
depends on what macros somebody's defined somewhere out of sight. Not
to mention that I'd have to let somebody else write the second edition
of the Nutshell -- if Python had macros, I would have to cover them in
"Python in a Nutshell".

They don't change the underlying language, they just add a[color=blue]
> more useful abstaction capability into the language.[/color]

They may not change the "underlying " language but they sure allow anybody
to change the language that is actually IN USE. That is definitely NOT
what I want in a language for writing production-level applications.

I dearly hope that, if and when somebody gives in to the urge of adding
macros to Python, they will have the decency to FORK it, and use an
easily distinguishable name for the forked Python-with-macros language,
say "Monty". This way I can keep editing future editions of "Python in
a Nutshell" and let somebody else write "Monty in a Nutshell" without
any qualms -- and I can keep programming applications in Python, helping
people with Python, consulting about Python, and let somebody else worry
about the "useful abstaction" fragmentation of "Monty". If that "useful
abstaction" enters the Python mainstream instead, I guess the forking
can only be the last-ditch refuge for those of us (often ones who've seen
powerful macros work in practice to fragment language communities and
end up with "every programmer a different language"... do NOT assume that
fear and loathing for powerful macro systems comes from LACK of experience
with them, see also the Laura Creighton posts whose URLs have already
been posted on this thread...) who'd much rather NOT have them. But maybe
moving over to Ruby might be less painful than such a fork (assuming THAT
language can forever stay free of powerful macro systems, of course).

I have nothing against macros *IN GENERAL*. I just don't want them *in
my general-purpose language of choice for the purpose of application
programming*: they add NOWHERE NEAR ENOUGH PRODUCTIVITY, in application
programming, to even START making up for the risks of "divergence " of
dialects between individuals, groups, and firms. If I was focused on
some other field than application programming, such as experimental
explorations, tinkering, framework-writing, etc, I might well feel quite
otherwise. But application programming is where the big, gaping hole
of demand in this world is -- it's the need Python is most perfectly
suited to fulfil -- and I think it's the strength it should keep focus
and iinvestments on.


Alex

[John J. Lee]

Re: What's better about Ruby than Python?

"Brandon J. Van Every" <vanevery@3DPro grammer.com> writes:
[color=blue][color=green]
> > Well, art is art, isn't it? Still, on the other hand, water is water!
> > And east is east and west is west and if you take cranberries and stew
> > them like applesauce they taste much more like prunes than rhubarb
> > does.
> >
> > Groucho Marx.[/color]
>
> I almost got it.[/color]

Not meant to be 'got'. Your mention of 'runon' sentences just
reminded me of it, and that was good enough excuse for me :-)


John

[Alex Martelli]

Re: What's better about Ruby than Python?

John J. Lee wrote:
...[color=blue]
> I'd never noticed that. Greg Ewing has pointed out a similar trivial
> wart: brackets and backslashes to get multiple-line statements are
> superfluous in Python -- you could just as well have had:
>
> for thing in things:
> some_incredibly _long_name_so_t hat_i_can_reach _the_end_of_thi s =
> line
>
> where the indentation of 'line' indicates line continuation.[/color]

I see somebody else already indicated why this isn't so.

[color=blue]
> The differences between Ruby and Python are, in the end, about as far
> from significant as it's possible to be (near as I can tell from[/color]

Yes, they're extremely similar languages.
[color=blue][color=green]
>> Ruby does have some advantages in elementary semantics -- for
>> example, the removal of Python's "lists vs tuples" exceedingly
>> subtle distinction.[/color]
>
> You may be right there. Guido's comment that tuples are mostly
> mini-objects did clarify this for me, though.[/color]

Oh, I'm quite "clear" on the issue, I just think it's a design
error to have tuples in Python, that's all (rather than just an
immutable version of lists for hashing purposes, for example).

[color=blue][color=green]
>> But mostly the score (as I keep it, with
>> simplicity a big plus and subtle, clever distinctions a notable
>> minus) is against Ruby (e.g., having both closed and half-open[/color]
>
> In the end, though, don't you agree that any such judgement is, from
> the pragmatic point of view, pointless once you realise how similar
> the two languages are?[/color]

No, I entirely disagree. I do have to choose one language or the
other for each given project; I do have to choose which language
to recommend to somebody wanting to learn a new one; etc, etc.
[color=blue]
> If somebody sneakily switched Python and Ruby
> in the middle of the night (so that suddenly many more people use
> Ruby, and much more code was written in Ruby than in Python), you'd
> stick with Ruby, wouldn't you?[/color]

Non-linguistic considerations such as the above may also have their
weight, in some case. But they're not huge ones, either.
[color=blue][color=green]
>> about undistinguishab le to anybody and interchangeable in any[/color]
>
> *in*distinguish able. Ha! I found a bug.[/color]

You're wrong, see e.g. http://dict.die.net/undistinguishable/ :
the spellings with the initial "u" and "i" are just synonyms.

[color=blue][color=green]
>> If I had to use Ruby for such a large application, I would
>> try to rely on coding-style restrictions, lots of tests (to
>> be rerun whenever ANYTHING changes -- even what should be
>> totally unrelated...), and the like, to prohibit use of this
>> language feature. But NOT having the feature in the first
>> place is even better, in my opinion -- just as Python itself[/color]
> [...]
>
> I mostly agree, but I think you could be accused of spreading FUD
> about this. Does anybody *really* choose to alter string-comparison
> semantics under everybody else's nose in Ruby?? That would be like[/color]

As I see others indicated in responses to you, this is highlighted
and recommended in introductory texts. So why shouldn't many users
apply such "big guns"?
[color=blue]
> doing
>
> import some_module
>
> def evil_replacemen t_function(): return blah()
>
> some_module.imp ortant_function = evil_replacemen t_function
>
>
> in Python, wouldn't it?[/color]

And hopefully this WILL be deprecated in 2.4 (pity that there just
was not enough time and consensus to do it in 2.3, but the BDFL
really liked the concept). Still, the Python usage you mention
is LESS problematic, in that the influence on some_module is
very explicit -- while altering Object (or whatever) in Ruby is
a way to IMPLICITLY AND HIDDENLY influence EVERY other module.
It's a *covert* channel -- a disaster, in large applications.

Thus, the direct Python equivalent might be

import __builtins__
__builtins__.le n = someotherfuncti on

and THAT usage is very specifically warned against e.g. in
"Python in a Nutshell" -- you CAN do it but SHOULDN'T (again, one
can hope to eventually see it "officially " deprecated...!) .


Alex

[Roy Smith]

Re: What's better about Ruby than Python?

Alex Martelli <aleaxit@yahoo. com> wrote:[color=blue]
> They may not change the "underlying " language but they sure allow anybody
> to change the language that is actually IN USE. That is definitely NOT
> what I want in a language for writing production-level applications.[/color]

Here's a real-life example of how macros change the language. Some C++
code that I'm working with now, has a debug macro that is used like this:

DEBUG (cout << "I'm a debug statement\n";)

Note the semicolon inside the closing paren.

I write in emacs, and depend heavily on its knowlege of C++ syntax to
auto-indent. It's not just a convenience, it's an interactive typo
prevention tool (if the code doesn't indent the way I expect, it's
probably because I messed up the punctuation). I'm personally not a big
fan of syntax coloring, but many people are, for much the same reason.

The problem is, emacs doesn't know what to do with the code above. It
doesn't see a trailing semicolon, so (IIRC), it tries to indent the next
line another step, as if it were a continuation of the same statement.
What a pain. Eventually, I figured out I could "solve" the problem by
adding an extra semicolon at the end:

DEBUG (cout << "I'm a debug statement\n";);

It looks ugly, but at least it indents correctly.

Before you start ranting about emacs, note that there are lots of
language-aware editors (and other tools), all of which would suffer from
the same problem. The macro has essentially invented new syntax, which
the tool can't possibly know about.

[A.M. Kuchling]

Re: What's better about Ruby than Python?

On Mon, 18 Aug 2003 15:17:03 -0700,
Erik Max Francis <max@alcyone.co m> wrote:[color=blue]
> Roy Smith wrote:
> My view of this is that if you really want to do this, you're better off
> inventing a separate language -- however similar to Python -- and using
> a processor to turn that language into real Python, which can then be
> interpreted. In an interpreted language, especially one as dynamic as[/color]

The problem is that writing such a processor is pretty messy. I've just
been writing a translator for a supersmall subset of Python ('while', 'for',
assignment, and that's it). While it was possible to do it with the
Lib/compiler/ package, the code for parsing the subset and generating Python
code from it is 12 screens long, ~300 lines of code. It's also difficult to
change the keyword set; for now I'm simply disallowing variables named 'in',
for example.

Macros would generally be a compact way of doing this, though that
compactness would have a cost (just like regular expressions are concise
but not very readable). Perhaps the solution isn't macros, but some kind of
Python-like-language parsing toolkit that's more easily customizable
than the compiler package is.

--amk

[Peter van Merkerk]

Re: Brandon's abrasive style (was Re: What's better about Rubythan Python?)

> > - GUI and tools support can end up being more important than
language[color=blue][color=green]
> > niceties.[/color]
>
> Absolutely. This is one of the main reasons languages like Ruby and
> Haskell aren't in my toolkit. wxRuby appears to be in the pre-alpha
> stages and wxHaskell doesn't exist at all.[/color]

http://wxhaskell.sourceforge.net

[John Roth]

Re: What's better about Ruby than Python?


"Heiko Wundram" <heikowu@ceosg. de> wrote in message
news:mailman.10 61271511.20407. python-list@python.org ...[color=blue]
> On Mon, 2003-08-18 at 19:40, John Roth wrote:[color=green]
> > This is why Ruby's solution is superior: "self" is a reserved word,
> > and so is the special character shortcut. There is no question as
> > to what is meant. It eliminates essentially futile arguements in the
> > same way that Python's indentation eliminates arguements about
> > the proper placement of braces.[/color]
>
> I think you're not getting the main point in a difference between Ruby
> and Python here, and why it makes (IMHO) no sense to have a default self
> in a function:
>
> class X:
> def test(*args):
> print args
>
> X.test() # 1
> x = X()
> x.test() # 2
> X.test(x) # 3
>
> Run this, and for the first call you will get an empty tuple, while for
> the second call, you will get a tuple with the first parameter set to a
> class instance of X, and for the third call the same as for the second
> call. Remember about method binding (method/function difference), and
> the like.
>
> I want to have class-functions which can be callable either as a
> function of the class (doing something on input-data), or work directly
> on the instance they are associated with. If you have a predeclared
> self, only calls 2 and 3 would work, if the self parameter is just
> another parameter for the function, I can miraculously call the function
> just like it is (see call 1).
>
> I find it reasonable enough to have a feature like this to not complain
> about having to specify self as the first parameter, always.[/color]

If every function/method has access to an instance/class whatever,
then there is clearly no reason to waste keystrokes specifying it on
the function/method header. I would think this would be obvious.

John Roth[color=blue]
>
> Heiko.
>
>[/color]

[Matthias]

Re: What's better about Ruby than Python?

Roy Smith wrote:[color=blue]
> DEBUG (cout << "I'm a debug statement\n";);
>
> It looks ugly, but at least it indents correctly.[/color]

Why not simply

DEBUG(cout << "I'm a debug statement\n");

This should work unless you DEBUG does something strange.

[Harry George]

Re: What's better about Ruby than Python?

Alexander Schmolck <a.schmolck@gmx .net> writes:
[color=blue]
> Harry George <harry.g.george @boeing.com> writes:[color=green]
> > In the Lisp world, you use the hundreds of macros in CL becuase they
> > *are* the language. But home-grown (or vendor supplied) macros are
> > basically a lockin mechanism. New syntax, new behavior to learn, and
> > very little improvement in readability or efficiency of expresison
> > (the commmon rationales for macros).[/color]
>
> How can you claim with a straight face that the sophisticated object, logic
> programming, constraint programming, lazy evaluation etc systems people have
> developed in scheme and CL over the years have brought "very little
> improvement in readability or efficiency"?
>[/color]

When I want logic programming I go to Prolog, and I bind to/from
prolog with python. If I want lazy evaluation, I do it in python (see
e.g., xoltar). My concern is based primarily on experience with the
ICAD language where massive use of macros provide lazy evaluation at
the expense of an utterlay different language. We are finding the
same KBE work can often be done cleaner and simpler in Python.

The issue is not "can I do it at all". Lisp is great for that. It is
rather "do I need a wholly new syntax".
[color=blue][color=green]
> > The python language is just fine as is.[/color]
>
> No it isn't. Like every other language I know python sucks in a variety of
> ways (only on the whole, much less so), but I don't claim I know how to fix
> this with a macro system. I'm just not sure I buy Alex's argument that an
> introduction of something equivalent in expressive power to say CL's macro
> system would immediately wreck the language.
>
> The trick with adding expressiveness is doing it in a manner that doesn't
> invite abuse. Python is doing pretty well in this department so far; I think
> it is easily more expressive than Java, C++ and Perl and still causes less
> headache (Perl comes closest, but at the price of causing even greater
> headache than C++, if that's possible).[/color]

That's the point: Lisp macros invite abuse. They are wonderfully
powerful and expressive. And they therefore support invention of new
worlds which must be learned by others. Python (so far) resists the
"creeping featurism", yet is still valuable in a very wide array of
situations.

To make an analogy with antural languages: English is relatively
successful not just through economic dominance but also through paring
away nuances of grammar. Yes, there are times and places where French
or Sanskrit or Morse code are more potent languages, but for a large
set of communications problems, English works quite well.

(If you are worried I'm a language chauvinist, see:
http://www.seanet.com/~hgg9140/languages/index.html )
[color=blue]
>[color=green]
> > If you really, really need something like a macro, consider a template body
> > which is filled in and exec'd or eval'd at run time.[/color]
>
> I've actually written a library where most of the code is generated like this
> (and it works fine, because only trivial code transformation are needed that
> can be easily accomodated by simple templating (no parsing/syntax tree
> manipulations necessary)).
>
> But show me how to write something like CL's series package that way (or
> better yet, something similar for transforming array and matrix manipulations
> from some reader-friendly representation into something efficient).
>[/color]

Why reimplement the series package? That is a good example of rampant
CL overkill. In Steele's CLTL2, it takes 33 pages to explain. It is
great for people who are in the language day in and day out, and can
therefore keep the whole shebang in their mental working set. For
anyone who has other committments (e.g., me and 30 other engineers I
work with), the nuances of series are too complex for practical use.
In code reviews we have to bring out CLTL2 whenever someone uses any
of the fancy macros. You can get the same functionality with python
"for" or "while" and a few idioms.

As for array and matrix manipulation, I want a good C-based library
with python binding (e.g,, gsl), at times helped by some syntactic
sugar (Numeric). What I don't need is a brand new language for matrix
manipulation (wasn't APL for that?). If you mean a human readable
treatment that can be converted to those libraries, I'd have to point
to MathML. If you mean the programming syntax itself looks like
vector math, I'd use Numeric overloads up to a point, but beyond that
people get confused and you (I at least) need explicitly named
functions anyway.
[color=blue]
>
> 'as[/color]

I'll concede that the macro issue is a personal taste sort of thing.
if you live inside a single mental world, you can afford to grow and
use fancy macros. If (like me) your day includes a dog's bvreakfast
of tasks, then the overhead is too great for the payoff.

--
harry.g.george@ boeing.com
6-6M31 Knowledge Management
Phone: (425) 342-5601

[Jacek Generowicz]

Re: What's better about Ruby than Python?

Roy Smith <roy@panix.co m> writes:
[color=blue]
> Here's a real-life example of how macros change the language. Some C++
> code that I'm working with now, has a debug macro that is used like this:
>
> DEBUG (cout << "I'm a debug statement\n";)[/color]
[color=blue]
> The problem is, emacs doesn't know what to do with the code above.[/color]

If you think that's a problem ... I have recently seen some code where
a DEBUG macro trampled all over an enum containing a DEBUG value. I'm
not too worried about Emacs not knowing what to do with the code, but
I get rather more upset when the compiler doesn't know what to do with
the code :-)

But this is all slightly off-topic. I don't think this part of the
thread is about C-style macros (which are fundamentally flawed and
useless <0.0001 wink>, and very boring), but Lisp-style macros, which
are are to C-style macros what Emacs is to cat.

[Jacek Generowicz]

Re: What's better about Ruby than Python?

Alex Martelli <aleaxit@yahoo. com> writes:
[color=blue]
> Python's firmly in the "always half-open" field (pioneered in print,
> to the best of my knowledge, in A. Koenig's "C Traps and Pitfalls",[/color]

I seem to recall seeing a scanned-in copy of a hand-written talk by
Dijkstra, on this.

[I suspect it predates Andrew's oeuvre ... but then probably doesn't
qualify on the "in print" requirement.]

Anyone know what I'm talking about ?

[John J. Lee]

Re: What's better about Ruby than Python?

Alex Martelli <aleaxit@yahoo. com> writes:
[color=blue]
> John J. Lee wrote:
> ...[color=green]
> > I'd never noticed that. Greg Ewing has pointed out a similar trivial
> > wart: brackets and backslashes to get multiple-line statements are
> > superfluous in Python -- you could just as well have had:
> >
> > for thing in things:
> > some_incredibly _long_name_so_t hat_i_can_reach _the_end_of_thi s =
> > line
> >
> > where the indentation of 'line' indicates line continuation.[/color]
>
> I see somebody else already indicated why this isn't so.[/color]

Andrew Dalke? I just read that, and didn't see any contradiction of
Greg's idea, just a discussion of it. Or did you just mean 'it isn't
a wart'?

[...][color=blue][color=green]
> > You may be right there. Guido's comment that tuples are mostly
> > mini-objects did clarify this for me, though.[/color]
>
> Oh, I'm quite "clear" on the issue,[/color]

Didn't mean to imply otherwise.

[...][color=blue][color=green]
> > In the end, though, don't you agree that any such judgement is, from
> > the pragmatic point of view, pointless once you realise how similar
> > the two languages are?[/color]
>
> No, I entirely disagree. I do have to choose one language or the
> other for each given project; I do have to choose which language
> to recommend to somebody wanting to learn a new one; etc, etc.[/color]

Yes. My criterion is then simply: "Which language is more popular?"
rather than "Which is marginally better?". Well, strictly, it's
"which has better free library code, ng support, etc.", but that's
reasonably well-correlated with popularity (unless you're Japanese, in
this case, perhaps).

[...][color=blue]
> Non-linguistic considerations such as the above may also have their
> weight, in some case. But they're not huge ones, either.[/color]

I had the impression that the amount of good library code out there
for Ruby was small, which I view as more important than the language
features which have been discussed here (with the possible exception
of this retroactive builtin class modification business, if people do
use it -- still seems incredible, but from Andrew's post it seems
you're right to be repulsed by this). But maybe the Python <--> Ruby
bridge is good enough that that (library code) isn't such a problem.

[color=blue][color=green][color=darkred]
> >> about undistinguishab le to anybody and interchangeable in any[/color]
> >
> > *in*distinguish able. Ha! I found a bug.[/color]
>
> You're wrong, see e.g. http://dict.die.net/undistinguishable/ :
> the spellings with the initial "u" and "i" are just synonyms.[/color]

:-( Google reports > factor of 10 fewer hits for it than 'in', and
it's not in my little dictionary. I wonder if it's in the OED...

[...][color=blue][color=green]
> > I mostly agree, but I think you could be accused of spreading FUD
> > about this. Does anybody *really* choose to alter string-comparison
> > semantics under everybody else's nose in Ruby?? That would be like[/color]
>
> As I see others indicated in responses to you, this is highlighted
> and recommended in introductory texts. So why shouldn't many users
> apply such "big guns"?[/color]
[...]

That is indeed strange.


John