What's better about Ruby than Python?

[Harry George]

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"?

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".

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).

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 )

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).

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.

'as

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.

 

[Matthias]

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

It looks ugly, but at least it indents correctly.

Why not simply

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

This should work unless you DEBUG does something strange.

 

[Jacek Generowicz]

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"

The problem is, emacs doesn't know what to do with the code above.

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]

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",

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]

John J. Lee wrote:
...

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

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'?

[...]

Oh, I'm quite "clear" on the issue,

Didn't mean to imply otherwise.

[...]

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.

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).

[...]

Non-linguistic considerations such as the above may also have their
weight, in some case. But they're not huge ones, either.

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.

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

:-( 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...

[...]

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"?

[...]

That is indeed strange.


John

 

[Cliff Wells]

http://wxhaskell.sourceforge.net

Feh. I should have known =) It seems nearly every language is
gathering a wx interface. What's next, wxC#?

Regards,

 

[Anand Pillai]

The anaconda was much bigger, louder and enormous than anything
the snakes ever experienced in their humble but peaceful abode.

The anaconda saw his chance to make it big in the snake community.
It began hissing violently in all directions.

....And the snakes went back to their burrows leaving the
anaconda to regurgitate its undigested food...

Waiting for the hissing to die...

-Anand

I hate to use an Eep-ism, but it's time for people to evolve. "You sound
like a troll" is not that reasonable an assumption. Outside of politics
newsgroups, I've almost never seen actual trolls.

I've seen several, mostly on the Linux lists, but c.l.py hasn't been
immune (lumberjack, you there?).

I've seen plenty of
people insulting each other, totally unable to see the other person's point
of view. I've seen countless instances of Troll Hunting all over Usenet
that had nothing to do with me. In fact, it's clearly a popular newsgroup
sport! People are intellectually lazy, they don't have an ironclad
criterion for what is or isn't a troll. A troll is anything they don't
like. They don't use imagination or exercise benefit of the doubt when
controversial posts appear. They just enjoy naming things within a familiar
pigeonholeing system. It comforts them. They are so focused on controlling
group discourse, and not letting "the wrong kind of conversation" happen,
that they don't put much thought into what was said in the first place.

Have you ever considered that perhaps it is your own expectation of a
"Troll Hunt" that makes you see such a thing when there is at least a
remote chance you're looking for something that isn't there? In my two
years on c.l.py I've never seen any such thing nor heard anyone else
complain of such until now. If you give up the fantasy that people are
out to get you then perhaps you might see how your own actions
precipitated today's events. It's certainly true that people were quick
to label your thread on Python vs. Ruby as a troll. However I also
expect much of that was due the lingering effects of your prior thread
on Python vs C#.

As I see it, my detractors are enginerds with no appreciation for or skill
at marketing.

Quite probably true. Also most of them are probably proud of it. This
isn't a marketing group, it's a programming language discussion group.
I'd venture that with few exceptions most people here probably despise
marketing or at best find it irrelevant. That is why there is a
separate ng for discussion of such things. Most people here don't want
to hear about it, even in the sense that it relates to Python.

Nor, probably, much awareness of Python marketing efforts.

But the ones that do have hopefully found the appropriate forum.

That's how I figure you can (1) blithely ignore my analysis of Reality On
The Ground, (2) merrily claim I'm a do-nothing. I've suggested you look at
the marketing-python archives several times, it's a comment I've peppered
here and there. Have you?

I browsed it and in fact considered responding to some of your claims
there, which I found to be baseless (or at least misguided), but as I am
one of the people who find marketing boring I didn't bother.

Actually, it says more about where I am in life. There was a time when I
never killfiled anybody. If I was rude, and we got into fights, we'd just
keep fighting. Often we'd kiss and make up. But sometimes, I'd get an
intractable, unforgiving, obsessive compulsive fixated asshole on my ass for
years. It drove me out of comp.games.development.* for a time, the
hierarchy I created. I got fed up with being told that I was a troll,
seeing as how I'd been Newsgroup Proponent. What the hell is that, the
ultimate trolling? I've never trolled in my life. Abrasive, argumentative,
violent, sure. Trolling, never.

