Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 307 Vote(s) - 3.58 Average
  • 1
  • 2
  • 3
  • 4
  • 5
What does Ruby have that Python doesn't, and vice versa?

#21
I'm unsure of this, so I add it as an answer first.


## Python treats unbound methods as functions ##

That means you can call a method either like `theobject.themethod()` or by `TheClass.themethod(anobject)`.

Edit: Although the difference between methods and functions is small in Python, and non-existant in Python 3, it also doesn't exist in Ruby, simply because Ruby doesn't have functions. When you define functions, you are actually defining methods on Object.

But you still can't take the method of one class and call it as a function, you would have to rebind it to the object you want to call on, which is much more obstuse.
Reply

#22
I would like to mention Python descriptor API that allows one customize object-to-attribute "communication". It is also noteworthy that, in Python, one is free to implement an alternative protocol via overriding the default given through the default implementation of the `__getattribute__` method.
Let me give more details about the aforementioned.
Descriptors are regular classes with `__get__`, `__set__` and/or `__delete__` methods.
When interpreter encounters something like `anObj.anAttr`, the following is performed:

- `__getattribute__` method of `anObj` is invoked
- `__getattribute__` retrieves anAttr object from the class dict
- it checks whether abAttr object has `__get__`, `__set__` or `__delete__` callable objects
- the context (i.e., caller object or class, and value, instead of the latter, if we have setter) is passed to the callable object
- the result is returned.

As was mentioned, this is the default behavior. One is free to change the protocol by re-implementing `__getattribute__`.

This technique is lot more powerful than decorators.
Reply

#23
Another difference in lambdas between Python and Ruby is demonstrated by Paul Graham's [Accumulator Generator][1] problem. Reprinted here:

<blockquote>Write a function foo that takes a number n and returns a function that takes a number i, and returns n incremented by i.

Note: (a) that's number, not integer, (b) that's incremented by, not plus.</blockquote>

In Ruby, you can do this:

def foo(n)
lambda {|i| n += i }
end

In Python, you'd create an object to hold the state of n:

class foo(object):
def __init__(self, n):
self.n = n
def __call__(self, i):
self.n += i
return self.n

Some folks might prefer the explicit Python approach as being clearer conceptually, even if it's a bit more verbose. You store state like you do for anything else. You just need to wrap your head around the idea of callable objects. But regardless of which approach one prefers aesthetically, it does show one respect in which Ruby lambdas are more powerful constructs than Python's.

[1]:

[To see links please register here]

Reply

#24

[To see links please register here]

[To see links please register here]

[To see links please register here]

[To see links please register here]

[To see links please register here]

Reply

#25
## Python Example
Functions are first-class variables in Python. You can declare a function, pass it around as an object, and overwrite it:

def func(): print "hello"
def another_func(f): f()
another_func(func)

def func2(): print "goodbye"
func = func2

This is a fundamental feature of modern scripting languages. JavaScript and Lua do this, too. Ruby doesn't treat functions this way; naming a function calls it.

Of course, there are ways to do these things in Ruby, but they're not first-class operations. For example, you can wrap a function with Proc.new to treat it as a variable--but then it's no longer a function; it's an object with a "call" method.

## Ruby's functions aren't first-class objects
Ruby functions aren't first-class objects. Functions must be wrapped in an object to pass them around; the resulting object can't be treated like a function. Functions can't be assigned in a first-class manner; instead, a function in its container object must be called to modify them.

def func; p "Hello" end
def another_func(f); method(f)[] end
another_func(:func) # => "Hello"

def func2; print "Goodbye!"
self.class.send(:define_method, :func, method(:func2))
func # => "Goodbye!"

method(:func).owner # => Object
func # => "Goodbye!"
self.func # => "Goodbye!"
Reply

#26
> In Ruby, when you import a file with
> require, all the things defined in
> that file will end up in your global
> namespace.

With [Cargo][1] you can "*require libraries without cluttering your namespace*".

# foo-1.0.0.rb
class Foo
VERSION = "1.0.0"
end

# foo-2.0.0.rb
class Foo
VERSION = "2.0.0"
end

<pre>
>> Foo1 = import("foo-1.0.0")
>> Foo2 = import("foo-2.0.0")
>> Foo1::VERSION
=> "1.0.0"
>> Foo2::VERSION
=> "2.0.0"
</pre>

[1]:

[To see links please register here]

Reply

#27
At this stage, Python still has better unicode support
Reply

#28
python has named optional arguments

def func(a, b=2, c=3):
print a, b, c

>>> func(1)
1 2 3
>>> func(1, c=4)
1 2 4

AFAIK Ruby has only positioned arguments because b=2 in the function declaration is an affectation that always append.
Reply

#29
I like the fundamental differences in the way that Ruby and Python method invocations operate.

Ruby methods are invoked via a form "message passing" and need not be explicitly first-class functions (there are ways to [lift methods](

[To see links please register here]

) into "proper" function-objects) -- in this aspect Ruby is similar to Smalltalk.

Python works much more like JavaScript (or even Perl) where methods *are* functions which are invoked directly (there is also stored context information, but...)

While this might seem like a "minor" detail it is really just the surface of how *different* the Ruby and Python designs are. (On the other hand, they are also quite the same :-)

One practical difference is the concept of `method_missing` in Ruby (which, for better or worse, seems to be used in some popular frameworks). In Python, one can (at least partially) emulate the behavior using \__getattr__/\__getattribute__, albeit non-idiomatically.
Reply

#30
Ultimately all answers are going to be subjective at some level, and the answers posted so far pretty much prove that you can't point to any one feature that isn't doable in the other language in an equally nice (if not similar) way, since both languages are very concise and expressive.

I like Python's syntax. However, you have to dig a bit deeper than syntax to find the true beauty of Ruby. There is zenlike beauty in Ruby's consistency. While no trivial example can possibly explain this completely, I'll try to come up with one here just to explain what I mean.

Reverse the words in this string:

sentence = "backwards is sentence This"

When you think about how you would do it, you'd do the following:

1. Split the sentence up into words
2. Reverse the words
3. Re-join the words back into a string

In Ruby, you'd do this:

sentence.split.reverse.join ' '

Exactly as you think about it, in the same sequence, one method call after another.

In python, it would look more like this:

" ".join(reversed(sentence.split()))

It's not hard to understand, but it doesn't quite have the same flow. The subject (sentence) is buried in the middle. The operations are a mix of functions and object methods. This is a trivial example, but one discovers many different examples when really working with and understanding Ruby, especially on non-trivial tasks.
Reply



Forum Jump:


Users browsing this thread:
3 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through