What's better about Ruby than Python? I'm sure there's something. What is
it?
This is not a troll. I'm language shopping and I want people's answers. I
don't know beans about Ruby or have any preconceived ideas about it. I have
noticed, however, that every programmer I talk to who's aware of Python is
also talking about Ruby. So it seems that Ruby has the potential to compete
with and displace Python. I'm curious on what basis it might do so.
--
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.
Jul 18 '05
220  17598 
Harry George <ha************@boeing.com> writes: 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).
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"?
The python language is just fine as is.
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).
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.
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).
'as
Alex Martelli <al*****@yahoo.com> writes:
[...] of each block (rather than just unindenting) -- but then I do get
to avoid typing the equally-silly ':' which Python requires at the
_start_ of each block, so that's almost a wash:-). Other syntax
[...]
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_that_i_can_reach_the_ end_of_this =
line
where the indentation of 'line' indicates line continuation.
Others no doubt base their choice of programming languages on just
such issues, and they generate the hottest debates -- but to me that's
just an example of one of Parkinson's Laws in action (the amount on
debate on an issue is inversely proportional to the issue's actual
importance).
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
everybody's comments, that is). Which is why Ruby's very existence is
a bit sad -- you could almost regard it as a code fork, except that
the author forgot to start with Python's source code ;-)
[...] I do understand why others would thing otherwise, even though
I could hardly disagree more vehemently with them:-).
Thus proving your own point about the inverse importance / volume
relationship ;-)
[...] Ruby does have some advantages in elementary semantics -- for
example, the removal of Python's "lists vs tuples" exceedingly
subtle distinction.
You may be right there. Guido's comment that tuples are mostly
mini-objects did clarify this for me, though.
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
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? 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?
[...] about undistinguishable to anybody and interchangeable in any
*in*distinguishable. Ha! I found a bug.
[...] 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
[...]
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
doing
import some_module
def evil_replacement_function(): return blah()
some_module.important_function = evil_replacement_function
in Python, wouldn't it?
John
On Mon, Aug 18, 2003 at 03:14:52PM -0700, Brandon J. Van Every wrote: Lulu of the Lotus-Eaters wrote: The second surest sign that a post is a troll is if the author
includes:
This is not a troll.
The first surest sign that a post is a troll is if the author is:
"Brandon J. Van Every" <va******@3DProgrammer.com>
Man, it's clear that I've got an entire hate group around here to
exterminate! I wonder how long it's going to take? Maybe this is a
positive sign of Python's growth: it's got enough critical mass to attract
just about anybody, not just people who want to get things done. At any
rate, welcome to my killfile.
Never blame on malice what can be explained by stupidity.
I don't care if you write troll posts maliciously or not, I do care that you
keep sending them.
So how big is that RAID that holds your killfile?
-jack
"Brandon J. Van Every" <va******@3DProgrammer.com> writes: Alex Martelli wrote:
Don't be misled by these comparisons into thinking the two
[...] spaghettini as the pastasciutta to go with suitable sauces for
such long thin pasta forms (olive oil, minced garlic, minced
[...] [or even -- I'm a heretic...! -- light mint...] leaves -- at
the very last moment before serving the dish).
What a wonderful runon sentence. You must be an A. A. Milne fan.
[...]
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.
John
On Mon, 18 Aug 2003 15:09:44 -0700, "Brandon J. Van Every"
<va******@3DProgrammer.com> wrote: Doug Tolton wrote:
Clearly you are interested in people's philosophical take on why you
should've posted to the Ruby boards, because you take the time to
respond to each and every criticism.
I actually can't remember that I've deliberately done that. I expect I
probably haven't. At any rate, I do always take the time to let people know
that I'm putting them in my killfile. Such as yourself. You haven't said
anything awful, but you also went out of your way to make an otherwise
content-free post at my expense. Of what use is that to me? Eventually,
I'll whittle this group down to people who can take a simple, rational
question at face value, provide the needed info, and be done with it.
Yes!!
I wonder why he takes the time to continue posting to this group if we
are all such idiots?
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
On 18 Aug 2003 23:40:58 +0100, Alexander Schmolck <a.********@gmx.net>
wrote: Alex Martelli <al*****@yahoo.com> writes:
Alexander Schmolck wrote:
... > I recall the following, roughly in order of importance (treat with
> caution, it's some time that I looked at Ruby):
>
> 0. I it's possible to redefine classes at runtime without going bonkers
> (instances automatically get updated to the new class definitions).
This is generally feasible in Python, too -- but not with built-in types
(e.g., you can't redefine what "+" means on integers, while in Ruby you
could).
I don't care about redefining built-in types, I *do* care about redefining the
behavior of all instances of a class automatically, rather than by hand and
only for some cases (like classes without those damned __slots__).
> This, I think is by far python's greatest flaw, amongst other things it
> greatly compromises its interactiveness, which is a key virtue. If
> someone can explain to me how I'm wrong on this and python's behavior
> really is sane, I'll be eternally grateful.
I don't think I understand what you're saying. For example:
>>> class X:
... def amethod(self): return 'just a method'
... >>> x=X()
>>> x.amethod()
'just a method' >>> def abettermethod(self): return 'ah, now THIS is better!'
... >>> X.amethod = abettermethod
>>> x.amethod()
'ah, now THIS is better!' >>>
I want something like:
class X:... def amethod(self): return 'just a method'
... x=X()
class X:... def amethod(self): return 'ah, now THIS is better!'
... x.amethod()
'ah, now THIS is better!'
But of course what currently happens is:
'just a method'
And rightly so, you have just rebinded a name. If you type
x.__class__
you get the older X. Or are you proposing that rebinding X to
automagically rebind the __class__ of all the X instances?
But why can't you just
X.amethod = lambda self: "ah, now THIS is better!"
that is, mutate the class referenced by X instead of rebinding X to
some other class?
With my best regards,
G. Rodrigues
I gave a look at Ruby some months ago, due to various favorable
opinions
I saw on c.l.py. Whereas there are few interesting things, there are
at
least two things I didn't like:
1. The syntax: too perlish for my taste;
2. Mixins: a poor man solution compared to multiple inheritance in
Python.
I also got the impression that they make a big deal about object
orientation but that in practice Python has a better support for
object orientation (I mean multiple inheritance, metaclasses,
descriptors, properties,
etc.) even if nobody is interested in stressing this point
particularly
in this community, since Python is multi-paradigm. Also, functional
programming seems to be easier in Python than in Ruby.
I got these impressions from an evening reading the tutorial, so
I reserve myself the right to change my opinion if I find the time
of looking at Ruby better ;)
Anyway, no doubt that I will choose Ruby over perl, tcl, c#, c++,
java,
etc. (I mean, as a language; the situation is different if
avalaibility
of libraries or performances are taken in account). If Perl is
Python's
uncle, Ruby is Python's brother. As other have said, there are more
similarities than differences and I expect the productivity to be more
or less the same (modulo possible issues with the lack of librairies
or english documentation, issues that probably will disappear soon,
I think).
Michele
Doug Tolton I don't agree at all. Yes when you are defining a macro you are in
essence defining a new mini-language. This is perhaps one of the most
powerful features of Lisp. Programming closer to the application
domain, *greatly* enhances both the readability and the reusability of
code.
For that domain. And rarely does the author of a package,
much less a macro, understand "the domain as understood by other
people" vs. personal understanding.
This topic has come up before. Laura Creighton made several
comments on macros, the most notable of which is:
lac:
] Writing your own Lisp Macro System is better than sex. I
] _know_ -- 18 year old me turned down _lots_ of opportunities
] for sex to go hack on her macro system. Thus if we introduce
] this to the language, I think that it is _inevitable_ that we will
] fragment the Python community into a plethora of mutually
] unintelligble dialects. I don't want this. Thus I don't want a
] macro facility in the language _because_ it would be so cool.
That doesn't mean it *shouldn't* be available [in Python].
Python is Open Source, how would someone writing a
Macro lock you in? Just don't use the macro.
Another writing from Laura seems relevant:
http://mail.python.org/pipermail/pyt...ay/042102.html
My interepretation - I don't customize my apps, nor even
my .cshrc (except for one alias (alias ls 'ls -l \!* | grep ^d')
an 'unset noclobber', 'set ignoreeof', and the PATH and
LD_LIBRARY_PATH - and I wish I didn't need those)
I don't, because I don't like to think. At least not spend my
time puzzling out slight changes. I like my changes either
none or a lot, that is, use Python as-is or write a converter
(or use another language).
Just like anything else, Macro's can be over used and abused. However
I maintain that if you don't see the usefulness of macros, you don't
really understand them.
That's not the argument against them. It's that they are too useful,
each person makes their own dialect, the community breaks down
as the different branches do their own thing, and one person's so-
called "Python" code looks different than another's.
I know I am nowhere near as good a language designer as Guido,
Larry Wall, Matz, and the others, though I think I'm pretty decent.
I don't have the essential hubris to say that I know better how
to tweak Python-the-language to fit my own domain.
Essentially using Python over Machine
language is just using one big ass macro language.
You confuse two meanings of the word 'macro' here.
Any assembly language worth its salt has "macros", which
are pre-assembled sets of code. Use the macro and it
generates the code. But you can't use those macros to
rewrite the actual language like you can with hygenic
macros. It doesn't have the proper tail-biting recursive nature.
Andrew da***@dalkescientific.com
Gonçalo Rodrigues <op*****@mail.telepac.pt> writes: On 18 Aug 2003 23:40:58 +0100, Alexander Schmolck <a.********@gmx.net>
wrote:
But of course what currently happens is:
'just a method'
And rightly so, you have just rebinded a name. If you type
x.__class__
you get the older X. Or are you proposing that rebinding X to
automagically rebind the __class__ of all the X instances?
Well, yes, I propose that x.__class__ return the *new* definition of X (like
in ruby, for example). I don't think that necessarily involves rebinding
anything "automagical", depending on how the lookup of x.__class__ works.
Can you give my any reason why you would *not* want all instances to be
updated on class redefinition?
But why can't you just
X.amethod = lambda self: "ah, now THIS is better!"
that is, mutate the class referenced by X instead of rebinding X to
some other class?
Um, didn't you read what I wrote or was I just unclear?
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 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. This is an *very*
reasonable wish if it doesn't just take seconds to get to the current state by
rerunning everything, but possibly hours or days). 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 easy task, as far as I can see and
then updating their .__class__ might not quite work as expected either as I've
already mentioned).
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.
'as
"Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message news:<bh************@ID-203719.news.uni-berlin.de>... Lulu of the Lotus-Eaters wrote: The second surest sign that a post is a troll is if the author
includes:
This is not a troll.
The first surest sign that a post is a troll is if the author is:
"Brandon J. Van Every" <va******@3DProgrammer.com>
Man, it's clear that I've got an entire hate group around here to
exterminate!
Doesn't that just mean a lot of people will be able to talk about you
behind your back without your ever realising? I was wondering why all
those people were making allegations about small children, and you
didn't defend yourself. I thought it was all true!
At any rate, welcome to my killfile.
Like he cares?
Congratulations, you've just managed to deprive yourself of the often
insightful contributions of a regular poster to this newsgroup.
I wonder if you wouldn't be better off simply not participating in
Usenet groups at all. You'll save significant amounts of diskspace
without that killfile of yours, not to mention keystrokes. But please
feel free to add me to your much vaunted killfile as well, that way
you don't have to listen one of the few people who, in this thread,
actually took your question seriously and gave a substantive answer.
Ah yes, back to substance. I forgot to mention that Ruby ranges seem
much more intuitive than Python slicing. But I think the confusion,
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.
On 18 Aug 2003 23:40:58 +0100
Alexander Schmolck <a.********@gmx.net> wrote: Does it make sense now? I say "something like" because I could also live with
something like ``sys.update_all_instances_of(X)``. What I can't live with is
the (according to my current understanding) entirely brain-dead ``x.__class__
= X`` for every `x` I can lay my hands on, with quite a bit of labour (and
which furthermore tends to break pickling etc). I guess I must be overlooking
something here, because to me it seems entirely obvious that there should be a
straightforward mechanism for updating all instances of a class when the class
is redefined.
Well... I think you're overlooking the fact that you're not exactly _redefining_ the class. You're creating an entirely new class object and binding it to the same name, but the old class is still lying there, and all instances have their __class__ references pointing to it.
class X:
def amethod(self): return "just a method"
# and
import types
def amethod(self): return "just a method"
X = types.ClassType('X', (), {'amethod':amethod})
#
So, I may be completely wrong, but I think that redefining the entire class rather than methods on the former class, is not possible in Python, unless you keep references of instances and iterate over them updating their __class__ to point to the new class object.
Brandon J. Van Every wrote: You certainly are a waste of my time, Tom. Welcome to my killfile. I'd
like to think that if I'm a waste of your time, it's for different reasons
and not ones of my own designing.
For what is worth Brandon is a hard working troll.
I can respect that. Look at all of his responses,
and all the effort to reward those that do respond
to his questions.
And all that killfiling, it is a gimmick but it works,
is funny to see whether you make it or not. It makes you
read what he says next. Posting on the usenet is
a sort of jungle, getting read is surviving. And
no matter how, mocked or not, laughed at or ridiculed
Brandon's parasitic postings live on.
It is not that easy and it takes an appreciable mental
exercise to attempt to juggle or manipulate people.
Istvan.
Alexander Schmolck: 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.
What about the other way around? Make a macro for Lisp or
Scheme which converts Python into the language then evals
the result?
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?
(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.)
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).
The Boost code for C++ suggests a different way to do the latter.
(I don't think templates are the same as hygenic macros.)
Andrew da***@dalkescientific.com
> Brandon J. Van Every wrote:
Man, it's clear that I've got an entire hate group around here to
exterminate! I wonder how long it's going to take? Maybe this is a
positive sign of Python's growth: it's got enough critical mass to
attract just about anybody, not just people who want to get things done. At any
rate, welcome to my killfile.
Cliff Wells wrote:
The major problem appears to be your mode of communication. At first I
took your questions seriously, then I began to think you were trolling
(and a rather clever troll at that), and finally I've come to the
conclusion that you're not trolling, rather merely arrogant and
abrasive. You seem to get a large number of people who perceive you as
a troll. While I no longer believe this to be true, the sheer number of
people in so many different newsgroups should perhaps indicate to you
that you need to take a break from your local D&D group and socialize a
bit. You are lacking some fundamental skills in this area. You're
clearly intelligent and have in fact brought up some interesting topics,
but your lack of tact tends to take them off-track rather quickly.
For instance, do you really think publicly announcing that someone is in
your killfile hurts their feelings or somehow vindicates you? That's
rather pathetic, but makes sense given the source. I'd venture that
mentality is most common at the pre-teen level of social interaction.
Cliff, welcome to Brandon's killfile. I'll buy you a beer as soon as I get
there. You may not have to wait long. ;-)
Brandon, you would do well to take a deep breath, read and understand
Cliff's message. You may not like it, but it's extremely perceptive, and it
would do you a world of good to take his advice to heart.
When you started the Python vs. Java thread a few days ago and the first
couple of people ragged on you, I stood up for you, saying that I found your
message interesting and thought-provoking. I deliberately chose not to
google your previous conversations, figuring that anybody deserves a fresh
start.
But my goodness! Now I can see what all the fuss was about. You even
killfiled Doug Tolton, who made some very insightful comments about the
benefits of macros today in this Ruby thread.
A single friend of my wife's recently moved to Tacoma, Washington, because
she wasn't satisfied with the quality of the people (read: men) she was
meeting here in San Jose. She was shocked--shocked!--to find that the people
in Tacoma were no different from the ones down here. I had to wonder if
there just might have been *something* in common between the people she met
in San Jose and the people she met in Tacoma.
Brandon, learn to roll with the punches and have some fun with the rest of
us. What good does it do *you* when you say to someone, "You said something
I don't like. You failed to satisfy my needs in this conversation. I will
never listen to anything you ever say again!"
Would you do that in a face to face conversation? I didn't think so. So try
this: delete that silly killfile, cultivate the sense of humor you've shown
in the rattlesnake thread--I knew you could do it!--and be willing to say,
"Folks, I know I've been a bit abrasive and antagonistic in the past, and I
apologize for that. I really would like to get a fresh start here and I'm
curious to hear your thoughts on these questions."
Fair enough?
-Mike
Alexander Schmolck <a.********@gmx.net> wrote in message news:<yf*************@black132.ex.ac.uk>... I want something like:
class X: ... def amethod(self): return 'just a method'
... x=X()
class X: ... def amethod(self): return 'ah, now THIS is better!'
... x.amethod() 'ah, now THIS is better!'
Yeah, I see what you mean. I have dreamed of redefining a base
classes and having all its children automatically updated. This
would be a potential source of confusion, however (i.e. I redefine my
class at line 1242 of my code and the behavior of all the classes defined
in the previous thousand of lines is magically altered, making harder
to understand what the program is doing).
Currently you can add methods to a base class instead, and it does work
under inheritance too:
class B(object):
.... pass class C(B):
.... pass c=C()
B.m=lambda self:None
c.m()
You can also change the class of an instance:
c.__class__=B
However this does not work always in Python 2.3 (there is an issue
with "heap" classes, a limitation to avoid redefining the boolean type).
I guess I must be overlooking
something here, because to me it seems entirely obvious that there should be a
straightforward mechanism for updating all instances of a class when the class
is redefined.
Since I know of no such mechanism and python's current semantics seem pretty
moronic to me, I'm sure I must be missing something (python has an amazingly
low rate of "obviously stupid" design decisions, that still strike you as
stupid after you understood their rationale). So it's maybe about time
someone put me straight.
Regular instances are automatically updated when you modify their class;
however if I remember correctly I had problems updating classes which
metaclass was modified (don't remember what problem exactly).
Michele
John J. Lee 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_that_i_can_reach_the_ end_of_this =
line
where the indentation of 'line' indicates line continuation.
Hmm. Start with
for a in some, incredibly, long, list, so, it, hides, the, end,:
qwerty_etaoin_shrdlu_glub_glub()
g()
Drop the colon one line and it would then be legal to write
for a in some, incredibly, long, list, so, it, hides, the, end,
qwerty_etaoin_shrdlu_glub_glub():
g()
As it is now, you'll have to write
for a in (some, incredibly, long, list, so, it, hides, the, end,
qwerty_etaoin_shrdlu_glub_glub()):
g()
or perhaps the less recommended
for a in some, incredibly, long, list, so, it, hides, the, end, \
qwerty_etaoin_shrdlu_glub_glub():
g()
Both provide a little more clue that the expression goes on
into the next line.
Not really a counterpoint, just an observation.
the two languages are? 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?
I was in a field, bioinformatics, dominated by Perl code. (It
still is.) But I decided Python was better in various ways - easier
to read, easier to build larger data structures, and easier for
non-software developers (scientists) to use.
A few years ago I looked at Ruby. I think my criteria for
selecting Python over Perl is still true for Python over Ruby,
in that it has too many special characters (like @ and the
built-in regexpes), features (like continuations and code
blocks) which are hard to explain well (I didn't understand
continuations until the Houston IPC), and 'best practices'
(like modifying base classes like strings and numbers)
which aren't appropriate for large-scale software
development.
So the answer would likely still be yes.
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
doing
Good question, since I repeated it above.
In the into to Ruby docs (or the book?) it mentions that there
are no functions in Ruby, only methods, and that when you
wrote something which looks like a function it's really a
private method of the base Object. Eg, it does change
methods of the fundamental base class.
(I took it to mean that Ruby's claim to be unrepentantly OO
was overly strong.)
I don't have any experience programming Ruby to know
what people do for large projects. I will point out that
the Ruby book in one of the first few chapters says:
http://www.rubycentral.com/book/tut_classes.html In Ruby, classes are never closed: you can always add
methods to an existing class. This applies to the classes
you write as well as the standard, built-in classes. All
you have to do is open up a class definition for an
existing class, and the new contents you specify will
be added to whatever's there.
and later on
http://www.rubycentral.com/book/ospace.html You can add code to a running process. You can
redefine methods on the fly, change their scope from
public to private, and so on. You can even alter basic
types, such as Class and Object.
Once you get used to this flexibility, it is hard to go
back to a static language such as C++, or even to
a half-static language such as Java.
and I found a tutorial showing how to do the same thing
http://www.math.hokudai.ac.jp/~gotok.../uguide14.html In subclass, we get changing behavior of the instances
by redefine the superclass methods.
(It appears this is a translation from a Japanese tutorial.)
Both are in introductory material, and neither make a
suggestion about its inappropriateness for anything other
than debugging.
import some_module
def evil_replacement_function(): return blah()
some_module.important_function = evil_replacement_function
in Python, wouldn't it?
And that is frowned upon, and as I recall there's some
thought to preventing that in "Python 3.0" for performance
reasons. Though I've needed to patch code that way.
(It may be that I misheard too.)
It isn't talked about in any of the introductory materials
for Python that I recall reading.
Andrew da***@dalkescientific.com
|>The first surest sign that a post is a troll is if the author is:
|>|"Brandon J. Van Every" <va******@3DProgrammer.com>
|Oh, come on, Brandon is *much* less of a troll than T*m*t*y R*e. Unlike
|the R**bot, we do some interesting topics out of Brandon, they're just
|written with such antagonism that I'd be hard-pressed to top them.
True enough, I was under-general in listing my "first sign." What I
meant was:
The first surest sign...is if the author is in the set {BJVE, ...}
Of course, my killfile pretty much gets rid of the main ones... I only
see the followups, not the original posts. But I think the R**bot has
gone away.
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 :-).
Yours, Lulu...
--
mertz@ _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis _/_/ Postmodern Enterprises _/_/ s r
..cx _/_/ MAKERS OF CHAOS.... _/_/ i u
_/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/ g s
On Tue, Aug 19, 2003 at 01:46:20AM +0100, Alexander Schmolck wrote: Gonçalo Rodrigues <op*****@mail.telepac.pt> writes:
On 18 Aug 2003 23:40:58 +0100, Alexander Schmolck <a.********@gmx.net>
wrote:
But of course what currently happens is:
'just a method'
And rightly so, you have just rebinded a name. If you type
x.__class__
you get the older X. Or are you proposing that rebinding X to
automagically rebind the __class__ of all the X instances?
Well, yes, I propose that x.__class__ return the *new* definition of X (like
in ruby, for example). I don't think that necessarily involves rebinding
anything "automagical", depending on how the lookup of x.__class__ works.
Can you give my any reason why you would *not* want all instances to be
updated on class redefinition?
Python names aren't special in any way so making names special when associated
with a class as opposed to a function or variable would make it less
intuitive for users. Pyhon also doesn't have anonymous classes, so an odd
but perfectly OK program could be written
class Anon(Exception): pass
raise_this_later(Anon) # stores it for later
class Anon(Exception):
def __str__(self):
return "Slightly different exception"
raise_this_later(Anon)
Explicit is better than implicit requires that the programmer specifically
change all old 'Anon' classes into the new classes. Writing a metaclass
to do this explicitly for you just for all the classes that might be
redefined is also OK.
# completely untested, I haven't overidden __new__ in practice so that line
# might be a bit off.
class NamesMatter(type):
all_seen_classes = {}
all_seen_instances = []
def __init__(cls, name, bases, dict):
"""If a class name is reused rebind all the old instances to the new class"""
if (name in NamesMatter.all_seen_classes):
for (ob) in filter(lambda x:x.__class__ == NamesMatter.all_seen_classes[name]):
ob.__class__ = cls
NamesMatter.all_seen_classes[name] = cls
def remember_obs__new__(cls, **args, **opts):
"""A custom __new__ that records instances in a central place"""
self = object.__new__(cls)
NamesMatter.all_seen_instances.append(self)
return self
setattr(cls, '__new__', classmethod(remember_obs__new__))
return
# usage
class Anon(object): pass # a class that doesn't upgrade itself
class Upgrader(object):
__metaclass__ = NameMatter
"""Instances of this class will be upgraded to a new class if this name
is reused"""
-jackdied
On 19 Aug 2003 01:46:20 +0100, Alexander Schmolck <a.********@gmx.net>
wrote: Gonçalo Rodrigues <op*****@mail.telepac.pt> writes:
On 18 Aug 2003 23:40:58 +0100, Alexander Schmolck <a.********@gmx.net>
wrote: >But of course what currently happens is:
>
>'just a method'
>
And rightly so, you have just rebinded a name. If you type
x.__class__
you get the older X. Or are you proposing that rebinding X to
automagically rebind the __class__ of all the X instances?
Well, yes, I propose that x.__class__ return the *new* definition of X (like
in ruby, for example). I don't think that necessarily involves rebinding
anything "automagical", depending on how the lookup of x.__class__ works.
Can you give my any reason why you would *not* want all instances to be
updated on class redefinition?
But in the example you gave you were not *redefining* the class
referenced by X! You are *rebinding* the name X to a different class,
two completely different things. So no, I do not want
rebinding the name X => Automagically change instances of X.__class__
to the new class
This strikes me as a very insane thing to do. That, or else I'm not
understanding a thing of what you are saying -- which given that it's
3am and I am tired, it's not that farfetched.
But why can't you just
X.amethod = lambda self: "ah, now THIS is better!"
that is, mutate the class referenced by X instead of rebinding X to
some other class?
Um, didn't you read what I wrote or was I just unclear?
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 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. This is an *very*
reasonable wish if it doesn't just take seconds to get to the current state by
rerunning everything, but possibly hours or days). 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 easy task, as far as I can see and
then updating their .__class__ might not quite work as expected either as I've
already mentioned).
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.
Um, you were unclear. I still can't understand why the following does
not work for you: class X(object):
.... def amethod(self):
.... return "I am %r." % self
.... x = X()
x.amethod()
'I am <__main__.X object at 0x010D4C10>.' X.amethod = lambda self: "I am not who I am."
x.amethod()
'I am not who I am.'
It seems to cover the use case you describe above.
There are other, more "violent" means of mucking with a class
hierarchy, such as rebinding __class__ or __bases__ directly but that
does not always work and is fraught with dangers.
With my best regards,
G. Rodrigues
Pedro Werneck: Well... I think you're overlooking the fact that you're not exactly
_redefining_ the class. You're creating an entirely new class
object and binding it to the same name, but the old class is still
lying there,
I'm pretty sure he knows that and simply disagrees with that
design choice, suggesting that a class def should augment a
class if it already exists.
I wonder ... Alexander? What should this do?
from Q import X
class X:
def amethod(self): return 'ah, now THIS is better!'
Should it refine the X in the local namespace or make a new
class?
I have wondered if
def X.amethod(self): return "...."
should be allowed, but no longer think it should.
OTOH, a proper reload, which updated all instance's __class__
to the newly reloaded class, would be nice. I've stumbled
over that many a time.
Andrew da***@dalkescientific.com
Cliff Wells wrote:
The major problem appears to be your mode of communication. At first
I took your questions seriously, then I began to think you were
trolling (and a rather clever troll at that), and finally I've come
to the conclusion that you're not trolling, rather merely arrogant and
abrasive.
Bingo! Guilty as charged. And I get more and more abrasive the more people
call me a troll. As do most people who aren't actually trolling.
I ask tough questions about Python vs. other languages and platforms. Some
people can't handle it. Maybe they'd handle it if I diplomatically sugar
coated it, but I'm not going to. Things to irritate the "Brandon's a troll"
crowd some more:
- Python is not a good language for low-level 3D graphics problems. C++ is
better.
- Python isn't a rapid prototyping godsend for every problem out there.
- GUI and tools support can end up being more important than language
niceties.
- Microsoft C# and .NET are strategic threats to Python's prosperity and
vitality, if not survival.
- Pythonistas should consider trying to eat Java's lunch, because they
aren't going to eat Microsoft's lunch.
- Ruby has some mindshare among people with knowledge of Python.
- Yet unnamed languages are capable of taking Python's place on the food
chain.
- You have to promote your language, grow its market share, to prevent that
from happening.
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.
Fortunately, I was pointed to the marketing-python list and I've discovered
that not all Python crowds are the same.
The rest of you: wake up! Smell the Windows!
--
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.
You seem to get a large number of people who perceive you
as
a troll. While I no longer believe this to be true, the sheer number
of people in so many different newsgroups should perhaps indicate to
you
that you need to take a break from your local D&D group and socialize
a bit. You are lacking some fundamental skills in this area. You're
clearly intelligent and have in fact brought up some interesting
topics, but your lack of tact tends to take them off-track rather
quickly.
For instance, do you really think publicly announcing that someone is
in your killfile hurts their feelings or somehow vindicates you?
That's rather pathetic, but makes sense given the source. I'd
venture that mentality is most common at the pre-teen level of social
interaction.
Regards,
Cliff Wells wrote:
For instance, do you really think publicly announcing that someone is
in your killfile hurts their feelings or somehow vindicates you?
That's rather pathetic, but makes sense given the source. I'd
venture that mentality is most common at the pre-teen level of social
interaction.
You and I have different social theories. My social theory is, people are
very stubborn. Nobody will engage in Right behavior the minute you tell
them to. But if I killfile people, and tell them why (i.e. "Because you are
a Troll Hunter, and such people are useless."), then someday they may wake
up and figure it out. It may be 6 months from now, it may be 2 years from
now. The point is to have a cumulative effect on people's newsgroup
behavior.
It also starts to sink in when people realize they've been killfiled for
years. People eventually wake up and mellow out.
Cliff, you aren't in my killfile. I don't have much problem with what you
wrote about me, because you wrote it tentatively, even if you strongly
suspected you'd reach certain conclusions. The point is to examine one's
perceptions, one's role, before running off and screaming, "So and so's a
troll!" There may be other explanations. Generally, it is broadening to
put yourself in someone else's shoes.
--
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.
On Mon, 18 Aug 2003 21:43:12 -0700, Brandon J. Van Every wrote: Cliff Wells wrote: finally I've come to the conclusion that you're not trolling, rather
merely arrogant and abrasive.
Bingo! Guilty as charged. And I get more and more abrasive the more
people call me a troll. As do most people who aren't actually
trolling.
Quite the opposite -- "get[ting] more and more abrasive the more people
call [one] a troll" is *exactly* how a troll acts.
People who aren't actually trolling will make efforts to depart from
troll-like behaviour when accused of it, to avoid confirming the
accusation.
--
\ "When I was crossing the border into Canada, they asked if I |
`\ had any firearms with me. I said, 'Well, what do you need?'" |
_o__) -- Steven Wright |
Ben Finney <http://bignose.squidly.org/>
Michael Geary wrote:
But my goodness! Now I can see what all the fuss was about. You even
killfiled Doug Tolton,
Is Doug Tolton pure? Let's see, what did I killfile him for... ah, here was
the first bit.
Doug Tolton wrote: On Mon, 11 Aug 2003 14:16:35 +0200, Max M <ma**@mxm.dk> wrote: Bob Gailer wrote: What is "trolling"?
Ugh...he got me.
So at this point, Doug has already decided that I'm a troll. He hasn't
applied critical thinking, he's just running with the pack. I responded,
explaining myself, but didn't killfile him. Later on, Doug makes a post
that explicitly flames me and doesn't include any info about Python or Ruby
whatsoever. He said I was ranting, whining, and begging, and he wasn't
trying to be at all useful about it. So I killfiled him. Surprised?
who made some very insightful comments about
the benefits of macros today in this Ruby thread.
So what? Sometimes you forego information when the source is too much
trouble. Besides, if it's a really really really great point, someone else
will reply to it and I'll see an executive summary indirectly.
Brandon, learn to roll with the punches and have some fun with the
rest of us.
I'm a pugilist. If someone punches me, I'd sooner smash their face in and
be done with it. There are so many other people to talk to that don't take
jabs at you.
What good does it do *you* when you say to someone, "You
said something I don't like. You failed to satisfy my needs in this
conversation. I will never listen to anything you ever say again!"
Oh, I don't killfile people *forever*. The first reprieve generally comes
at system reinstall. When all the killfiles acidentally get wiped out, or I
change newsreaders, or something like that. Everybody gets a second chance
at that point. People who still insist on being trouble at that point, get
killfiled for many years. I've known a few, like 2 or 3. Even they mellow
out with age. But that can be as long as 5 years. At some point, such
people look back over those 5 years and realize I wasn't personally around
to be their whipping boy or irritant for most of that time. So, they
realize it was them, not me.
Would you do that in a face to face conversation? I didn't think so.
Most people don't have this much trouble face-to-face. There's so much
extra information: tone, facial expression, body posture, hand gestures.
It's easier for people to take comments in the manner they were intended,
and it's easier for people to see they're pissing someone else off and back
down. E-mail and newsgroups are inherently imperfect media, and I will not
try to change them.
So try this: delete that silly killfile, cultivate the sense of humor
you've shown in the rattlesnake thread--I knew you could do it!--and
be willing to say, "Folks, I know I've been a bit abrasive and
antagonistic in the past, and I apologize for that. I really would
like to get a fresh start here and I'm curious to hear your thoughts
on these questions."
No, I shall not. I acknowledge and own my abrasion, I don't apologize for
it. Nothing I say should be that tough for people to swallow. But, there
are always people who are emotional and reactive, who think something big is
at stake. I know these people are always out there... I recognize that I
reap what I sow. But I will continue to sow. Because I've tried the other
way, the polite way, the diplomatic way, and you know what? People flame
anyways. That has always been the pattern. No matter what you say,
*someone* has to make a problem out of it. And those people, they go in the
killfile and stay there.
Case in point: my first "What's better about Ruby than Python?" post. I
explicitly said, this is not a troll. Some chose to flame and accuse
anyways. Such people are useless, there is nothing you can do with them.
Fair enough?
My smiles are for those who smile. Or for those who frown, but realize
their frown is a mirror.
--
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.
"Troll" is really a function of the audience. These guys will
exist, there is this way of viewing the world as a dramatic
contest between the armies of Python etc.: You will lose, they
will eat your lunch, you're already dead and you don't know it,
bla bla. But it takes an audience that finds this sort of thing
in the least compelling, usually young males it seems.
I don't actually see much of that in the responses, just picking
a few at random. A discussion of language issues, like why Python
has no macros etc., not contentious though a bit boring because it
tends to be a rehash. Other than people using the newsgroup to
complain about Brandon posts, Brandon's abrasive style doesn't
seem to have much effect.
If there's anything about c.l.p. that makes any of this disagreeable,
it's the implicit awareness that someone might actually add macros,
etc., to Python. This means that you can't just let people blabber
on about it, stuff like that has to be nipped in the bud and all the
usual arguments have to be presented every damned time the subject
comes up. Or next thing you know, Guido will conduct a poll: should
there be macros.
Donn Cave, do**@drizzle.com
On Mon, 2003-08-18 at 19:40, John Roth wrote: 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.
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.
Heiko.
On Mon, 2003-08-18 at 21:43, Brandon J. Van Every wrote: Cliff Wells wrote:
The major problem appears to be your mode of communication. At first
I took your questions seriously, then I began to think you were
trolling (and a rather clever troll at that), and finally I've come
to the conclusion that you're not trolling, rather merely arrogant and
abrasive.
Bingo! Guilty as charged. And I get more and more abrasive the more people
call me a troll. As do most people who aren't actually trolling.
Quoting the Dalai Lama:
Conventional truth, conventional reality is a consensus reality,
something that people agree on. Events do not have a reality of their
own. All events depend on other events. Nothing (no person) has an
independent identity, there is no intrinsic reality. What is called
"reality" depends on the context of other factors.
While I don't necessarily consider the Dalai Lama an authority on all
(or even many) things, I think there is certainly a great amount of
truth to this observation. If the majority of people think you are
trolling, then, whether you intend to or not, perhaps you are.
If you were being truly pragmatic, as you claim, then you must surely
realize that offending people with an abrasive approach is
counter-productive. Especially when many of those people are central to
the Python community. By that I don't mean prolific posting (although
that is part of it), but rather the people who have some of the most
intimate knowledge of Python and some who actually contribute to its
development. You might think that killfiling those people will teach
them a lesson (it won't, they could probably care less), but I can
guarantee that if you do use Python you will suffer far more than they
from missing out on their knowledge of the tool you've chosen. If you
post a question regarding actual use of Python (versus rhetorical
questions about its utility or future) you have increased your chance of
not seeing the answer because you've killfiled the person with the
knowledge you are after.
I ask tough questions about Python vs. other languages and platforms. Some
people can't handle it. Maybe they'd handle it if I diplomatically sugar
coated it, but I'm not going to. Things to irritate the "Brandon's a troll"
crowd some more:
- Python is not a good language for low-level 3D graphics problems. C++ is
better.
This is a worthless assertion. I don't think anyone has suggested
otherwise, either in any of the threads you've started or at any other
time. You did assert it in an earlier thread, but it was apparently in
response to nothing.
- Python isn't a rapid prototyping godsend for every problem out there.
No, but for many if not most.
- GUI and tools support can end up being more important than language
niceties.
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. And this is just one thing.
- Microsoft C# and .NET are strategic threats to Python's prosperity and
vitality, if not survival.
This is certainly arguable. Java certainly hasn't stopped Python's
growth. There is little to support this claim other than fear or
admiration of Microsoft.
- Pythonistas should consider trying to eat Java's lunch, because they
aren't going to eat Microsoft's lunch.
IMHO, Python is set to become the Visual Basic of the open-source
world. RedHat uses it for many of its administrative tools and the RH
installer. It comes bundled with most open source operating systems.
Many open source applications are starting to use Python as an extension
and scripting language. Python on Win32 might struggle against MS
languages (whatever that means), but as Linux gains mindshare it carries
Python with it. It seems MacOSX might also become a "carrier" of
Python.
- Ruby has some mindshare among people with knowledge of Python.
Certainly. Your questions regarding this were something I had wondered
myself but didn't concern myself with due to Ruby's lack of
infrastructure (tools and libraries).
- Yet unnamed languages are capable of taking Python's place on the food
chain.
As with any other language. Of course languages aren't applications or
operating systems. The competition isn't quite the same in this arena.
For the most part, it doesn't matter if you write your application in
BrandonBasic of which you are the sole user and developer. What matters
is how your applications written in this unappreciated language perform.
- You have to promote your language, grow its market share, to prevent that
from happening.
Okay, this is where you lose me: why? Why should I care if other people
use Python? In my opinion, being in an exclusive group of developers
who use what I consider to be superior tools gives me a distinct
advantage. Why would I want that to change? I certainly recommend
Python to others, but that's just my nice side winning out. If someone
irritates me I have no problem recommending Perl or C# to them <wink>.
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.
Probably these same people wondered the same about Linux advocates a few
years ago. In a few more years they'll wonder what happened to their
beloved behemoth (Windows).
Fortunately, I was pointed to the marketing-python list and I've discovered
that not all Python crowds are the same.
Part of the reason people respond to you so violently is because you
tend to make unsubstantiated and provocative claims and then accuse
people of being "knee-jerk reactionaries" when they dismiss them.
The rest of you: wake up! Smell the Windows!
Sorry, I haven't smelled that smell (except incidentally) since 1994
(Slackware 1.0). I expect to be smelling it less and less as time goes
on. However, this is a fine example of an unnecessarily inflammatory
statement.
Regards,
Cliff
--
I have seen too much, wipe away my eyes
-Bauhaus
Jack Diederich wrote: On Mon, Aug 18, 2003 at 03:14:52PM -0700, Brandon J. Van Every wrote:
Man, it's clear that I've got an entire hate group around here to
exterminate! I wonder how long it's going to take? Maybe this is a
positive sign of Python's growth: it's got enough critical mass to
attract just about anybody, not just people who want to get things
done. At any rate, welcome to my killfile.
Never blame on malice what can be explained by stupidity.
What if stupidity fosters malice? To wit:
I don't care if you write troll posts maliciously or not, I do care
that you keep sending them.
The problem here is, they aren't troll posts. You just perceive them to be.
Why you do, you'd have to answer for yourself. But I will hazard to guess:
you don't like it when certain questions are asked. You think they are
illegitimate questions, and that nobody, rationally speaking, should ask
them. You think the questions will always cause trouble, that we can count
on this from what we know about newsgroup behaviors, so therefore the
questions should not be asked. In other words, you think you know best
about how discourse should properly proceed.
So how big is that RAID that holds your killfile?
Text is trivial to store on modern computers and I'm not in newsgroups
*that* much. My anti-spam file is a couple of orders magnitude bigger than
my killfile. Maybe 3 orders of magnitude. 4? I can't tell. Anyways, I
don't think it's worth trying to work out your perceptions, so welcome to my
killfile along with the rest.
I am starting to wonder, if the high number of kills I've gotten in c.l.p
says something about community cohesion? I mean, I get kills in *every*
group I spend any time in, but the speed and volume of kills I'm getting
here is novel. It's usually much more isolated and sporadic than this. I
hereby pronounce c.l.p, Second Order Magnitude of community cohesion. You
guys aren't all in the same pocket or parrots of each other, but there are c
learly some trends. For a First Order Magnitude community cohesion, check
out something really cranky and old guard like rec.arts.int-fiction. I
think they still think the Internet is a DARPA project! And despite years
of absence, I'm sure I'm still a favorite there. Smooches, any of that ilk
lurking about.
--
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.
Alexander Schmolck wrote: "Brandon J. Van Every" <va******@3DProgrammer.com> writes:
Alexander Schmolck wrote:
Would you still have a problem with macros in python if utilizing
them required some obvious and explicit mechanism (say a
'use_custom_syntax' statement right at the beginning of a module
that wants to use macros), so that their use could easily be
controlled by e.g. project managers?
Yes you would. In open source communities, you'd get different
philosophical camps, and people in one camp would embed
'use_custom_syntax' in some *.h file (yeah yeah I'm a C++
programmer) that all the other *.h files use.
In the proposed scheme every module that wants to use custom syntax
has to say so, period. So there is no silent infestation (these
syntaxes can't be stealthily exported).
I wsan't talking about stealth, I was talking about developmental inertia.
The least common denominator is functionality turned ON in some root *.h
file, and everyone else inherits the functionality. Are you saying that
modules in Python don't inherit?
If you don't want the functionality to end up being "always ON" by faits
accompli, then you must ensure that functionality is irrevocably, "always
OFF." In other words, don't provide the functionality.
It would be
easy (from a technical perspective) for project managers (open source
or otherwise) to only allow certain, particularly trusted programers
to create such modules or ban them outright.
From a technical perspective. From a productivity, political, or business
perspective, you are asking the moon. People are going to do what works.
What works, is functionality turned ON at the least common denominator.
Nobody wants to chase the ON/OFF test issues. Nobody's going to change code
that was designed monolithically ON to something compartmentalized ON/OFF.
Just like you wouldn't allow every second rate programmer to write the
system-critical libraries everything is built upon, you wouldn't
allow just about anybody to create their own mini-languages without a
need.
Man, this isn't very real world as far as how sprawling projects evolve!
--
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.
> > Would you do that in a face to face conversation? I didn't think so.
Most people don't have this much trouble face-to-face. There's so much
extra information: tone, facial expression, body posture, hand gestures.
It's easier for people to take comments in the manner they were intended,
and it's easier for people to see they're pissing someone else off and
back down. E-mail and newsgroups are inherently imperfect media, and I will
not try to change them.
That's an excellent point that we would all do well to heed. (Myself
included.) Being half Italian, I have plenty of experience with heated
discussions conducted in total friendship. But that definitely works only in
person!
Personally, I think it's worth taking a little extra effort to try to
compensate for the limitations of the medium. If you know that people are
more likely to misunderstand your intentions, why egg them on?
You've certainly made some insightful comments here, such as the Reality On
The Ground list you just posted. It's unfortunate that the message has been
obscured by the tone of the conversation. (Not placing blame--it takes more
than one to tango.)
-Mike (Windows programmer for 17 years and Python newbie...)
Asun Friere wrote: "Brandon J. Van Every" <va******@3DProgrammer.com> wrote in message
Man, it's clear that I've got an entire hate group around here to
exterminate!
Doesn't that just mean a lot of people will be able to talk about you
behind your back without your ever realising?
That's the point! I *want* them to! I look so, so much better when people
abuse me and I don't answer them at all. People figure out pretty quick
who's really full of it or not. The killfile makes the process...
automatic. It's just messy now because the killfile is still being built.
Congratulations, you've just managed to deprive yourself of the often
insightful contributions of a regular poster to this newsgroup.
Lulu??!? You think with the kind of barb he made, that my e-mail address is
synonymous with "troll," that I care about his insights? or think that he
has any to offer? Even if he does, I'll decline that trouble. It ain't
worth it.
I wonder if you wouldn't be better off simply not participating in
Usenet groups at all. You'll save significant amounts of diskspace
without that killfile of yours,
Please. We all know how tiny text storage is, EVEN WHEN IMPLEMENTED IN
PYTHON. ;-)
not to mention keystrokes.
True. The problem is, I'm still young and stupid enough to believe that I
can have a cumulative effect on Usenet behavior. Maybe in 10 years I'll see
the light.
But please
feel free to add me to your much vaunted killfile as well, that way
you don't have to listen one of the few people who, in this thread,
actually took your question seriously and gave a substantive answer.
It's not that easy. You have to actually insult me, show an incapacity to
rate me as anything but "troll," and/or demonstrate your complete
unwillingness to be useful. The exact combo is a judgement call, but easily
seen when there. For example, Doug Tolton fulfilled the criteria, albeit
barely. Albeit again, quite deliberately, so not so barely. You yourself
have failed, you will have to try harder if you want into my killfile.
MHHUUAHAHAHHAHAHHAHAAAA!!!!
--
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.
Michael Geary wrote:
Personally, I think it's worth taking a little extra effort to try to
compensate for the limitations of the medium. If you know that people
are more likely to misunderstand your intentions, why egg them on?
Often, I have a misanthropic idea that I can negatively educate people. If
people "get into it," and later it is pointed out how they got themselves
into it, they might learn not to "get into it."
I don't know if in 10 years' time, I'll find it pointless to educate anybody
other than my own (future) children. I already have a theory of static
archetypes. Think I posted that in one of these forums, in one of these
kinds of interchanges. Basically, people change, but people change so
slowly that you can't measure it in weeks or months. It takes years. So if
you're dealing with people on a timespan shorter than a year, regard them as
a static type. They are part of a system, an ecology of types. They are a
certain enzyme. The Troll Hunters are a certain enzyme, so you espouse
Buddhist wisdom to them and also killfile them. There is nothing else to do
with them right now. Their growth will come later.
--
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.
Ben Finney wrote: On Mon, 18 Aug 2003 21:43:12 -0700, Brandon J. Van Every wrote: Cliff Wells wrote: finally I've come to the conclusion that you're not trolling, rather
merely arrogant and abrasive.
Bingo! Guilty as charged. And I get more and more abrasive the more
people call me a troll. As do most people who aren't actually
trolling.
Quite the opposite -- "get[ting] more and more abrasive the more
people call [one] a troll" is *exactly* how a troll acts.
So? Squares are rectangles, but rectangles are not squares.
People who aren't actually trolling will make efforts to depart from
troll-like behaviour when accused of it, to avoid confirming the
accusation.
Only in your world view. It's not a IFF.
--
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.
Dave Harrison wrote: I ask tough questions about Python vs. other languages and platforms.
Quite frankly most people of your ilk have a tendency to winge and
complain about "missing features" or "bad design" but do nothing to
contribute to the language. I fail to see why this puts you in any
position to ask the "tough questions" as you put it. If you see
something you consider to be a weakness, suggest a solution, don't
winge about the fact that it exists.
Well, I can certainly put up or shut up about *that* !
http://pythonology.com/pipermail/marketing-python/
http://www.3dprogrammer.com/Python_Logo_Draft.JPG
http://www.3dprogrammer.com/French_Python.JPG
Warning, last 2 are 754K and 461K, and you'll probably need to scroll.
I get tired of people who lack imagination, who think they know everything
about why so-and-so asks such-and-such a question, or speaks in
this-and-that a way. Who never exercise their imaginations, who don't try
to see from someone else's perspective. What do you really do, yourself, to
address the problems? And seeing these photos above, are you going to
falsely conclude that I care about Python? I don't. Not yet, at any rate.
This is a trial period.
- You have to promote your language, grow its market share, to
prevent that from happening.
Who cares ? If you want to go stick up posters for Python go for it.
That's why I spend my time working with the marketing-python crowd and not
your ilk. As far as I'm concerned, you are the enemy of progress. Because
progress requires relevance. "What language will be relevant 10 years from
now?" That is my agenda.
You certainly appear like a troll, so how about a few suggested
solutions to these so called problems you raised ?
Your wish is my command, Grasshopper. Now, what should I ask of you in
return? I know: nothing. You will either see or you will not see.
--
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.
Donn Cave wrote: "Troll" is really a function of the audience.
Agreed.
These guys will
exist, there is this way of viewing the world as a dramatic
contest between the armies of Python etc.: You will lose, they
will eat your lunch, you're already dead and you don't know it,
bla bla. But it takes an audience that finds this sort of thing
in the least compelling, usually young males it seems.
I'm after something much bigger than Python. I'm after Permanent Computing.
I want any game I make to be archived for hundreds of years to posterity.
Championing an open source language, or figuring out how to surf Microsoft
indefinitely, is only the opening gambit.
It would not shock me if most people could care less about this agenda.
Most programmers are not also artists. They accept their ephemerality,
their complete wastes of time. In fact, they usually think it's kewl.
--
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.
On Mon, 2003-08-18 at 23:17, Brandon J. Van Every wrote: The problem here is, they aren't troll posts. You just perceive them to be.
Why you do, you'd have to answer for yourself. But I will hazard to guess:
you don't like it when certain questions are asked. You think they are
illegitimate questions, and that nobody, rationally speaking, should ask
them. You think the questions will always cause trouble, that we can count
on this from what we know about newsgroup behaviors, so therefore the
questions should not be asked. In other words, you think you know best
about how discourse should properly proceed.
There is a grain of truth to this. Certain questions and conversations
almost inevitably lead to flame wars. This is well-known to long-term
usenet users. This is why people who ask such questions are usually
referred to the archives where such battles have been waged ad nauseum.
There is a definite tendency to try to deflect such battles before they
begin. To try to force those battles is about as reliable an indicator
of trolling as is "URGENT: YOUR IMMEDIATE ASSISTANCE REQUIRED" is a
reliable indicator of Nigerian spam. It should come as no surprise to
you that people mistake your posts as trolling. They may be incorrect,
but it is certainly a reasonable assumption. As such, the burden is on
you to demonstrate otherwise. To do otherwise is simply taking
advantage of the fact that this ng isn't moderated (in which case you
would certainly have been moderated out of existence by this point).
You seem to be under the impression that people here are hostile to
certain points of view, but I'm aware of at least one time in the past
year or so when the topic of forcing someone from the ng came up and
most were vehemently opposed to such tactics, even though the person in
question had irked everyone to no end.
Like most groups of people with an intellectual leaning, people here
tend to be fairly skeptical. Making inflammatory assertions with no
supporting arguments is bound to gather you the flames you seem to be
asking for.
I am starting to wonder, if the high number of kills I've gotten in c.l.p
says something about community cohesion? I mean, I get kills in *every*
group I spend any time in, but the speed and volume of kills I'm getting
here is novel. It's usually much more isolated and sporadic than this. I
hereby pronounce c.l.p, Second Order Magnitude of community cohesion. You
guys aren't all in the same pocket or parrots of each other, but there are
clearly some trends.
This is actually quite insightful. I'd agree that as a whole this ng is
rather cohesive. Most people who come to this ng comment on its overall
friendliness and helpfulness. That is something rather rare on usenet.
Those of us who spend a good portion of our days here prefer it that
way. And it isn't a "we don't take kindly to strangers" small-town
mentality. Python is a pragmatic language and tends to attract
pragmatic people. Long-winded dissertations on things not-Python tend
to be tolerated to the extent the participants contribute to things
Pythonic. Were you known to be a contributor, either with code or
knowledge, your forays into time-wasting speculation would most likely
be much better received. As it is the only "contribution" you've made
is a generous use of other people's time and bandwidth.
The fact that you get "kills" in every ng you spend time in probably
says more about you than other people. 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). As you've acknowledged in another post (although
in somewhat different words), people tend to create the world they live
in. You've also claimed to be a pugilist. Why then, are you surprised
when people choose to fight with you? Taking your statements together
would seem to indicate that a fight is what you want. People who
actively seek fights in newsgroups are called trolls. You can take this
to its logical conclusion as others already have. To quote another post
of yours (see, I'm still reading): "Generally, it is broadening to put
yourself in someone else's shoes." If others are (mis)perceiving you as
a troll, then perhaps you should try to see it from their point of view
for a moment. At the very least you'll have a better insight as to how
their accusations should be addressed and might actually prevail in the
argument. *plonk* is the sound the white flag makes when it hits the
top of the post.
Regards,
Cliff
--
Severance, the birds of leaving call to us
Yet here we stand, endowed with the fear of flight
-Dead Can Dance
Cliff Wells wrote:
Quoting the Dalai Lama:
Conventional truth, conventional reality is a consensus reality,
something that people agree on. Events do not have a reality of their
own. All events depend on other events. Nothing (no person) has an
independent identity, there is no intrinsic reality. What is called
"reality" depends on the context of other factors.
While I don't necessarily consider the Dalai Lama an authority on all
(or even many) things, I think there is certainly a great amount of
truth to this observation. If the majority of people think you are
trolling, then, whether you intend to or not, perhaps you are.
Then you missed what the Dalai Lama said. He did not speak of essence. He
spoke of events depending on other events. And I'm quite conversant with
what Troll Hunters depend on.
If you were being truly pragmatic, as you claim, then you must surely
realize that offending people with an abrasive approach is
counter-productive.
Counter-productive to what agenda? My current agenda is identifying the
unworkable people and disposing of them.
You might think that killfiling those people will teach
them a lesson (it won't, they could probably care less),
Frankly, I don't think I've killfiled anyone who's worth the trouble to
un-killfile. I seriously doubt that they have anything important to say
that I have to hear.
Part of the reason people respond to you so violently is because you
tend to make unsubstantiated and provocative claims and then accuse
people of being "knee-jerk reactionaries" when they dismiss them.
It's only the people calling me a troll that I label "knee-jerk
reactionaries."
--
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.
"Brandon J. Van Every" wrote: I'm after something much bigger than Python. I'm after Permanent
Computing.
I want any game I make to be archived for hundreds of years to
posterity.
Championing an open source language, or figuring out how to surf
Microsoft
indefinitely, is only the opening gambit.
The abandonware community is alive with emulators. "Permanent
computing" is fool's gold.
--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Let he who does not know what war is go to war.
\__/ (a Spanish proverb)
Cliff Wells wrote: To try to force those battles is about as reliable an indicator
of trolling as is "URGENT: YOUR IMMEDIATE ASSISTANCE REQUIRED" is a
reliable indicator of Nigerian spam. It should come as no surprise to
you that people mistake your posts as trolling. They may be
incorrect, but it is certainly a reasonable assumption.
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 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.
Were you known to be a contributor, either with code or
knowledge, your forays into time-wasting speculation would most likely
be much better received. As it is the only "contribution" you've made
is a generous use of other people's time and bandwidth.
As I see it, my detractors are enginerds with no appreciation for or skill
at marketing. Nor, probably, much awareness of Python marketing efforts.
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?
The fact that you get "kills" in every ng you spend time in probably
says more about you than other people.
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.
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.
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. 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.
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.
Taking your statements together
would seem to indicate that a fight is what you want.
That's sorta true. This is really what I call a "posting binge," to avoid
other things I don't want to be doing. 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. 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.
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?
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.
--
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.
In article <bh************@ID-203719.news.uni-berlin.de>, Brandon J. Van
Every wrote: I ask tough questions about Python vs. other languages and platforms.
Why don't you work on some tough solutions?
Some
people can't handle it. Maybe they'd handle it if I diplomatically sugar
coated it, but I'm not going to. Things to irritate the "Brandon's a troll"
crowd some more:
- Python is not a good language for low-level 3D graphics problems. C++ is
better.
Not many programmers are going to write their own low-level 3D code. Python
has bindings to 3D libraries. For some specialized applications this will
not be adequate, but I don't think that is something worth worrying too much
about.
- Python isn't a rapid prototyping godsend for every problem out there.
Someone said that it was? BTW, in your experience, for which problems is
Python not good for rapid prototyping?
- GUI and tools support can end up being more important than language
niceties.
Luckily Python has both excellent GUI and tool support *and* language
niceties.
- Microsoft C# and .NET are strategic threats to Python's prosperity and
vitality, if not survival.
Sounds like a good opportunity for someone who sees such a threat to work
out and implement a response.
- Pythonistas should consider trying to eat Java's lunch, because they
aren't going to eat Microsoft's lunch.
Sounds like a good opportunity for someone interested in eating Java's
lunch to work out and implement a plan for doing so.
- Ruby has some mindshare among people with knowledge of Python.
OK.
- Yet unnamed languages are capable of taking Python's place on the food
chain.
I'll worry about it when they get names. I like learning new languages.
Maybe unnamed language will be more fun than Python.
- You have to promote your language, grow its market share, to prevent that
from happening.
Sounds like a good opportunity for someone interested in marketing.
Dave Cook
Heiko Wundram wrote:
... 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
Wrong:
class X:
.... def test(*args): print args
.... X.test()
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)
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).
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).
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
Asun Friere wrote:
... Ah yes, back to substance. I forgot to mention that Ruby ranges seem
much more intuitive than Python slicing. But I think the confusion,
Having both a..b AND a...b -- one indicating a half-open range, another
indicating a closed range -- "more intuitive"? You gotta be kidding...
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.
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
Alexander Schmolck wrote:
... 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
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.
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.
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__.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? 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"?
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
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(oldClass, newClass):
oldClass.__dict__.clear()
oldClass.__bases__ = 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).
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.
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
Doug Tolton wrote:
... 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.
"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 more useful abstaction capability into the language.
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
"Brandon J. Van Every" <va******@3DProgrammer.com> writes: 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.
I almost got it.
Not meant to be 'got'. Your mention of 'runon' sentences just
reminded me of it, and that was good enough excuse for me :-)
John
John J. Lee wrote:
... 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_that_i_can_reach_the_ end_of_this =
line
where the indentation of 'line' indicates line continuation.
I see somebody else already indicated why this isn't so.
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
Yes, they're extremely similar languages.
Ruby does have some advantages in elementary semantics -- for
example, the removal of Python's "lists vs tuples" exceedingly
subtle distinction.
You may be right there. Guido's comment that tuples are mostly
mini-objects did clarify this for me, though.
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).
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
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?
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.
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?
Non-linguistic considerations such as the above may also have their
weight, in some case. But they're not huge ones, either.
about undistinguishable to anybody and interchangeable in any
*in*distinguishable. Ha! I found a bug.
You're wrong, see e.g. http://dict.die.net/undistinguishable/ :
the spellings with the initial "u" and "i" are just synonyms.
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
[...]
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
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"?
doing
import some_module
def evil_replacement_function(): return blah()
some_module.important_function = evil_replacement_function
in Python, wouldn't it?
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__.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...!).
Alex
Alex Martelli <al*****@yahoo.com> wrote: 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.
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.
On Mon, 18 Aug 2003 15:17:03 -0700,
Erik Max Francis <ma*@alcyone.com> wrote: 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
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
> > - GUI and tools support can end up being more important than
language niceties.
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.
http://wxhaskell.sourceforge.net
"Heiko Wundram" <he*****@ceosg.de> wrote in message
news:ma**********************************@python.o rg... On Mon, 2003-08-18 at 19:40, John Roth wrote: 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.
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.
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
Heiko.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Brandon J. Van Every |
last post by:
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...
|
by: Stephen C. Waterbury |
last post by:
This seems like it ought to work, according to the
description of reduce(), but it doesn't. Is this
a bug, or am I missing something?
Python...
|
by: john_sips_tea |
last post by:
Just tried Ruby over the past two days. I won't bore you
with the reasons I didn't like it, however one thing really
struck me about it that I...
|
by: emrahayanoglu |
last post by:
Hello Everyone,
Now, I'm working on a new web framework. I tried many test on the other
programming languages. Then i decided to use python on my...
|
by: Kemmylinns12 |
last post by:
Blockchain technology has emerged as a transformative force in the business world, offering unprecedented opportunities for innovation and...
|
by: antdb |
last post by:
Ⅰ. Advantage of AntDB: hyper-convergence + streaming processing engine
In the overall architecture, a new "hyper-convergence" concept was...
|
by: Matthew3360 |
last post by:
Hi there. I have been struggling to find out how to use a variable as my location in my header redirect function.
Here is my code.
...
|
by: Matthew3360 |
last post by:
Hi, I have a python app that i want to be able to get variables from a php page on my webserver. My python app is on my computer. How would I make it...
|
by: AndyPSV |
last post by:
HOW CAN I CREATE AN AI with an .executable file that would suck all files in the folder and on my computerHOW CAN I CREATE AN AI with an .executable...
|
by: Arjunsri |
last post by:
I have a Redshift database that I need to use as an import data source. I have configured the DSN connection using the server, port, database, and...
|
by: WisdomUfot |
last post by:
It's an interesting question you've got about how Gmail hides the HTTP referrer when a link in an email is clicked. While I don't have the specific...
|
by: Matthew3360 |
last post by:
Hi,
I have been trying to connect to a local host using php curl. But I am finding it hard to do this. I am doing the curl get request from my web...
|
by: Rahul1995seven |
last post by:
Introduction:
In the realm of programming languages, Python has emerged as a powerhouse. With its simplicity, versatility, and robustness, Python...
| |
