Live data from Hacker News

Ask HN: Why Python over Ruby?

news.ycombinator.com

141–150 of 198 posts

Re: Ask HN: Why Python over Ruby?

#141

Earlier quoted context omitted.

Very flexible. Once you learn what the sytnax means the implementation of blocks and iterators is one of the best parts of the language. 3.upto(6){ |x| puts x } I don't think the uniqueness of a language is any reason not to learn it. To be honest that sounds lazy. PS I'm not a Ruby zealot, and Python is a great language

So I just saw 3 ways to print from 3 to 6... are those all used in the wild? Zen of Python: "There should be one-- and preferably only one --obvious way to do it." Sure, there are other ways to do it in Python, but it'd be frowned upon to use something like 3.upto(6) rather than a standard range() that everyone is used to. Readability matters.

I'm sorry, did you say there's only one way to deal with each integer in a set of numbers? Admittedly I don't know very much about python, but it seems that at the very least you could do this recursively.

Re: Ask HN: Why Python over Ruby?

#142
post #100

Earlier quoted context omitted.

To claim that Ruby is a tangled soup of options and syntactic sugar is to miss the point really. What is the point? I sincerely wish to learn, for my own intellectual curiosity. Because I have read Ruby code and I have done Ruby tutorials and talked to people who use Ruby and for the life of me, no matter how hard I meditate on the issue, I cannot understand why anyone would use Ruby over Python. I don't feel Python…

Python presented me with one insurmountable cognitive hurdle, and that's what drove me to Ruby: whitespace scoping. That single misfeature in Python is enough to keep me from ever using it in my own projects. The compiler/interpreter should work for me , not force me to work for the compiler/interpreter. (And no, there's not always preferably one way to do things, which is an attitude I can't stand.)

That's an ancient argument, about as old as the python language itself. The standard rebuttal for your particular argument would be:

You indent your code anyways, in any language. Hence there is no extra work involved for writing Python.

And yes, in this case that is the preferable way to do it. Unless you want to argue for non-indented or randomly indented code.

Re: Ask HN: Why Python over Ruby?

#143
post #140

Earlier quoted context omitted.

Ruby has method aliases. Python does not allow a string to capitalize itself. >>> "hello".capitalize() "Hello" Python has decorators so you can write functions that return functions that return functions to create a new function. Or functions that return classes, or classes that use other objects, or any possible other use for the pattern "wrap this with that and save the result" Python will let you mix tabs and spac…

I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize! And as for indentation, I think Guido should have followed through with making tabs a syntax error, because they are part of the syntax and are fiendish sources of error. Let's just say you have this code, properly indented with spaces: class X: def visible(self): pa…

I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize!

So the quote deals with mutability? I suppose that makes more sense, since Ruby tends to favor mutable objects. Of course, to my Python-based mind changing the definition of 'a' or 3 seems like a poor idea.

And as for indentation, I think Guido should have followed through with making tabs a syntax error

Surely you mean "making spaces a syntax error"? That would be much more sensible, since using spaces for indentation is absurd. Even better would be simply ignoring spaces, since that allows them to be used for pretty-printing and alignment without any potential ambiguity.

Also, the bug in your example will not be difficult to figure out, because Python will/should raise an exception when parsing the malformed file. Not everybody runs with -tt, but that ought to be the default behavior (and is anywhere I get to control the installation).

Re: Ask HN: Why Python over Ruby?

#144
post #23

Python is older, and gained popularity before ruby. That's why it's more established outside of the web development frameworks space.

How does python compare to ruby in terms of web development? I get the impression that there are more 3rd-party libraries in Ruby, so it is easier to get web code up and running with ruby.

Can't compare to ruby as I haven't used it much but the python world is seriously overflowing with web-related frameworks and libraries.

Django is the most popular single framework, but at least as many people prefer to roll their own based on various modules. Some of the most popular backbone kits would be werkzeug, cherrypy, webpy, pylons. Then there's literally dozens of template languages (jinja, genshi, cheetah, to name a few) and at least three mature ORMs (sqlalchemy, storm, sqlobject) to choose from.

So, while I have no idea about ruby libraries I can assure you that in python-land you get to choose between at least two mature options for pretty much any web-related task.

Re: Ask HN: Why Python over Ruby?

#145
post #89
post #76

1. Get latest OpenSolaris. 2. Install latest SunStudio 3. download latest source of Python (3.1) and Ruby (1.9.1). 4. Try to build them with CC=/opt/SUNWspro/bin/cc" CFLAGS="-m64" 5. See the results. Run make test for ruby.