Fair enough. But would you find it odd if you were to slip on over to
alt.culture.black and mention that you think affirmative action was a
mistake and people got riled up? That some of them would label you
racist? Of course not. In fact, if that were your position, you would
expect such a response and preemptively address that response before the
flamewar began. You should try the same thing with less volatile
topics. Instead of assuming that your point of view is obvious (it
isn't) or that people have read your posts in other groups (they
haven't), simply provide a supporting argument for such remarks. Trust
me, it goes a long way.

Anyways, a few years later I came back. I've been summarily killfiling
people ever since. It does wonders for my long-term interaction with people
and groups. I don't have to deal with the people I can't work with.

That actually doesn't sound confrontational. In fact, IIWAP, I'd
probably label it passive aggressive.

Personally I've never
killfiled anyone (not even the ruebot[!]) and to my knowledge, I've
yet to be
killfiled (although at times I'm a bit surprised at that, today being
one of those times).

It's really very simple. Your behavior is not the same as other people's
behavior. That's why we're still talking.

Why then, are you surprised when people choose to fight with you?

Why do you say I'm surprised? This is all very predictable to me. Seen at
this moment in time, you are a static type within this system. You just
happen to be a benevolent, workable type. You are the "Well, are you going
to killfile *me* too?" type.

I'm just the type who finds the entire process rather boring. I enjoy a
good argument (heated or otherwise) a bit more than the next guy.
However, I find irrational behavior a big yawn. I see no point in
investing a lot of work trying to make someone look foolish who is going
to do the job on his own anyway. I respect people who make their
knowledge and work available to others without belittling them. I
respect people who are able to articulate their arguments whether I
agree with them or not. In general, I'm willing to give people the
benefit of doubt which is why I've never killfiled anyone.

The kind of person who doesn't behave in a way
that I would killfile, and who doesn't quite understand how his behavior is
different from the people I do killfile. But, who probably will understand
by the time I get done explaining it.

Actually, what surprises me is that several of the people you killfiled
are some of the more reasonable people on the list. I'm a little

Have you seen Enter The Matrix? The scene with The Architect is very
profound. The Matrix demands Neo. Someone else observed, this stuff is all
about young males. That's no accident, it's a feature of our genetics. Our
genetics demand certain confrontations at a certain age. In our lives, we
obey certain Grand Strategies, even if we are sapient and exercising choice
over the details.


That's sorta true. This is really what I call a "posting binge," to avoid
other things I don't want to be doing.

So for entertainment value you stir up groups where people are trying to
help others get their jobs done? That might be a bit of a cheap shot,
as I doubt you consciously intended to initiate a wild flamewar, but
seriously, your binge took valuable time from people who others depend
on. When I post a question to c.l.py, it's usually because I've got
something I need done now and don't have a ton of time to tinker around
or RTFM.

I'm an intellectually violent
person, I like a good debating scrap. But I've got Rules Of Engagement
about what I think is appropriate, intellectually defensible debate.
"You're a troll!" instead of hearing someone else's opinion ain't it.

Ah, you've done the same, albeit in a different fashion. "You're a
troll" certainly doesn't constitute a grand argument. But your approach
is to selectively respond to arguments and sprinkle in the odd flamebait
(or, as you would label them: things people don't want to hear). This
is why I had you pegged (momentarily) as a clever troll. It appeared as
if you were using just enough reasonable debate to disguise the
unreasonable assertion.

Those
people, I want to punish. It's irrational, because intellectually I know I
can't actually change them. Rationally, I can killfile them. Possibly, I
can stimulate cumulative change in the system, but I am uncertain of it. In
10 years maybe I will have let it go.

This sounds good on the surface, and I can certainly understand phases
in one's life. Nevertheless, acknowledging a shortcoming doesn't excuse
it (please don't repeat that to my girlfriend, I don't want it used
against me later <wink>). Besides, you are still assuming that it is
others who need to change. I can assure you that even were that so, it
is an exercise in futility. Until you can cease to react to others, it
is somewhat hypocritical to explain that they shouldn't react to you.

For instance, I'm reasonably sure I can stimulate minor change in your own
static type. You understand enough of the dimensions already that you're
capable of absorbing more of them. But you'll have probably gotten there on
your own soon anyways, so am I really needed as a stimulus?

That would assume that 1) I desire such change, and 2) that such change
would be desirable.

