UserLinux chooses Python as "interpretive language" of choice
John Roth
newsgroups at jhrothjr.com
Sat Dec 20 07:55:42 EST 2003
More information about the Python-list mailing list
Sat Dec 20 07:55:42 EST 2003
- Previous message (by thread): UserLinux chooses Python as "interpretive language" of choice
- Next message (by thread): UserLinux chooses Python as "interpretive language" of choice
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"Ville Vainio" <ville.spammehardvainio at spamtut.fi> wrote in message news:du7r7yzzmw6.fsf at mozart.cc.tut.fi... > "John Roth" <newsgroups at jhrothjr.com> writes: > > > > > a third is the ability to forget the empty parenthesis after > > > > a function/method call that doesn't require parameters. > > > > Doesn't this suck big time? How can the interpreter tell whether you > > > are trying to call a function or just want a reference to a callable > > > object? > > > That's the crux of the implementation issue, and I, for one, > > haven't got an answer that doesn't look real ugly (let alone > > break backwards compatability.) That's why I'm not pushing > > this particular issue seriously - I don't see a way of doing it, > > given the rest of Python, and completely independently of any > > "Python philosophy" issues. > > Most importantly, why would anyone even care? Ability to optionally > invoke a "call" operation on an object implicitly seems utterly > worthless to me. That may not be one of your common coding mistakes. My mind doesn't quite get the point of inserting an otherwise useless pair of parenthesis, and consequently it's fairly high on the list of common coding errors I make that causes run time errors. Of course, rigidly applying TDD will bring those errors up rapidly so they don't lurk to cause problems later, but not having them in the first place would be even better. There's a Japanese term used in Lean Manufacturing that basically translates as "mistake proofing." While Python makes it harder to make mistakes than many other languages, it is certainly not perfect in that respect, and this issue is one of several that fall into that category. > It has the feel of perl philosophy (regexps in > language syntaxm anyone? ), and it's not the only instance in Ruby. I > don't really like the Perl philosophy (like most of the people who > "get" Python), and I don't really believe a language whose designers > appreciate the perlisms poses a serious threat to Python. Not even if > they got some things right. I suspect you're missing the point. I'm not advocating Ruby, which has, as far as I am concerned, enough problems that I'm not considering shifting at this time. What I am advocating is looking at what it's doing right and asking if some of those things might not improve Python. > > to Python. Maybe the fact that such industry heavy hitters as Robert > > Martin, David Thomas, and any number of others have switched > > Frankly, I don't know who these "heavy hitters" are, but they probably > have their reasons. Quick googling didn't turn out any useful articles > explaining why either of them has switched from Python to Ruby. Let's see. Dave (the Pragmatic Programmer) wrote the textbook on Ruby, and I think his preface says it quite nicely. > > As far as doing the "right" thing, check the partial list of Ruby > > features I gave, and ask yourself how much each of them would > > break the "feel" of Python. > > I am yet to see a feature list that would inspire me to switch, or > even consider switching. The little advantages Ruby has over Python > are dwarfed by the advantages of Python (of which the least is not > maturity, community and documentation). As I said, my intent is not to inspire anyone to switch. My intent is to ask whether there is anything they're doing that would be (in concept if not in implementation) an improvement to Python. John Roth > > -- > Ville Vainio http://www.students.tut.fi/~vainio24
- Previous message (by thread): UserLinux chooses Python as "interpretive language" of choice
- Next message (by thread): UserLinux chooses Python as "interpretive language" of choice
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list