So Ruby compiles cleaner on failed Unix OSs?

It's a bit harsh (albeit not completely off-base) to call solaris a failure but I do agree that c00p3r's argument is quite meaningless with regard to a ruby versus python comparison.

Both impls appear to work well enough on a wide range of platforms, the sun compiler is not exactly what makes or breaks it.

Re: Ask HN: Why Python over Ruby?

#146
post #140

Earlier quoted context omitted.

I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize! And as for indentation, I think Guido should have followed through with making tabs a syntax error, because they are part of the syntax and are fiendish sources of error. Let's just say you have this code, properly indented with spaces: class X: def visible(self): pa…

I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize! So the quote deals with mutability? I suppose that makes more sense, since Ruby tends to favor mutable objects. Of course, to my Python-based mind changing the definition of 'a' or 3 seems like a poor idea. And as for indentation, I think Guido should have followed t…

> Even better would be simply ignoring spaces

Oh god no. Then you could have blocks that line up visually but execute in different scopes

Re: Ask HN: Why Python over Ruby?

#147
post #56

Earlier quoted context omitted.

I have used both, Python more than Ruby. Python's iterators are more usable in many situations than the Ruby block system. I can return an iterator, stick it in a variable, call another function with it that returns another iterator, and so on. Python's classes also seem cleaner and less magical than Ruby's. For example, a method on a class is just an attribute that happens to be a method. Much more intuitive than Ru…

Everything is an object in Ruby, including the blocks. I'm not clear how you can't pass around a block -- or is it the block + iterator metadata you're talking about? I suspect that's just an experience problem, where Python promotes iterators over lambdas so lends itself to a different style of programming; I'm not sure how often you'd want/need to pass a full iterator around in Ruby. Personally I find blocks far mo…

You can do ", ".join(x) on any x that you can do "for y in x" on. If join were a method of the list (or sequence, or iterator, ...) then it would need to be defined over and over again.

Re: Ask HN: Why Python over Ruby?

#148

Earlier quoted context omitted.

So you're going to judge the entire Ruby community by like... 5% of their bloggers? :P

Hey, now we can judge the entire Python community by tdavis's comments. :)

shrug You certainly could! Though judging any group of people by my comments would certainly do a disservice to that group.

Re: Ask HN: Why Python over Ruby?

#149
post #100

Earlier quoted context omitted.

To claim that Ruby is a tangled soup of options and syntactic sugar is to miss the point really. What is the point? I sincerely wish to learn, for my own intellectual curiosity. Because I have read Ruby code and I have done Ruby tutorials and talked to people who use Ruby and for the life of me, no matter how hard I meditate on the issue, I cannot understand why anyone would use Ruby over Python. I don't feel Python…

I currently use Python and Django for the following reasons: 1) Coworker familiar with Python 2) I had an easier time understanding the mechanics of Django than I did Rails 3) Some libraries I needed were only in Python However, from a language point of view, I have a slight preference towards Ruby. Here are some things I like: 1) More consistent commitment to object paradigm, e.g. all function calls are actually met…

len(list) is actually a shortcut for calling list.__len__() , any object that implements the __len__ method is therefore compatible with it. So in practice, len is in fact a method call. Almost every python function that operates on objects is just a similar shorthand.

Re: Ask HN: Why Python over Ruby?

#150
post #140

Earlier quoted context omitted.

Ruby has method aliases. Python does not allow a string to capitalize itself. >>> "hello".capitalize() "Hello" Python has decorators so you can write functions that return functions that return functions to create a new function. Or functions that return classes, or classes that use other objects, or any possible other use for the pattern "wrap this with that and save the result" Python will let you mix tabs and spac…

I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize! And as for indentation, I think Guido should have followed through with making tabs a syntax error, because they are part of the syntax and are fiendish sources of error. Let's just say you have this code, properly indented with spaces: class X: def visible(self): pa…

Maybe you could consider a pre-commit hook which blocks /^\s* \t/ on * .py? Or if nothing else it's simple enough to grep/ack for.

I'd also recommend making indentation whitespace visible if your editor supports it - it is syntax after all. I have vim configured to colour leading spaces green, leading tabs as blue, and tabs following anything other than a tab highlighted red. Making inconsistent indentation ugly is quite effective, though sadly ineffective on other people.

Post reply on HN