Actually, I suspect I'm not for your benefit, if I am for anyone's benefit.
I suspect it is for someone who is lurking. Maybe someone who hasn't formed
much of a world view yet. Mine, at any rate, is in my .sig.

Well, certainly there is some benefit for someone, but I'm less than
certain that the lesson is necessarily what you would expect.


Regards,

 

[Ramon Leon Fournier]

- Python is not a good language for low-level 3D graphics problems. C++ is
better.

Well, not just for low-level 3D graphics. There are many other things
you would not code in Python unless you are a complete fool. Your
companies mail server, for instance. But you wouldn't do that in C#
either. Though there probably *are* people or companies who would even
manage to sell such stuff. Wonderful Windows world.

- Python isn't a rapid prototyping godsend for every problem out there.

But let me ask you, what is it that you are actually looking for? A
language for each and "every problem out there"? Can there be such a
thing? I doubt. For me, it's just one out of about three 1/2 languages
I use for my daily work (that is, Python, C/C++, Bourne-Shell, in that
order, plus a bit of Fortran where it really can't be avoided). I find
that Python is very handy and I may say that I now use it for more than
50% of my work. But I wouldn't unnecessarily force myself to use it for
everything.

- Microsoft C# and .NET are strategic threats to Python's prosperity and
vitality, if not survival.

Only time will tell. But let's face it: For Python it will be difficult
to stand against the massively advertised, fashionable M$ products,
that everybody believes (s)he needs. Under Windows, of course. Unix is
a different domain.

- Yet unnamed languages are capable of taking Python's place on the food
chain.

Let's not speculate. Let them come. We'll evaluate then.

- You have to promote your language, grow its market share, to prevent that
from happening.

Granted that my motivation to use Python is different from that of many
others here. I have work to do, and to finish it as quickly as
possible. I figured that Python is a great language for people like me,
who are not full-time programers but who need an easy to learn language
for daily quich-and-dirty scripting. Thus, it doesn't matter to me if
Python has 1 or 10 Million users. Though I am happy about every
colleague I can "convert". Because I know from experience that it's a
good thing and that for others it may be as good as it has proven for
myself. That doesn't necessarily mean that there is nothing better out
there. In the environment that I am working in (a M$ free one), Python
is a good choice. Possibly Ruby would be about as good, and despite of
having looked at both, I liked Python a lot more, but that's more a
matter of my personal taste. I also used Perl from time to time but
never got to like it. In contrast to Python.

These analyses are called "sanity" in the Windows world. It's Reality On
The Ground. It's really odd to come to a developer community where people
are insular and freak out about these kinds of pronouncements. It makes
Windows people wonder if Python people are capable of industrial relevancy.

As stated, I don't care. If one day I have to learn C# or .NET, it'll
be early enough. But unless I am forced to, I happily stay away from
it.

The rest of you: wake up! Smell the Windows!

I never particularly liked that stench. Do you?

BTW: What exactly has "Smell the Windows" to do with the current Ruby
vs. Python debate? Are you actually serious about learning any of
these, or are you trying to convince yourself that it was right not to
ever try them out?

Your attitude reminds me of somebody not wanting to try the taste of
say, cheese, because it smells so bad, doesn't look great, etc. But who
always goes into the swiss restaurants asking around "What's so good
about cheese, why don't you better eat potatoes?" What will the people
tell that guy?

I am not saying that you are trolling, and in the recent discussions
you actually made some good points. But you obviously lack the sincere
will to actually become able to make a competent judgement yourself.
That's annoying.

Ramón

 

[Heiko Wundram]

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).

