What's better about Ruby than Python?
Brandon J. Van Every
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.
Raymond Hettinger
"Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message
news:bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de...
> What's better about Ruby than Python? I'm sure there's something. What is
> it?
Code blocks, automatic properties, continuations,
and excellent Japanese documentation ;-)
Raymond Hettinge
Erik Max Francis
> What's better about Ruby than Python? I'm sure there's something.
> What is
> it?
Wouldn't it make much more sense to ask Ruby people this, rather than
Python people?
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Never had very much to say / Laugh last, laugh longest
\__/ Des'ree
Graham Fawcett
>What's better about Ruby than Python? I'm sure there's something.
>
Of course there is.
>What is
>it?
>
>
You're never going to get an answer to this question that satisfies you.
Even if everyone chips in and describes their favourite features, those
features may be worthless to you personally. So why bother asking?
Try the languages out yourself, both of them; program a non-trivial
application in both languages. See how each feels to you, and which
better suits your development style.
Determine which language has, in your opinion, better support via
documentation and community.
Then come back to the list and tell us which is the better language. ;-)
>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.
>
Exactly: so don't ask for others' ideas. Since you haven't used Ruby
yet, their ideas will simply give you preconceived ideas. What you need
are postconceived ideas; harder to gain, but infinitely more valuable.
-- Graham
Ville Vainio
> This is not a troll. I'm language shopping and I want people's answers. I
..
> 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.
:-)
Asun Friere
> it?
>
> This is not a troll. I'm language shopping and I want people's answers.
When I was language shopping python was up to version 1.5.2 (actually
it was probably up to 1.6.1, but not on the system I was using), and
there were a number of distinct advantages that I felt Ruby held over
Python.
First and foremost, everything in Ruby was (behaved like) an object.
That is now true for Python also.
Secondly you could subclass basic types, again, this is true for
Python as well.
Thirdly the regular expression syntax was Perl-like and built into the
core of the language (althought unlike perl, of course, the syntax
generated an object). In a way this is unaesthetic, certainly
python's approach is much more consistent with the object oriented
nature of the language. However, I use regexp so often, and still
find the re module cumbersome in comparison to Perl's way of doing
things, so imho this is still and advantage (ugly as it may be) that
Ruby holds.
Finally I was apprehensive about the 'signigicant whitespace' issue in
Python, and thought that Ruby's approach was safer. I've definitely
changed my mind on that one. Now all manner of obsceneties are heard
to eminate from my corner of the room whenever I have to program in a
language which requires me to explicitly delimit blocks @!$*&#!!
Some folks also like the existence of code blocks and iterators in
Ruby, (Well Python has its own kind of iterators now as well,) but
that didn't concern me greatly.
In the end two things persuaded me to go with Python. Firstly I work
in a 'Perl shop' and I'm supposed to write Perl (which I sometimes
do), my using Python was already considered using an "obscure
language," Ruby would have been quite beyond the pale. More
importantly, Ruby just did not have anywhere near the range of
libraries that Python did. Specifically Ruby, at that time, did not
have any sensible way of handling XML (ie no SAX or DOM libraries).
In my opinion, most of the advantages Ruby had over Python seem to
have disappeared as Python has developed.
Asun Friere
> "Brandon J. Van Every" wrote:
>
> > What's better about Ruby than Python? I'm sure there's something.
> > What is
> > it?
>
> Wouldn't it make much more sense to ask Ruby people this, rather than
> Python people?
Maybe he can't speak Japanese?
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> What's better about Ruby than Python?
>
> you. Even if everyone chips in and describes their favourite
> features, those features may be worthless to you personally. So why
> bother asking?
You assume too much. My attitudes and criteria aren't yours. I ask because
it's useful to me, not because it's useful to you.
> Try the languages out yourself, both of them; program a non-trivial
> application in both languages.
I frankly don't have the time, and am not afraid to leverage other people's
experiences to some degree.
> Exactly: so don't ask for others' ideas.
You have a profound difference of philosophy that I don't share. You seem
to think other people's opinions are all or nothing.
Brandon J. Van Every
I can't actually. Didn't know that Ruby was Nippocentric. And no, it
wouldn't make "more sense" to ask the Ruby people this. They are going to
give an answer that's biased from the Ruby perspective. For purposes of
this post, I'm interested in the Python biased perspective.
Michael Peuser
"Brandon J. Van Every" <vane...@3DProgrammer.com> schrieb im Newsbeitrag
news:bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de...
> What's better about Ruby than Python? I'm sure there's something. What
is
> it?
There have been very profound answers in this thread (I like Asun Friere's
and Graham Fowcett's best so far ;-)
I don't know much about Ruby but I did some substantial programming in
Python and Perl. I should now consider side issues more important than
language features itself:
- How fast does the code run
- Is there an acceptable IDE (best: GUI/IDE RAD-Framework)
- Is there a flexible and fast GUI Toolkit
-Can you access OpenGL
- Which platforms are supported
- How easy is multimedia (Sound/Movie in- and output)
- How can you deploy your program
- How large is a self contained EXE file
- Is there mathematical support (array arithmetic, statistical functions,
plotting)
- Is there documentation
- Are there books
Theses questions are quite unordered as they just orrured to me. However it
has turned out that answering them or working around negative answers will
probably cost you more time than any flaws in the language itself....
Kindly
Michael P
Sean 'Shaleh' Perry
> > application in both languages.
>
> I frankly don't have the time, and am not afraid to leverage other people's
> experiences to some degree.
>
> > Exactly: so don't ask for others' ideas.
>
> You have a profound difference of philosophy that I don't share. You seem
> to think other people's opinions are all or nothing.
>
these two statements are the crux of the problem.
If you joined a Chevy car mailing list and asked "what is better about Ford
than Chevy?" would you expect to hear intelligent, insightful responses?
Perhaps you would receive good answers, perhaps not. But if you never
actually looked at a Ford how would you know?
You see, by asking here you have people who have already decided against Ruby
for whatever reason. All we can give you is our reasons for not choosing it.
For balance you would HAVE to ask the Ruby people why they chose it over
something like Python.
Stating "well I just don't have time and would like others to decide for me"
just won't get you very far. Might as well being asking the group to finish
your homework assignments.
BTW, my reason, like many here is Ruby looks like Perl and I prefer Python's
syntax and design approach. Not a very scientific reason, about the same as
saying "well, I like blue ones more than red ones".
Graham Fawcett
>Graham Fawcett wrote:
>
>
>>Brandon J. Van Every wrote:
>>
>>
>>>What's better about Ruby than Python?
>>>
>>>
>>You're never going to get an answer to this question that satisfies
>>you. Even if everyone chips in and describes their favourite
>>features, those features may be worthless to you personally. So why
>>bother asking?
>>
>>
>
>You assume too much. My attitudes and criteria aren't yours. I ask because
>it's useful to me, not because it's useful to you.
>
>
Fair enough. I can only encourage you, in the spirit of collegiality and
goodwill, to emphasise among your attitudes the attitude of personal
research.
For the sake of brevity (not mine alone, but of this thread), let me add
that this point has been previously discussed. A Google Groups search
for "ruby vs. python group:comp.lang.python.*" returns over 250
responses. To assist those who don't like to look things up by
themselves, here's a link:
Notably, see:
In this particular thread, from December 2002, Lyle Johnson points out
"This has been discussed to death in the past and so you should be able
to dig up a lot of information with your search engine of choice."
History does indeed repeat itself!
A more salient discussion on this list -- not just for you, Brandon, but
for everyone -- might entail a review and updating of these older
threads (what's changed in Python and Ruby since Dec 2002?), rather than
a banal rehashing of it. But of course, our criteria vary. ;-)
Yours,
-- Graham
Andrew Dalke
> 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.
Your logic is specious and your observations biased.
Perhaps the programmers "aware of Python" that you know are
more interested in comparing different languages, so know more
about languages in general?
How many Ruby programmers (per capita) do you know talking about
Python? Perhaps Python "has the potential to ...display Ruby"
How many Python-aware programmers do you know who also talk
about Java? Also talk about C#? About C++? About BASIC?
I don't know the programmers you sample from. but looking at c.l.py
since the start of the year, I can give you some numbers about other
languages mentioned. (From Google 'groups' search, numbers are
approximate.)
java group:comp.lang.python from Jan 1, 2003 to today. 1,680
perl group:comp.lang.python from Jan 1, 2003 to today. 1,550
tcl group:comp.lang.python from Jan 1, 2003 to today. 470
pascal group:comp.lang.python from Jan 1, 2003 to today. 295
ruby group:comp.lang.python from Jan 1, 2003 to today. 279
haskell group:comp.lang.python from Jan 1, 2003 to today. 155
eiffel group:comp.lang.python from Jan 1, 2003 to today. 99
rexx group:comp.lang.python from Jan 1, 2003 to today. 99
awk group:comp.lang.python from Jan 1, 2003 to today 58
ocaml group:comp.lang.python from Jan 1, 2003 to today. 26
Based on your logic, you should try pascal or tcl instead of ruby.
Though you really should be using perl or Java.
Of course, percent change is a better metric for up-and-coming,
so here's numbers for all of 2002. To get estimated 2003 numbers I
multiplied the above by 12/8, which means I'm a little on the low side
since August is only half-way through.
2002 2003 change
est. %
Java 2710 2520 - 7
perl 2580 2325 -10
tcl 922 705 -23
pascal 396 442 +12
ruby 542 418 -22
haskell 107 232 +117
eiffel 65 148 +128
rexx 95 148 + 56
awk 93 87 - 6
ocaml 60 39 - 35
Again, you looks like you should use Pascal. Or maybe haskell,
which was talked about a lot more this year already than all of
last year! (I keep meaning to learn some of it.)
So I suspect despite your statement about having no preconceived
ideas about Ruby that you do have some, which sensitises you
to discussions which mention it.
BTW, ruby's numbers on c.l.py for
2003 446 (I used 12/7.5 for a slightly better estimate)
2002 542
2001 487
2000 291
1999 162
1998 4
And Haskell's
2003 248 (ditto on 7.5)
2002 107
2001 282
2000 251
1999 63
1998 7
Given how many more people use Ruby than Haskell and how much
Ruby is mentioned as an alternative to the big 3 of Perl, Python,
and Tcl, it kinda makes you wonder if we aren't just a bunch of
programming language wonks in this group. :) If so, it would again
mean you aren't critical enough of your own beliefs and conclusions.
Andrew
da...@dalkescientific.com
John Roth
"Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message
news:bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de...
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.
Well, each language has to be considered on its own merits; however,
from my rather limited knowledge of Ruby, there are a number of things
I'd like to see in Python. None of them are showstoppers, but some of them
are definite irritations. Other Ruby features either don't make sense in
Python,
or would need a really different implementation.
1. The use of ! and ? as the final character of names to indicate that the
method modifies the object, and that it's a boolean question respectively.
I think the latter is handled adequately by saying "is" in front of the
method
name, but the former directly addresses the [list].append, .sort and
.reverse
idiocy of not returning a value.
2. Treating a module object as a non-instantiable class. This would
eliminate the distinction between methods and functions: everything
would be a method because there would be a well defined meaning
to "self." It also eliminates the need for the global statement.
3. Not having to write "self" in the method definition. This falls out of
item 2: since every function/method has an instance, there's no need to
declare it. I've thought of writing a PEP for this one.
4. Shortcut syntax for writing self in a method body. I don't particularly
like the way it uses capitalization to signal the namespace category (I
think Python does locals a lot better) but there's a lurking mess in
this area that needs to be addressed. (And I don't mean by saluting
it and saying "Yes, SIR!")
5. Blocks. I suspect they got them from Smalltalk, but the syntactic
support for one-time anonamous functions which can contain statements
is one of those things that does seem to make a real difference in
programming style.
6. The way Ruby handles parameterless functions as if they were
properties.
John Roth
John J. Lee
> "Brandon J. Van Every" wrote:
>
> > I frankly don't have the time, and am not afraid to leverage other
> > people's
> > experiences to some degree.
>
> But surely in the time you've been considering the use of Python --
> particularly now, since you claim to have to decided to use it as one of
> your main development languages -- you could have taken a few hours or
> so it would require to read and really absorb the tutorial
Fair comment, but it *is* reasonable to ask about Pythonistas' view of
Ruby -- I don't know why other posters have complained about that.
> (much less,
> of course, if you're already a competent programmer, as you claim to
> be)?
[...]
Much less than a few hours? You're obviously much faster on the
uptake than me...
John
John J. Lee
[...]
> I don't know much about Ruby but I did some substantial programming in
> Python and Perl. I should now consider side issues more important than
> language features itself:
>
> - How fast does the code run
> - Is there an acceptable IDE (best: GUI/IDE RAD-Framework)
> - Is there a flexible and fast GUI Toolkit
> -Can you access OpenGL
> - Which platforms are supported
> - How easy is multimedia (Sound/Movie in- and output)
> - How can you deploy your program
> - How large is a self contained EXE file
> - Is there mathematical support (array arithmetic, statistical functions,
> plotting)
> - Is there documentation
> - Are there books
AFAIK, none of these are distinguishing features between Python and
Perl.
The really major differences are: Perl has tons of library code
(though Python has lots) and Perl has a pile of stuff you have to
learn that brings no significant benefits. It'd be great to see more
research on the impact of the nonsense-overhead that comes with Perl
(and is absent from Python).
John
Roberto Amorim
> properties.
That's the thing I like most about Ruby. But I couldn't get past its
Perl-like syntax and the garbage collector (the latter when mixed with
embedding).
Anyway, since Ruby 1.8.0 is (finally) out, I'll try it again to see if it
can be a viable alternative to Python (at least on some areas), but I doubt
it. Python, as a multiparadigm language, is quite unique on its approach,
and it seems much more fit to large projects than Ruby.
Regards,
Roberto
Michael Peuser
"John J. Lee" <j...@pobox.com> schrieb im Newsbeitrag
news:87ekzj6...@pobox.com...
> "Michael Peuser" <mpe...@web.de> writes:
> [...]
> > I don't know much about Ruby but I did some substantial programming in
> > Python and Perl. I should now consider side issues more important than
> > language features itself:
> >
> > - How fast does the code run
> > - Is there an acceptable IDE (best: GUI/IDE RAD-Framework)
> > - Is there a flexible and fast GUI Toolkit
> > -Can you access OpenGL
> > - Which platforms are supported
> > - How easy is multimedia (Sound/Movie in- and output)
> > - How can you deploy your program
> > - How large is a self contained EXE file
> > - Is there mathematical support (array arithmetic, statistical
functions,
> > plotting)
> > - Is there documentation
> > - Are there books
>
> AFAIK, none of these are distinguishing features between Python and
> Perl.
>
merits of the languages, but of what you can do with them with reasonable
effort.
Those "side issues" I mentioned above (and some more, and some of them not
relevant for everyone) have - this is my experience - influenced my
productivity more than everything else.
Most of the things we do with - especially so called script languages is
inetrfacing library packages. Thoug this is not a feature of the languge it
is most important how to do it, what pachages have already been bound etc
etc. Consider the permanent discussions about what GUI oder IDE to use. The
OpenSource situation is, well unclear. I have learning a lot about that
durung the last two weeks, and I would say: Well perhaps take eric3 and
PyQt. But in fact I have no experience with eric and I very little with Qt.
If all those would be in a state as VB with its Active-X support and quitre
acceptable application framework or - eben better - as compiled RealBasic on
Macintosh with its universal Quicktime interface, then I should say you
could discuss fines language matters. (One should mention Delphi as well.)
But this is not the case.
> The really major differences are: Perl has tons of library code
> (though Python has lots) and Perl has a pile of stuff you have to
> learn that brings no significant benefits. It'd be great to see more
> research on the impact of the nonsense-overhead that comes with Perl
> (and is absent from Python).
Just amount of "library code" is not what matters. You cannot have found it
on my list ;-)
Perl is not much better than Python - I think I did not mention that
explicitly.
Kindly Michael P
>
> John
dan
> 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.
Dude, what is it with you? You must post like 50 msgs a day on this
ng, and I suspect we're not the only target of your "interest". On
another thread you said you haven't actually tried Python because you
don't want to spend the time until you understand if it's worth it.
That is ridiculous, considering you have spent man-months posting to
clp. I was writing code within an hour of downloading.
Download Python, download Ruby, check them out for yourselves. Make
up your own mind instead of depending on others (with whom you rarely
agree anyway).
Just a random suggestion.
Alexander Schmolck
> What's better about Ruby than Python? I'm sure there's something. What is
> it?
>
Since I think this is a reasonable question and I haven't seen to many direct
answer I'll give it a shot.
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, 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.
1. syntactic distinction between destructive and nondestructive methods
(list.sort! vs list.sort)
2. lightweight lambdas (blocks)
3. Generally more OOation (in the style of Smalltalk), if you think that's
good (doesn't make functional programming easier, for example).
The class hierachies are certainly cleaner and, thanks to 'modules' (viz.
mixins), have less duplication. In python, for example there is no
reasonable way to find out whether something is a Mapping, or a number and
classes that should be taxonmically connected aren't and thus reduplicate
code (or just miss random features; e.g. both `str` and `list` have methods
that the other one could do with; in ruby this is handled by the
Enumeration module)
5. continuations, should you so desire.
6. An interesting attempt at an OO case statement.
I should add that 1. and 2. are however inexcusably flawed, especially since
they are really just (badly) adapted from scheme and smalltalk, respectively:
irb(main):001:0> [1,2].sort
[1, 2]
irb(main):002:0> [1,2].sort!
[1, 2]
irb(main):003:0> [1].sort
[1]
irb(main):004:0> [1].sort!
nil
^^^ !!!
irb(main):017:0> x = 10
10
irb(main):018:0> [1,2,3].reject {|x| x < 2}
[2, 3]
irb(main):019:0> x
3
This together with some other symptoms (what the hell is the point of having
Array.assoc?) gives me the overall impression that Ruby is an uglified
smalltalk, hideously disguised as Perl for mainstream appeal with some random
scheme features on top crafted by someone who doesn't seem to have quite
understood either smalltalk or scheme. OTOH, smalltalk and scheme at least
aren't such bad languages to steal from (even badly) and Ruby has one
worthwhile feature over (standard) smalltalk, mixins (there is BTW, some
interesting work in the squeak community on 'traits').
'as
Alex Martelli
> "Brandon J. Van Every" wrote:
>
>> What's better about Ruby than Python? I'm sure there's something.
>> What is it?
>
> Wouldn't it make much more sense to ask Ruby people this, rather than
> Python people?
Might, or might not, depending on one's purposes -- for example, if
one's purposes include a "sociological study" of the Python community,
then putting questions to that community is likely to prove more
revealing of informaiton about it, than putting them elsewhere:-).
Personally, I gladly took the opportunity to follow Dave Thomas'
one-day Ruby tutorial at last OSCON. Below a thin veneer of syntax
differences, I find Ruby and Python amazingly similar -- if I was
computing the minimum spanning tree among just about any set of
languages, I'm pretty sure Python and Ruby would be the first two
leaves to coalesce into an intermediate node:-).
Sure, I do get weary, in Ruby, of typing the silly "end" at the end
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
differences such as '@foo' versus 'self.foo', or the higher significance
of case in Ruby vs Python, are really just about as irrelevant to me.
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).
One syntax difference that I do find important, and in Python's
favour -- but other people will no doubt think just the reverse --
is "how do you call a function which takes no parameters". In
Python (like in C), to call a function you always apply the
"call operator" -- trailing parentheses just after the object
you're calling (inside those trailing parentheses go the args
you're passing in the call -- if you're passing no args, then
the parentheses are empty). This leaves the mere mention of
any object, with no operator involved, as meaning just a
reference to the object -- in any context, without special
cases, exceptions, ad-hoc rules, and the like. In Ruby (like
in Pascal), to call a function WITH arguments you pass the
args (normally in parentheses, though that is not invariably
the case) -- BUT if the function takes no args then simply
mentioning the function implicitly calls it. This may meet
the expectations of many people (at least, no doubt, those
whose only previous experience of programming was with Pascal,
or other languages with similar "implcit calling", such as
Visual Basic) -- but to me, it means the mere mention of an
object may EITHER mean a reference to the object, OR a call
to the object, depending on the object's type -- and in those
cases where I can't get a reference to the object by merely
mentioning it I will need to use explicit "give me a reference
to this, DON'T call it!" operators that aren't needed otherwise.
I feel this impacts the "first-classness" of functions (or
methods, or other callable objects) and the possibility of
interchanging objects smoothly. Therefore, to me, this specific
syntax difference is a serious black mark against Ruby -- but
I do understand why others would thing otherwise, even though
I could hardly disagree more vehemently with them:-).
Below the syntax, we get into some important differences in
elementary semantics -- for example, strings in Ruby are
mutable objects (like in C++), while in Python they are not
mutable (like in Java, or I believe C#). Again, people who
judge primarily by what they're already familiar with may
think this is a plus for Ruby (unless they're familiar with
Java or C#, of course:-). Me, I think immutable strings are
an excellent idea (and I'm not surprised that Java, independently
I think, reinvented that idea which was already in Python), though
I wouldn't mind having a "mutable string buffer" type as well
(and ideally one with better ease-of-use than Java's own
"string buffers"); and I don't give this judgment because of
familiarity -- before studying Java, apart from functional
programming languages where _all_ data are immutable, all the
languages I knew had mutable strings -- yet when I first saw
the immutable-string idea in Java (which I learned well before
I learned Python), it immediately struck me as excellent, a
very good fit for the reference-semantics of a higher level
programming language (as opposed to the value-semantics that
fit best with languages closer to the machine and farther from
applications, such as C) with strings as a first-class, built-in
(and pretty crucial) data type.
Ruby does have some advantages in elementary semantics -- for
example, the removal of Python's "lists vs tuples" exceedingly
subtle distinction. 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
intervals, with the notations a..b and a...b [anybody wants
to claim that it's _obvious_ which is which?-)], is silly --
IMHO, of course!). Again, people who consider having a lot of
similar but subtly different things at the core of a language
a PLUS, rather than a MINUS, will of course count these "the
other way around" from how I count them:-).
Don't be misled by these comparisons into thinking the two
languages are _very_ different, mind you. They aren't. But
if I'm asked to compare "capelli d'angelo" to "spaghettini",
after pointing out that these two kinds of pasta are just
about undistinguishable to anybody and interchangeable in any
dish you might want to prepare, I would then inevitably have
to move into microscopic examination of how the lengths and
diameters imperceptibly differ, how the ends of the strands
are tapered in one case and not in the other, and so on -- to
try and explain why I, personally, would rather have capelli
d'angelo as the pasta in any kind of broth, but would prefer
spaghettini as the pastasciutta to go with suitable sauces for
such long thin pasta forms (olive oil, minced garlic, minced
red peppers, and finely ground anchovies, for example - but if
you sliced the garlic and peppers instead of mincing them, then
you should choose the sounder body of spaghetti rather than the
thinner evanescence of spaghettini, and would be well advised
to forego the achoview and add instead some fresh spring basil
[or even -- I'm a heretic...! -- light mint...] leaves -- at
the very last moment before serving the dish). Ooops, sorry,
it shows that I'm traveling abroad and haven't had pasta for
a while, I guess. But the analogy is still pretty good!-)
So, back to Python and Ruby, we come to the two biggies (in
terms of language proper -- leaving the libraries, and other
important ancillaries such as tools and environments, how to
embed/extend each language, etc, etc, out of it for now -- they
wouldn't apply to all IMPLEMENTATIONS of each language anyway,
e.g., Jython vs Classic Python being two implementations of
the Python language!):
1. Ruby's iterators and codeblocks vs Python's iterators
and generators;
2. Ruby's TOTAL, unbridled "dynamicity", including the ability
to "reopen" any existing class, including all built-in ones,
and change its behavior at run-time -- vs Python's vast but
_bounded_ dynamicity, which never changes the behavior of
existing built-in classes and their instances.
Personally, I consider [1] a wash (the differences are so
deep that I could easily see people hating either approach
and revering the other, but on MY personal scales the pluses
and minuses just about even up); and [2] a crucial issue --
one that makes Ruby much more suitable for "tinkering", BUT
Python equally more suitable for use in large production
applications. It's funny, in a way, because both languages
are so MUCH more dynamic than most others, that in the end
the key difference between them from my POV should hinge on
that -- that Ruby "goes to eleven" in this regard (the
reference here is to "Spinal Tap", of course). In Ruby,
there are no limits to my creativity -- if I decide that
all string comparisons must become case-insensitive, _I CAN
DO THAT_! I.e., I can dynamically alter the built-in string
class so that
a = "Hello World"
b = "hello world"
if a == b
print "equal!\n"
else
print "different!\n"
end
WILL print "equal". In python, there is NO way I can do
that. For the purposes of metaprogramming, implementing
experimental frameworks, and the like, this amazing dynamic
ability of Ruby is _extremely_ appealing. BUT -- if we're
talking about large applications, developed by many people
and maintained by even more, including all kinds of libraries
from diverse sources, and needing to go into production in
client sites... well, I don't WANT a language that is QUITE
so dynamic, thank you very much. I loathe the very idea of
some library unwittingly breaking other unrelated ones that
rely on those strings being different -- that's the kind of
deep and deeply hidden "channel", between pieces of code that
LOOK separate and SHOULD BE separate, that spells d-e-a-t-h
in large-scale programming. By letting any module affect the
behavior of any other "covertly", the ability to mutate the
semantics of built-in types is just a BAD idea for production
application programming, just as it's cool for tinkering.
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
would be an even better language for application programming
if a certain number of built-ins could be "nailed down", so
I KNEW that, e.g., len("ciao") is 4 (rather than having to
worry subliminally about whether somebody's changed the
binding of name 'len' in the __builtins__ module...). I do
hope that eventually Python does "nail down" its built-ins.
But the problem's minor, since rebinding built-ins is quite
a deprecated as well as a rare practice in Python. In Ruby,
it strikes me as major -- just like the _too powerful_ macro
facilities of other languages (such as, say, Dylan) present
similar risks in my own opinion (I do hope that Python never
gets such a powerful macro system, no matter the allure of
"letting people define their own domain-specific little
languages embedded in the language itself" -- it would, IMHO,
impair Python's wonderful usefulness for application
programming, by presenting an "attractive nuisance" to the
would-be tinkerer who lurks in every programmer's heart...).
Alex
Terry Reedy
"John Roth" <newsg...@jhrothjr.com> wrote in message
news:vk1c89j...@news.supernews.com...
> 4. Shortcut syntax for writing self in a method body.
If you declare the first param as 's', for instance, then your
shortcut is 's.', which is pretty minimal, and hardly enough, it seems
to me, to make much fuss over. I like having a clean visual
separation between local variables and instance attributes.
TJR
Peter Hansen
>
> it?
>
> This is not a troll.
An observation: Brandon seems particularly incapable of posting anything
that is *not* a troll.
On the plus side, he didn't cross-post it...
Please, someone, teach the guy about Google.
-Peter "already in his killfile" Hansen
Borcis
> Me, I think immutable strings are
> an excellent idea (and I'm not surprised that Java, independently
> I think, reinvented that idea which was already in Python)
IIRC Applesoft Basic on the Apple II had immutable strings,
way back in the late seventies.
Alex Martelli
...
> 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).
> 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!'
>>>
Isn't this "redefining classes at runtime // instances automatically
get updated", too? If you want to redefine a bunch of entries in X,
rather than just a few, X.__dict__.update(someotherdict) -- or even,
shudder, reassigning X.__dict__ altogether... -- may perhaps be
preferable, but I personally like the explicitness of assignments
for most cases of such (rare) tasks.
Alex
Alexander Schmolck
> (I do hope that Python never gets such a powerful macro system, no matter
> the allure of "letting people define their own domain-specific little
> languages embedded in the language itself" -- it would, IMHO, impair
> Python's wonderful usefulness for application programming, by presenting an
> "attractive nuisance" to the would-be tinkerer who lurks in every
> programmer's heart...).
I don't think a powerful but potentially dangerous feature poses much of a
problem as long as there is little danger of inadvertently using it and little
incentive to inappropriately use it (e.g. you could do all sorts of stupid
things in python, like redefining __builtins__.len, but generally there isn't
much of an incentive to do so, so many of the reasons why e.g. Java
programmers might think python an unsuitable language for larger projects
don't really apply in practice. My feeling is this *not* true to the same
extent for ruby, where similar things are both encouraged and, if I don't
misremember, can happen inadvertently).
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?
'as
Tom
> This is not a troll.
"I am not a crook." R.Nixon
Don't waste yr time feeding the trolls. (unless it amuses you)
If you feel I'm being hard on the prolific Mr. Avery, do a search on
his posts and decide for yourself. My personal opinion is that he,
like any troll, wastes valuable c.l.p. cycles.
If I remember correctly, a recent Avery post said he was finished with
the c.l.p. group (oh, darn) and was moving on the the marketing-python
mailing list. Guess he's back.
Tom
John Roth
"Terry Reedy" <tjr...@udel.edu> wrote in message
news:b8GdnQTH7Ka...@comcast.com...
This particular issue has been debated a number of times, and one
of the answers that always comes up is the one you trot out.
Just about everyone uses "self" for good reason: everyone else
uses "self", so it communicates its meaning clearly. If everyone
suddenly decided to use their own terms, program readability
would go down across the board; unless, of course, the only
programs you read are your own.
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.
John Roth
>
> TJR
>
>
Brandon J. Van Every
>
> If you joined a Chevy car mailing list and asked "what is better
> about Ford than Chevy?" would you expect to hear intelligent,
> insightful responses? Perhaps you would receive good answers, perhaps
> not. But if you never actually looked at a Ford how would you know?
Let me make myself as clear as I can. I am not the slightest bit interested
in yours or anyone else's philosophy of whether I should have asked the
question, or what manner I should have asked it. I asked a very simple
question, and in some cases was rewarded with very simple, helpful answers.
Whereas this meta-debate is a complete waste of time.
> BTW, my reason, like many here is Ruby looks like Perl and I prefer
> Python's syntax and design approach. Not a very scientific reason,
> about the same as saying "well, I like blue ones more than red ones".
Thanks for the info. You seem to agree with the Ruby FAQ on this point,
that the langauges have different design styles and people may prefer one or
the other. IMO this isn't a "better" because I'm a pragmatist. My rating
for stylism is "is it much less painful than C++ ?" If so then I don't
care.
Brandon J. Van Every
>
> How many Ruby programmers (per capita) do you know talking about
> Python? Perhaps Python "has the potential to ...display Ruby"
I don't know many. Anecdotally, though, it's clear that Ruby has mindshare.
It's on the radar of everyone I've talked to who knows about Python.
Thanks for the statistics. It didn't address the subject line, but it was
interesting.
Brandon J. Van Every
>
> Dude, what is it with you?
>
> up your own mind instead of depending on others (with whom you rarely
> agree anyway).
Why do you assume that I'm asking these questions in order to understand how
to program in either? I want to know what people's *perceptions* are.
Subscribe to marketing-python if you want to puzzle me out more.
Brandon J. Van Every
>
> Don't be misled by these comparisons into thinking the two
> languages are _very_ different, mind you. They aren't. But
> if I'm asked to compare "capelli d'angelo" to "spaghettini",
> after pointing out that these two kinds of pasta are just
> about undistinguishable to anybody and interchangeable in any
> dish you might want to prepare, I would then inevitably have
> to move into microscopic examination of how the lengths and
> diameters imperceptibly differ, how the ends of the strands
> are tapered in one case and not in the other, and so on -- to
> try and explain why I, personally, would rather have capelli
> d'angelo as the pasta in any kind of broth, but would prefer
> spaghettini as the pastasciutta to go with suitable sauces for
> such long thin pasta forms (olive oil, minced garlic, minced
> red peppers, and finely ground anchovies, for example - but if
> you sliced the garlic and peppers instead of mincing them, then
> you should choose the sounder body of spaghetti rather than the
> thinner evanescence of spaghettini, and would be well advised
> to forego the achoview and add instead some fresh spring basil
> [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.
> Ooops, sorry,
> it shows that I'm traveling abroad and haven't had pasta for
> a while, I guess. But the analogy is still pretty good!-)
What I take away from it, is Python and Ruby are far more similar than
different. So then one looks at industrial evolution - GUIs, tools,
community size, marketing, volunteer organization, mainstream commercial
use. Python is clearly much farther along than Ruby.
> 2. Ruby's TOTAL, unbridled "dynamicity", including the ability
> to "reopen" any existing class, including all built-in ones,
> and change its behavior at run-time -- vs Python's vast but
> _bounded_ dynamicity, which never changes the behavior of
> existing built-in classes and their instances.
Others have mentioned this. I imagine it would be a big ticket item for
some. I can't figure out why I'd care myself, but maybe as I get into my
diplomacy AI, I will.
> BUT Python equally more suitable for use in large production
> applications.
Yes, this definitely matters from 10,000 miles up.
Brandon J. Van Every
>
> 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. When you grab that code, you're not really going to want to do
the work of making more specific 'use_custom_syntax' directives, as it would
break in all sorts of subtle ways. So now the 'culture of feature'
supplants the culture of control. The same could happen in a big commerical
project, for that matter. Thus it may be wise not to allow this kind of
customization at all.
Andrew Dalke
> Thanks for the statistics. It didn't address the subject line, but it was
> interesting.
Wasn't meant to. It was saying that you you have flawed reasons
for your search. Either you do have ulterior motives for asking
your question (be it a post-hoc justification for your interest, poor
critical thinking skills, self-aggrandizement, or simple troll
bait) or, if it really reflects your thoughts on what languages to
evalutate then you should be looking at Haskell.
Andrew
da...@dalkescientific.com
Brandon J. Van Every
>
> The really major differences are: Perl has tons of library code
> (though Python has lots) and Perl has a pile of stuff you have to
> learn that brings no significant benefits. It'd be great to see more
> research on the impact of the nonsense-overhead that comes with Perl
> (and is absent from Python).
Don't leave out the possibility that cults of expertise can sustain careers
and book publishers.
John J. Lee
Yes.
> Those "side issues" I mentioned above (and some more, and some of them not
> relevant for everyone) have - this is my experience - influenced my
> productivity more than everything else.
Sure. What does that have to do with the *comparison* between Perl
and Python, though? My claim was that these things are pretty much
the same on both.
> Most of the things we do with - especially so called script languages is
> inetrfacing library packages. Thoug this is not a feature of the languge it
> is most important how to do it, what pachages have already been bound etc
> etc. Consider the permanent discussions about what GUI oder IDE to use. The
> OpenSource situation is, well unclear. I have learning a lot about that
> durung the last two weeks, and I would say: Well perhaps take eric3 and
> PyQt. But in fact I have no experience with eric and I very little with Qt.
Where's your point here? You seem to have slipped into a comparison
of Windows and Open Source. My post was a reply to your Perl / Python
comparison.
> If all those would be in a state as VB with its Active-X support and quitre
> acceptable application framework or - eben better - as compiled RealBasic on
> Macintosh with its universal Quicktime interface, then I should say you
> could discuss fines language matters. (One should mention Delphi as well.)
This comes over as a troll, so I shan't bother to answer.
> But this is not the case.
>
> > The really major differences are: Perl has tons of library code
> > (though Python has lots) and Perl has a pile of stuff you have to
> > learn that brings no significant benefits. It'd be great to see more
> > research on the impact of the nonsense-overhead that comes with Perl
> > (and is absent from Python).
>
>
> Just amount of "library code" is not what matters.
Where did I say that? Not sure why library code requires scare
quotes, either...
> You cannot have found it
> on my list ;-)
I still don't, if we're talking about *differences*. (With the
possible exception of 'how easy is multimedia' -- I don't know enough
about that to say).
John
Borcis
>
> 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.
>
This sets a specific target to an obfuscated python context :
Illustrate the freedom that python gives you to replace the name
of "self" in methods by any identifier you want, with a piece of
code designed to put the collision between class variables and the
name actually used in the method source as a replacement to "self",
into a functional role as a part of the main loop.
Or something comparable :)
Andrew Dalke
> Why do you assume that I'm asking these questions in order to
> understand how to program in either?
When you said at the start of this thread:
> I'm language shopping and I want people's answers.
You didn't say you were language window shopping.
> I want to know what people's *perceptions* are.
Nothing said in the last few days from either your C# thread or
your Ruby thread has raised anything new, and a trivial Google
groups search would have given you not only information about
perception but the ability to gauge trends in that perception.
If you were serious about this, you would *start* by giving
the results of your analysis, along with points which you think
need further clarification and point out weak points in your
thinking. You should not make the assumption that people
will do this for you, and given your poor reasoning skills, it's
unlikely that even if people did that you would miss the answer.
Instead, you make people like me just more and more annoyed
about your posts.
> Subscribe to marketing-python if you want to puzzle me out more.
Or not. Word on the net is that you've raised a whole bunch of
bluster there.
Andrew
da...@dalkescientific.com
Erik Max Francis
> Much less than a few hours? You're obviously much faster on the
> uptake than me...
To read and usefully absorb the tutorial in only an hour? That seems
quite feasible for an experienced programmer.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Principles have no real force except when one is well fed.
\__/ Mark Twain
William Trenker
Andrew Dalke <ada...@mindspring.com> wrote regarding Re: What's better about Ruby than Python?:
> java group:comp.lang.python from Jan 1, 2003 to today. 1,680
> perl group:comp.lang.python from Jan 1, 2003 to today. 1,550
> tcl group:comp.lang.python from Jan 1, 2003 to today. 470
[etc.]
c++ group:comp.lang.python from 1 Jan 2003 to today. 2,630
(for what it's worth)
Bill
Lulu of the Lotus-Eaters
|> This is not a troll.
The first surest sign that a post is a troll is if the author is:
Erik Max Francis
> Why do you assume that I'm asking these questions in order to
> understand how
> to program in either? I want to know what people's *perceptions* are.
> Subscribe to marketing-python if you want to puzzle me out more.
Why do you need to understand _other_ peoples' perceptions, general
marketing trends, and Python marketshare in order to learn it? You've
already evidently (from your post here and in other groups recently)
decided that you're going to go with Python -- at least that's what you
claim, I'm not entirely convinced -- so why aren't you learning the
language instead of all these other irrelevant things?
If you've truly decided that you're going to use Python, why aren't you
learning the _language_ now -- something you've been putting off for
years -- instead of hunting down all these red herrings?
Andrew Dalke
> c++ group:comp.lang.python from 1 Jan 2003 to today. 2,630
>
> (for what it's worth)
Relevant for the OP's thoughts.
I also tried C#, but then wondered if google would have problems
with non-text characters, and if not, if the search for C++ would
be biased by
int c = 0;
...
c++;
I also excluded 'basic' since it's too often used in other contexts.
And I totally left out lisp and scheme.
Now to confuse searches for the future: snobol, jovial, ada,
rebol, smalltalk, dylan, occam, objective c, apl, J, K, and
cobol. :)
Andrew
da...@dalkescientific.com
Harry George
Yes, it is a problem under any circumstances.
"The first step in writing a macro is to recognize that every time you
write one, you are defining a new language". P. Norvig, "Paradigms of
Artificial Intelligence Programming", c 1992, pg 66.
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).
The python language is just fine as is. 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.
--
harry.g...@boeing.com
6-6M31 Knowledge Management
Phone: (425) 342-5601
John Wilson
> Me, I think immutable strings are
> an excellent idea (and I'm not surprised that Java, independently
> I think, reinvented that idea which was already in Python),
Gosling claims that Java contains no new ideas. I have heard him say that
every feature of Java is in at least two other programming languages. Java
takes many things from CLU (including immutable strings). CLU looks to be an
influence on Python too.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Doug Tolton
<vane...@3DProgrammer.com> wrote:
>Let me make myself as clear as I can. I am not the slightest bit interested
>in yours or anyone else's philosophy of whether I should have asked the
>question, or what manner I should have asked it. I asked a very simple
>question, and in some cases was rewarded with very simple, helpful answers.
>Whereas this meta-debate is a complete waste of time.
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.
It's interesting to note that you could've pre-empted the question by
saying either "I've also posted this to the Ruby group, but I wanted
your take" or "The Ruby group is a bunch of dunder heads and I only
like Python programmers" etc. However your ranting and whining about
people not answering the question to your satisfaction is amusing.
Beggars can't be choosers my friend. You posted an antagonistic
question to the Python board, expect to get antagonistic responses.
Clearly people don't care if they are answering your question in a way
that is suitable and appealing to you.
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
John Roth
"Andrew Dalke" <ada...@mindspring.com> wrote in message
news:bhq501$a98$1...@slb6.atl.mindspring.net...
> How many Ruby programmers (per capita) do you know talking about
> Python? Perhaps Python "has the potential to ...display Ruby"
You might try getting onto some other newsgroups and mailing
lists that deal with more general (not language specific) issues and
find out exactly what people are saying. On the XP mailing lists
my general impression is that the Ruby programmers outnumber
the Python programmers, and a fair number of them came from
a Python background.
> How many Python-aware programmers do you know who also talk
> about Java? Also talk about C#? About C++? About BASIC?
Lots. Most of the people on the XP lists use multiple languages,
and are quite vocal about it in the appropriate circumstances.
John Roth
John J. Lee
> "John J. Lee" wrote:
>
> > Much less than a few hours? You're obviously much faster on the
> > uptake than me...
>
> To read and usefully absorb the tutorial in only an hour? That seems
> quite feasible for an experienced programmer.
[...]
Like I said. :-) Took me an afternoon.
Mind you, I am the type who, when faced with a new language, tends to
read everything slowly, chew the cud, *then* start writing. I read
the whole of Stroustrup and a couple of other books before writing a
line of C++ -- not an approach I recommend to others, but if I had to
do it again (heaven forfend), I'd do the same.
John
John J. Lee
> William Trenker:
> > c++ group:comp.lang.python from 1 Jan 2003 to today. 2,630
> >
> > (for what it's worth)
>
> Relevant for the OP's thoughts.
>
> I also tried C#, but then wondered if google would have problems
> with non-text characters, and if not, if the search for C++ would
> be biased by
>
> int c = 0;
> ...
> c++;
[...]
Alex Martelli a while ago posted his way of doing language searches on
Google -- searching for phrases like "x programmer", "x program", "x
code" etc. (including quotes): substitute the name of your favorite
language for x. Cuts out spurious stuff like 'c++;' (though in that
particular case I expect the systematic error introduced would be
small). There are interesting differences between the various terms:
the more 'commercial' languages tend to turn up more hits for "x
programmer" than the less-commercial ones, for example. As a whole, a
bunch of such searches tells you more than any individual one would.
Would be fun to write a Google API script, keep records, and put up a
page to plot graphs of some simple metrics... No doubt somebody has
done it already.
Somewhere, I came across somebody who had graphed nr. of Amazon books
over the years, by programming language, with a neat web interface
(maybe that was pointed to by Alex's post, can't remember). IIRC, it
breaks when you select Java -- too many books! The statistics were
good enough to make it quite interesting, though of course the number
of years availble was quite small.
John
Roy Smith
> I do hope that Python never gets such a powerful macro system
I'm with Alex on this. Macros suck. What you usually end up with is
essentially two different languages, with different syntaxes, and which
don't interract very well. If nothing else, this really screws up emacs
auto-indenting :-(
One of the few things I like about C++ is that between const, templates,
and inline, the need for the macro preprocessor has been almost
eliminated. Still, you see a lot of code which goes out of its way to
do fancy things with macros, almost always with bad effect.
I don't even want to talk about the various systems which make use of
things like m4.
Why do you need macros? There's a few things people do with them:
1) Define constants. In Python, you just define symbols in your module,
and get over the fact that there really is no such thing as a constant
in Python.
2) Define efficient pseudo-functions. In Python, you just define a
function (or method) and get over the fact that it's not as efficient as
a macro. If I cared about microseconds, I wouldn't be writing in Python.
3) File inclusion. In Python, you don't include files, you import
modules.
4) Conditional compilation. In Python, you can conditionally define
anything you want at import time.
5) Inventing your own language constructs. In Python, you just don't do
this.
John J. Lee
> > 6. The way Ruby handles parameterless functions as if they were
> > properties.
>
> That's the thing I like most about Ruby. But I couldn't get past its
[...]
Appeals to me too, but, when it comes right down to it, the only
reason I'm using Python and not Perl is that it has a really
significant reduction in baggage. There just is no such difference
between Python and Ruby, according to everything I've heard people put
forward here as 'significant'. Python has more users. Nothing more
to be said, as far as I'm concerned.
I really wish I could say more for Ruby, as I'd very much like to
sound less like a closed-minded programming language-monoglot.
In my defence, like lots of people here I'm eager to learn Haskell and
O'Caml, not to mention a bunch of others -- if only Python didn't do
almost everything so well, there'd be more motivation...
John
Bengt Richter
[...]
>
>One syntax difference that I do find important, and in Python's
>favour -- but other people will no doubt think just the reverse --
>is "how do you call a function which takes no parameters". In
>Python (like in C), to call a function you always apply the
>"call operator" -- trailing parentheses just after the object
>you're calling (inside those trailing parentheses go the args
>you're passing in the call -- if you're passing no args, then
>the parentheses are empty). This leaves the mere mention of
>any object, with no operator involved, as meaning just a
>reference to the object -- in any context, without special
>cases, exceptions, ad-hoc rules, and the like. In Ruby (like
>in Pascal), to call a function WITH arguments you pass the
>args (normally in parentheses, though that is not invariably
>the case) -- BUT if the function takes no args then simply
>mentioning the function implicitly calls it. This may meet
>the expectations of many people (at least, no doubt, those
>whose only previous experience of programming was with Pascal,
>or other languages with similar "implcit calling", such as
>Visual Basic) -- but to me, it means the mere mention of an
>object may EITHER mean a reference to the object, OR a call
>to the object, depending on the object's type -- and in those
>cases where I can't get a reference to the object by merely
>mentioning it I will need to use explicit "give me a reference
>to this, DON'T call it!" operators that aren't needed otherwise.
>I feel this impacts the "first-classness" of functions (or
>methods, or other callable objects) and the possibility of
>interchanging objects smoothly. Therefore, to me, this specific
>syntax difference is a serious black mark against Ruby -- but
>I do understand why others would thing otherwise, even though
>I could hardly disagree more vehemently with them:-).
>
This is interesting, because I presume you are happy with properties ;-)
So is this basically a thing about the global namespace? I.e., if
we had way to introduce a subclassed module types into the import
mechanism, we could have module properties, which presumbaly could
be accessed much like parameterless Pascal functions.
Regards,
Bengt Richter
Aahz
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.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz
Brandon J. Van Every
> "Brandon J. Van Every" <vane...@3DProgrammer.com> wrote in message
> news:<bhpbc6$1plpe$1...@ID-203719.news.uni-berlin.de>...
>
>> This is not a troll.
>
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.
Roy Smith
> I read the whole of Stroustrup and a couple of other books
> before writing a line of C++
You're a sick puppy :-)
Brandon J. Van Every
>
> 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.
sism...@hebmex.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.
>
Ahh, yes, Mr. Rue... It's been a while since he's dropped by
for a visit :-)
I think like you Aahz, that people's dumping way to harsh-like
on Brandon. And it's strange to me, because normally people's
much more polite here than elsewhere; I wonder what's squishing
everyone's balls so tight to make them so.
:-/
Sad.
-gus
Advertencia:La informacion contenida en este mensaje es confidencial y
restringida, por lo tanto esta destinada unicamente para el uso de la
persona arriba indicada, se le notifica que esta prohibida la difusion de
este mensaje. Si ha recibido este mensaje por error, o si hay problemas en
la transmision, favor de comunicarse con el remitente. Gracias.
Michele Simionato
news:<vk1c89j...@news.supernews.com>...
> 3. Not having to write "self" in the method definition. This falls out of
> item 2: since every function/method has an instance, there's no need to
> declare it. I've thought of writing a PEP for this one.
Out of curiosity: how does Ruby manages inner classes like this?
class MyClass(object):
def __init__(self,x):
class InnerClass(object):
def __init__(innerself,a):
innerself.a=a
self.b=2*a
self.x=InnerClass(x)
c=MyClass(1)
print c.x.a # =>1
print c.b # =>2
an-ex-enemy-of-self-now-converted-ly-your's
Michele
Brandon J. Van Every
> "Michael Peuser" <mpe...@web.de> writes:
>>
>> If all those would be in a state as VB with its Active-X support and
>> quitre acceptable application framework or - eben better - as
>> compiled RealBasic on Macintosh with its universal Quicktime
>> interface, then I should say you could discuss fines language
>> matters. (One should mention Delphi as well.)
>
> This comes over as a troll, so I shan't bother to answer.
You know, people would get along a lot better if they didn't have the
intellectually lazy habit of "troll hunting." When people express their
opinions about pros and cons, they are not trolling. You have to allow for
other people's opinions. Use your imagination: if you were in their shoes,
why mightn't you see things that way, or ask a question that way?
Brandon J. Van Every
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.
Brandon J. Van Every
> "Andrew Dalke" <ada...@mindspring.com> wrote in message
> news:bhq501$a98$1...@slb6.atl.mindspring.net...
>
>> How many Ruby programmers (per capita) do you know talking about
>> Python? Perhaps Python "has the potential to ...display Ruby"
>
> You might try getting onto some other newsgroups and mailing
> lists that deal with more general (not language specific) issues and
> find out exactly what people are saying. On the XP mailing lists
> my general impression is that the Ruby programmers outnumber
> the Python programmers, and a fair number of them came from
> a Python background.
Interesting anecdote and exercise suggestion. I will undertake it. For
instance, what if Windows tools support is better under Ruby than Python?
That's a hypothetical, I have no idea.
Doug Tolton
>Why do you need macros? There's a few things people do with them:
>
>1) Define constants. In Python, you just define symbols in your module,
>and get over the fact that there really is no such thing as a constant
>in Python.
>
>2) Define efficient pseudo-functions. In Python, you just define a
>function (or method) and get over the fact that it's not as efficient as
>a macro. If I cared about microseconds, I wouldn't be writing in Python.
>
>3) File inclusion. In Python, you don't include files, you import
>modules.
>
>4) Conditional compilation. In Python, you can conditionally define
>anything you want at import time.
>
>5) Inventing your own language constructs. In Python, you just don't do
>this.
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.
Good Lisp programmers use Macros all the time. They are incredibly
useful and powerful. The reason you don't do this in python is
because the feature isn't available. That doesn't mean it *shouldn't*
be available. Python is Open Source, how would someone writing a
Macro lock you in? Just don't use the macro.
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. Essentially using Python over Machine
language is just using one big ass macro language. They are there to
allow you to create higher level abstractions, and tools that are more
specifically useful to your application domain than a general purpose
tool.
Python is a Macro Language of Machine Language. Why don't you just
program everything in Machine Language? Macros are to Python as
Python is to C as C is to Machine Language.
Python is great, as the trend shows, working at higher levels of
abstraction though is the ultimate goal.
Erik Max Francis
> 5) Inventing your own language constructs. In Python, you just don't
> do
> this.
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
Python, translation often strikes me as superior to incorporating
macros.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ I want a martini that could be declared a disaster area.
\__/ Capt. Benjamin "Hawkeye" Pierce
Erik Max Francis
> You know, people would get along a lot better if they didn't have the
> intellectually lazy habit of "troll hunting." When people express
> their
> opinions about pros and cons, they are not trolling.
But don't you find it interesting that an anomalously large percentage
of people you encounter on Usenet -- the reaction of comp.lang.python is
not at all atypical -- conclude that you're trolling? Since this has
happened over and over again, ad infintum and ad nauseum, across all of
Usenet, everywhere you go, and doesn't happen with nearly that much
frequency to others, wouldn't it be reasonable to conclude there _might_
just possibly be something bad about your approach, particularly if you
sincerely don't intend to troll?
Aren't you just a little bit curious about why this keeps happening to
you?
Brandon J. Van Every
>
> I think like you Aahz, that people's dumping way to harsh-like
> on Brandon. And it's strange to me, because normally people's
> much more polite here than elsewhere; I wonder what's squishing
> everyone's balls so tight to make them so.
Well, I'll freely own up to being rude and intellectually violent. I don't
feel like being "PC" about certain basic questions, I'm a pragmatic
programmer and I call a spade a spade. But that doesn't make me a troll.
It's annoying when people can't/won't tell the difference. The sheer volume
of questions I've asked about Python should indicate to any impartial
observer that I actually do care about the answers. And if that isn't
sufficiently convincing, you might try checking the marketing-python
archives.
Alexander Schmolck
> 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
John J. Lee
[...]
> 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
Alexander Schmolck
> 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'
cf.:
irb(main):001:0> class X
irb(main):002:1> def amethod
irb(main):003:2> puts "just a method"
irb(main):004:2> end
irb(main):005:1> end
nil
irb(main):006:0> x = new X
irb(main):021:0> class X
irb(main):022:1> def amethod
irb(main):023:2> puts "Ah, this is better."
irb(main):024:2> end
irb(main):025:1> end
nil
irb(main):026:0> x.amethod
Ah, this is better.
nil
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.
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.
The fact that you can't easily update your instances (after all first you
gotta find then and secondly, as mentioned above even if you do you might run
into trouble) isn't that much of a problem if your progam takes about 5
seconds to run. If it takes 48 hours and you notice that you need to change a
method definition after you've got almost all the results in, you're in for
quite a bit of fun (or at least I have been, possibly due to ignorance).
I think this sucks pretty badly, even more so than the fact that I don't know
of a decent way to fix things if an exception occurs somehwere (again imagine
in the second to last line, after 48h of computations; this is not
hypothetical, as I'm sure you as an ex-Fortran (and hence I'd guess numerics)
programmer will appreciate). Maybe you can pickle some things if you are
careful and do an immedidate postmortem with pdb, without making a silly typo
first that will raise another exception and cost you all the previous
exception state you desperately needed, but this is really far from ideal.
> Isn't this "redefining classes at runtime // instances automatically
> get updated", too? If you want to redefine a bunch of entries in X,
> rather than just a few, X.__dict__.update(someotherdict) -- or even,
> shudder, reassigning X.__dict__ altogether... -- may perhaps be
> preferable, but I personally like the explicitness of assignments
> for most cases of such (rare) tasks.
This isn't a rare task at all. At least it wouldn't be if python had these
instance updating semantics and people used python in a vaguely intelligent
fashion (viz. interactively), because then it would happen countless times a
working day (and the reason I put that in the conditional is that I suspect
many might be hampered by bad habits formed with brain-dead
run-compile-debug-edit languages a la Java, C and C++).
'as
Alexander Schmolck
> 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).
> When you grab that code, you're not really going to want to do the work of
> making more specific 'use_custom_syntax' directives, as it would break in
> all sorts of subtle ways. So now the 'culture of feature' supplants the
> culture of control. The same could happen in a big commerical project, for
> that matter. Thus it may be wise not to allow this kind of customization at
> all.
I don't really understand what you're saying. To reiterate my point: the
language could force every module that wants to use some custom syntax
internally to explicitly say so at its beginning. 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. Or allow the use of certain custom syntaxes but only approved
ones (created by experienced programers) and only in special situations.
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. OTOH if that
need arises, you can get some good programmers to design the necessary syntax
transformations and I can't really see how this would be worse than having
them write some ad-hoc interpreter from scratch which likely will suffer from
an inferior design and worse reliability and performance.
'as
Jack Diederich
> 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" <vane...@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
Cliff Wells
> 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" <vane...@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.
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.
Regards,
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 (800) 735-0555
John J. Lee
> 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
Doug Tolton
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
>Python, translation often strikes me as superior to incorporating
>macros.
That's IMO the only real issue that would preclude Macro's from being
in Python. I wonder how slow they would really be though, the way
they are implemented in Lisp makes them pretty dang fast though, even
when interpreted.
Although if speed were your main issue, you really wouldn't be
programming in Python in general at this point. Python is
significantly slower than natively compiled Java, C.
Clearly the reason people use Python isn't for ultra-high performance.
So even though Macros are a performance hit, they probably wouldn't
impact performance as much as people think, and even if they did
affect performance for some things, they typically wouldn't be speed
critical sections of code anyway (ie, don't use them in speed critical
sections)
Allowing Macros makes it very easy to write an interpreter yes,
however I don't think that is the only or even necessarily the primary
reason for Macro's. Macro's allow you to embody common high level
idioms into a similarly clean statement or expression.
Using Python at all we are trading cpu cycles for higher level
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. They don't change the underlying language, they just add a
more useful abstaction capability into the language.
Alexander Schmolck
> Alex Martelli <ale...@yahoo.com> wrote:
> > I do hope that Python never gets such a powerful macro system
>
> I'm with Alex on this. Macros suck. What you usually end up with is
> essentially two different languages, with different syntaxes, and which
> don't interract very well. If nothing else, this really screws up emacs
> auto-indenting :-(
>
> One of the few things I like about C++ is that between const, templates,
> and inline, the need for the macro preprocessor has been almost
> eliminated.
Yeah, which is exactly why people are now writing books on and holding
conferences about some idiocy called template metaprogramming (which involves
extremely painfully building a modest subset of common and trivially defined
functionality offered by CL macros, see
http://www.prakinf.tu-ilmenau.de/~czarn/meta/metalisp.cpp).
> I don't even want to talk about the various systems which make use of
> things like m4.
>
> Why do you need macros? There's a few things people do with them:
>
> 1) Define constants. In Python, you just define symbols in your module,
> and get over the fact that there really is no such thing as a constant
> in Python.
>
> 2) Define efficient pseudo-functions. In Python, you just define a
> function (or method) and get over the fact that it's not as efficient as
> a macro. If I cared about microseconds, I wouldn't be writing in Python.
>
> 3) File inclusion. In Python, you don't include files, you import
> modules.
>
> 4) Conditional compilation. In Python, you can conditionally define
> anything you want at import time.
I think you should maybe do some reading about real macros first (like 'on
lisp', freely available on www.paulgraham.com), you wouldn't really use macros
for any of the above [1] (other than the ultra-primitive macros in
ultra-primitive languages like C and C++).
> 5) Inventing your own language constructs. In Python, you just don't do
> this.
Tautologically so, yes.
'as
[1] That is the prexisting facilities you use to do those things might
internally be built with macros, but that's none of your concern. You
wouldn't define your own macros for any of the above in a proper
programming language. 2) is a possible exception, but then you wouldn't
just do something primitive that amounts to just inlining the code (for
which there is an inline directive).
Doug Tolton
<vane...@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?
Gonçalo Rodrigues
wrote:
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
Michele Simionato
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
Aahz
Brandon J. Van Every <vane...@3DProgrammer.com> wrote:
>
>I don't feel like being "PC" about certain basic questions, I'm a
>pragmatic programmer and I call a spade a spade. But that doesn't make
>me a troll. It's annoying when people can't/won't tell the difference.
>The sheer volume of questions I've asked about Python should indicate
>to any impartial observer that I actually do care about the answers.
>And if that isn't sufficiently convincing, you might try checking the
>marketing-python archives.
Speaking as someone with a well-deserved reputation for abrasiveness
(nothing approaching yours, but established over more than a decade
on-line), when someone as obviously intelligent as you persists in
writing in ways that piss people off, the only likely answers for "why?"
are "troll" or "insane".
Since "troll" implies volition, it's actually less pejorative than the
alternative. One definition of insanity: performing the same action
over and over again, expecting a different result each time.
You're the one who has to decide, in the end, how much effort you're
willing to put into maintaining the social contract versus continuing to
get ostracized. I've made my decision to alienate a fair number of
people, but I also got on well enough with others.
I actually used to be more abrasive and annoying, but some people were
kind enough to whack me with a clue-by-four. Here's your free clue as
part of my pay-forward; I don't have the energy to give you more.
Cliff Wells
> [Aahz]
> > 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.
> >
>
> Ahh, yes, Mr. Rue... It's been a while since he's dropped by
> for a visit :-)
>
> on Brandon. And it's strange to me, because normally people's
> much more polite here than elsewhere; I wonder what's squishing
> everyone's balls so tight to make them so.
As annoying as Timothy is, his annoying qualities can easily be
attributed to a less-than-agile mind. His arrogance rings of madness,
which should be pitied, not despised. Brandon, on the other hand, is
annoying and arrogant without the saving grace of being either stupid or
insane.
Andrew Dalke
> 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/python-list/2001-May/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
Andrew Dalke
> 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.
Which includes you, given that you started posting to this group
about 7 months ago and still haven't programmed in it.
> At any rate, welcome to my killfile.
At this rate you won't have anyone left to read. I think you've
plonked a good portion of the regulars.
Andrew
da...@dalkescientific.com
Andrew Dalke
> Would be fun to write a Google API script, keep records, and put up a
> page to plot graphs of some simple metrics... No doubt somebody has
> done it already.
Even if not, the basic tools exist, like the Google/SOAP interface,
some COM code to talk to Excel, a couple mouse clicks, and poof.
But I'm not interested in the results nor the process, other than to
say it's easy.
> Somewhere, I came across somebody who had graphed nr. of Amazon books
> over the years, by programming language, with a neat web interface
> (maybe that was pointed to by Alex's post, can't remember).
There's also the sucks/rules index. See
http://www.lehigh.edu/~sol0/rules.html
Looks like Python rules ... but Ruby isn't on that list.
Andrew
da...@dalkescientific.com
G. Feldman
> Well, I'll freely own up to being rude and intellectually violent.
> It's annoying when people can't/won't tell the difference.
By admitting to being rude, your annoyance becomes irrelevant.
Rudeness indicates a disregard for others, hence it's correct and
appropriate for others to disregard your feelings about the use of the
term troll.
If you want people to care about what you say, you need to care enough
about them to be polite about it.
Alexander Schmolck
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
Asun Friere
> 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" <vane...@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.
Pedro Werneck
> 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.
Istvan Albert
> 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.
Andrew Dalke
> 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
Michael Geary
> >
> > 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
Michele Simionato
> 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
Andrew Dalke
> 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/~gotoken/ruby/ruby-uguide/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
Lulu of the Lotus-Eaters
|>|"Brandon J. Van Every" <vane...@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
Jack Diederich
> Gonçalo Rodrigues <op7...@mail.telepac.pt> writes:
>
> > On 18 Aug 2003 23:40:58 +0100, Alexander Schmolck <a.sch...@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
Gonçalo Rodrigues
wrote:
>Gonçalo Rodrigues <op7...@mail.telepac.pt> writes:
>
>> On 18 Aug 2003 23:40:58 +0100, Alexander Schmolck <a.sch...@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.
Andrew Dalke
> 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
Brandon J. Van Every
>
> 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.
Brandon J. Van Every
>
> 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.
Ben Finney
> 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/>
Dave Harrison
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.
> - 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.
So what ? It is simply impossible to have one language that does it all, essentially why there are so many different ways of combining Python with other languages.
> - 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.
Who cares ? If you want to go stick up posters for Python go for it.
You certainly appear like a troll, so how about a few suggested solutions to these so called problems you raised ?
Brandon J. Van Every
>
> 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.