Too true, I think I thought of classmethods/staticmethods when I posted
that... Guess that makes much more sense... It was early in the morning,
forgive me...

And for the rest, I don't find it bad to specify self as a first
parameter, anyway, as I can then always grab it using *args.

But, okay, I'll refrain from posting any code tonight, guess I'll get it
all wrong again.

Heiko.

 

[Nick Vargish]

read everything slowly, chew the cud, *then* start writing. I read
the whole of Stroustrup and a couple of other books before writing a

I couldn't get past the first chapter of Stroustrup... Maybe because
I'd already been working with C++, it read like a pile of
justifications for what I consider a bastardization of an elegant
foundation. (So, I like C but dislike C++, what can I say?)

Nick

 

[Dave Benjamin]

Thus, the direct Python equivalent might be

import __builtins__
__builtins__.len = someotherfunction

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...!).

I agree with your position, more or less, but I am curious - how far do you
think this deprecation should go? Just changing a function in __builtins__?
Changing a function in any module? Or changing *anything* about a module
from the outside?

Thanks,
Dave

 

[Tim Rowe]

Oh, come on, Brandon is *much* less of a troll than T*m*t*y R*e.

Dangerously close to my name -- I hope it's not a typo and meant to
/be/ my name!

 

[Tim Rowe]

O'Caml, not to mention a bunch of others -- if only Python didn't do
almost everything so well, there'd be more motivation...

Yep, that's the one. I was up and running producing useful code in
Python within hours, and though I'd go to other languages for
particularly specialised tasks Python does pretty much everything I
want, does it well and does it easily. On the other hand, I've tried
a few times to learn Ruby and never got to the point at which I could
produce anything useful. I think it's because I've never used Perl
and have not used Un*x much. Ruby, it seems to me, very much shows
those roots and so seems to me to have less of a general appeal.

 

[Tim Rowe]

That said, I feel a little bad for Tim Rowe. He's posted many
interesting and relevant articles. But for the last year or so, my
finger is always halfway to the delete button before I realize that a
post is by this nice guy with an unfortunately similar name .

Phew! Thanks for that. And it's a relief, because I was unaware of my
(near) namesake and I was worried I had done something horrid! Would
it help if I configured my newsreader to put my middle initial ("G")
in?

 

[Alexander Schmolck]

Alexander Schmolck wrote:
...

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

Indeed. But see below.

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".

I don't think I'm confused about this.

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).

Is your assumption of my ignorance regarding the difference between
mutation/rebinding maybe based on the implicit assumption that a class
statement by some sort of logical necessity *has* to create a new class object
and then bind a name to it?

Is there a reason why a class X(...):... statement can't just mutate a
preexisting, former version of the class X (provided there is one?). Maybe
there is, in which case let me state that I'm not particularly hung up on
this, what I'm hung up about is the ability to easily update the behavior of
pre-existing instances.

How exactly this happens (by mutating the class in question (by whatever
means, a new class statement, some function calls, __dict__-assignment), by
rebinding the .__class__ for all instances etc.) is of less importance to me
(although I suspect the 2nd alternative would cause all sorts of problems,
because the old (viz non-'id'entical) class object could also hang around in a
couple of other places than .__class__, .__bases__ etc.).

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.

Agreed, but I think that happened some time ago.

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).

I simply want some effective mechanism to have changes in selected parts of my
sourcecode adequately reflected in a running interactive session, without
much fuzz.

I'm happy to write some elisp and python code to do some extra work on top of
py-execute-region on a key-press. By "adequately reflected" I mean amongst
other things that I can easily change the behavior of existing instances of a
class after I made changes to the source code of that class.

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__.clear()
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?

I tried this some time ago and discovered it only worked for old style
classes; the dict-proxies of new-style classes are, I think, not directly
mutable, I'd guess for efficiency reasons.

Here is an example of the difference (update, clear, del won't work either,
BTW):
.... def bar(): "bar"
....

X.__dict__['bar'] = lambda :"foo"
class X(object):

.... def bar(): "bar"
....

X.__dict__['bar'] = lambda :"foo"

TypeError
TypeError: object does not support item assignment

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 "unreasonable"?

Agreed, this was an unproductive way to describe my problem. Mea culpa.

Although I have investigated the problem before (and for the reason stated
above, settled for the suboptimal reassigning to .__class__ when I
*desperately* wanted to change a important instances), on second thoughts not
only should I have phrased myself differently, I should also have spent more
time thinking about it.

I *think* it ought to be possible to effect all the necessary changes by
directly manipulating attributes, rather than going via .__dict__, even for
class/staticmethods.

It's too late now, so I haven't fully thought this through yet but I'll give
it a try tomorrow.

Anyway, I still don't see a compelling reason why class statements
couldn't/shouldn't be mutating, rather than rebinding. Is there one?

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).

I'd be interested to hear your reasons. (The only argument against this style
that I can think off from the top of my head is that it might encourage sloppy
and code development and unwitting reliance on irreproducible artifacts of the
session history.

I don't think this problem occurs in practice, however. If I write
(non-throwaway) code, I always write plenty of testcode, too, (which, BTW I
also find *much* more pleasant to develop and debug interactively) and
frequently start new python processes to to run this testcode in fresh
sessions to satify myself that things just don't appear to work because of
accumulated garbage in my interactive session.

[snipped]

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).

I think we need to sharply distinguish between two things (and I should
presumably have stressed this more in my last post):

1. Redefining methods of class during execution, as part of the solution to
the problem the program is supposed to adress.

2. Redefining classes as part of an incremental development process. In this
case, you of course "redo" the whole class statement, because you edit the
source code with the class statement and everything else in it and then the
most convinient way to update your code is to send all or part of this
newly edited file to your interactive session (plus potentially some
tweaking code that mutates the pre-existing "live" version of X as you
outlined above, or somehow else effects the changes you want to take place
in existing instances).

I'm chiefly interested in 2. (to the extent that I consider it an essential
ability of a good programming language) and much less so in 1. (although
modifying instances and classes can also sometimes be useful).

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

(I wonder whether it is (quite possibly) and if so why? Developing code
interactively just seems like the obvious and right thing to do to me.)

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

No it doesn't, for example Ruby doesn't have docstrings which is an
unnecessary waste of my time (apart from the fact that Ruby offends my
sense of esthetics).

-- 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.

Nope, in that case I'd almost certainly use smalltalk which I consider
infinitely superior to ruby (or possibly some Lisp).

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...).

I don't think we really fundamentally disagree. I don't think one should screw
around with everything just because one can and I also think that languages
who set inappropriate incentives in that direction are less suitable for
production software development.

'as

 

[Alexander Schmolck]

Alexander Schmolck:

What about the other way around? Make a macro for Lisp or
Scheme which converts Python into the language then evals
the result?

Actually, at least one person has been working on this for scheme (I've never
heard about it again and he targeted about the most useless scheme
implementation around).

One thing that makes such an attempt fairly unattractive for anyone with
finite amounts of time is that python isn't that much use without its
supporting C/C++ modules schemes/lisps suck in the FFI department (every
lisp/scheme has its own way of interfacing to C).

Given how easy it is to parse Python (there are several Python
parsers for Python) and the number of people who have popped
up with Lisp background, I'm surprised no one has done that
for fun. After all, there is Python for C, Java, .Net, and for
Python (PyPy) and variations like Pyrex and Vyper. But
none for Lisp?

Would certainly be interesting.

(I think I remember mention of one some years ago, .. I think
*I* posted that link to c.l.py, but I don't remember when and
can't find it via Google.)


The Boost code for C++ suggests a different way to do the latter.
(I don't think templates are the same as hygenic macros.)

Could you say a little bit more about it? In python I think one could to some
extent use operator overloading and a special expression class, that
simplifies the literal expression the programmer stated, but I guess then one
would then to explicitly request evaluation (and operator overloading isn't
quite powerful enough to easily incorporate 'alien' class-instances, too).

Is the C++ code something along those lines, or different?


'as

 

[John J. Lee]

I couldn't get past the first chapter of Stroustrup... Maybe because
I'd already been working with C++, it read like a pile of
justifications for what I consider a bastardization of an elegant
foundation. (So, I like C but dislike C++, what can I say?)

I agree. In C++, where you see a book section heading like "Feature
X, Feature Y and Feature Z", it means that X, Y and Z have some
horrendous interactions that you have to commit to memory. In Python,
it means that X, Y and Z are so simple they all fit in one section ;-)

I do wonder if the tight constraint on C++ of being C+extra bits was
ever really justified.


John

 

[Andrew Dalke]

John J. Lee, refering to Alex, refering to John J. Lee.:

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'?

I'm pretty sure he meant me. The use of a ":" is not required by the
language. Guido said it's there to provide extra visual clue about
the end of the line, and Tim added that it makes python-mode and
other such tools easier to write because that makes it easy to
tell when a block starts.

My complaint is that that option means it's harder to tell

if abcdefghijkl+
f()
g()

goes over several lines. Computational tractable, but
poor for readability.

:-( 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...

I would shy away from the "undistinguishable" form because

"He lead an undistinguished life"

is more synonymous (in my head - dictionaries not withstanding)
to "bland", "boring", and "uninteresting" while "indistinguishable"
is "cannot be told apart from other items."

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"?

[...]

That is indeed strange.

Additionally, I think back to the Smalltalk 80 book I
hazily remember reading, and I recall it also suggesting that
'open' class definitions are a good thing. Ruby's blocks have
strong Smalltalk heritage, which I believe also influenced
Ruby's choice in this.

Andrew
(e-mail address removed)

 

[Andrew Dalke]

Alexander Schmolck, responding to me:

I'd say redefine X in the local namespace. Have you spotted a problem with

it?

I'm thinking about problems like this

# module a.py
class X:
def a(self): print "qwerty"

# module b.py
from a import X

def redo():
global X
class X:
def a(self): print "asdfg"

# interactively
from b import X, redo

x = X()
redo()
print x.a()
print X().a()


Does the interactive loading of X get a copy of b.X,
which is a copy of a.X?

Because of the 'global X', will the redefinition
of X in redo() change the module definition?
What's the output from the print statements?

In short, it would be the only thing in Python which
rebinds a local variable in-place, and I don't have
good feelings about the consequences.

Andrew
(e-mail address removed)

 

[Andrew Dalke]

Alexander Schmolck:

One thing that makes such an attempt fairly unattractive for anyone with
finite amounts of time is that python isn't that much use without its
supporting C/C++ modules schemes/lisps suck in the FFI department (every
lisp/scheme has its own way of interfacing to C).

If Parrot gets enough Python working for the challenge, then someone
could write a Lisp-y language targeting Parrot, and take advantage
of the work of others.

For that matter, there's Lisps on the JVM, no? Could support
Jython.

Could you say a little bit more about it? In python I think one could to some
extent use operator overloading and a special expression class, that
simplifies the literal expression the programmer stated, but I guess then one
would then to explicitly request evaluation (and operator overloading isn't
quite powerful enough to easily incorporate 'alien' class-instances, too).

Is the C++ code something along those lines, or different?

Different. The problem with the operator overloading approach is
the creation and description of intermediate objects. If you do

a = b + c * d

then "c*d" makes an intermediary temporary.

Template expressions solve it by providing a description of
how to do the add, early enough that the compiler can optimize
based on the whole express. Eg, for vectors, the compiler
could generate code equivalent to

for (i=0; i<n; i++) {
a = b + c*d;
}

Here's an old reference
http://infm.cineca.it/infm_help/parallel/poop/KAY.html

Andrew
(e-mail address removed)