from Python to Ruby in 10 seconds

Discussion in 'Ruby' started by John M. Gabriele, Mar 11, 2006.

  1. I think this subject might make for a very nice article in
    the faq (maybe to complement
    http://www.rubygarden.org/faq/entry/show/14 ), or else
    possibly could belong at http://www.ruby-doc.org/docs/ .

    If it's too much to post on this list, please let me know
    where it might be more appropriate. I'm not asking these
    questions because I'm too lazy to look them up (I will,
    regardless), but rather, I think this might be a useful
    thread.

    Anyhow, for someone coming from Python to Ruby looking to
    learn the crucial basic differences in a hurry:


    - Does Ruby do "everything is a reference to an object"
    like Python does? Or does it do like Perl where a variable
    *is* the object, and if you want a reference you need to
    explicitly take a reference to it?


    - Python is strongly typed (every object has a type, and
    the system doesn't automatically convert between types)
    and dynamically typed (types are figured out at runtime
    as much as possible). Is Ruby strongly or weakly typed?
    Dynamically or statically typed?


    - In Python, everything is an object (including classes
    and modules too). Is Ruby that way too?


    - Python has the notion of bound and unbound methods
    (so that you can call a method like an instance method,
    or as what looks like a class method if you include
    an instance of its class in the argument list). Then
    it also has class methods and static methods too. Does
    Ruby have bound/unbound methods like this?


    - With Python, strings and tuples are immutable (for
    speed, I believe). Does Ruby have immutables like this,
    or are most object mutable?


    - Python has import where it loads and runs the module
    right where it hits that import statement. If the module's
    already been imported, subsequent imports don't do anything
    special. Is ruby like this?


    - Python uses _foo, __bar, and __baz__ underscore notation
    loosely for private references. Does Ruby have similar
    notions of "privacy"?


    - Python has the pydoc command that can read docstrings
    right there in your .py file and present them as a man page.
    Can ruby's "ri" command do this too? Or must "rdoc" get
    involved somehow?


    Any other "In Python it's like {this}, but in Ruby you
    do {that}" you can think of would most likely be useful
    here.

    Thanks,
    ---John
    --
    (remove zeez if demunging email address)
     
    John M. Gabriele, Mar 11, 2006
    #1
    1. Advertising

  2. On Mar 11, 2006, at 5:13 PM, John M. Gabriele wrote:

    > I think this subject might make for a very nice article in
    > the faq (maybe to complement
    > http://www.rubygarden.org/faq/entry/show/14 ), or else
    > possibly could belong at http://www.ruby-doc.org/docs/ .
    >
    > If it's too much to post on this list, please let me know
    > where it might be more appropriate. I'm not asking these
    > questions because I'm too lazy to look them up (I will,
    > regardless), but rather, I think this might be a useful
    > thread.
    >
    > Anyhow, for someone coming from Python to Ruby looking to
    > learn the crucial basic differences in a hurry:
    >
    >
    > - Does Ruby do "everything is a reference to an object"
    > like Python does? Or does it do like Perl where a variable
    > *is* the object, and if you want a reference you need to
    > explicitly take a reference to it?
    >

    Everything is a reference to an object

    >
    > - Python is strongly typed (every object has a type, and
    > the system doesn't automatically convert between types)
    > and dynamically typed (types are figured out at runtime
    > as much as possible). Is Ruby strongly or weakly typed?
    > Dynamically or statically typed?
    >
    >

    Strong-Dynamic

    > - In Python, everything is an object (including classes
    > and modules too). Is Ruby that way too?
    >

    Yes
    >
    > - Python has the notion of bound and unbound methods
    > (so that you can call a method like an instance method,
    > or as what looks like a class method if you include
    > an instance of its class in the argument list). Then
    > it also has class methods and static methods too. Does
    > Ruby have bound/unbound methods like this?
    >
    >

    Yeeees.... I think.

    a = "Hello"

    to_s_from_object = Object.instance_method:)to_s) #=> #<UnboundMethod:
    Object(Kernel)#to_s>

    to_s_from_obj_bound = to_s_from_object.bind(a) #=> #<Method:
    String#to_s>
    to_s_from_obj_bound.call() #=> "#<String:0x3a6ebc>"

    If that's the sort of thing you mean

    > - With Python, strings and tuples are immutable (for
    > speed, I believe). Does Ruby have immutables like this,
    > or are most object mutable?
    >

    Strings are mutable, symbols, fixnums, floats and bignums are
    immutable (among others)
    For the most part if it makes sense that something should be
    mutable, it is. I don't think that mutability is ever determined on
    the basis of performance ( except for maybe symbols)

    Ruby doesn't have tuples (If these are the same tuples from ML,
    etc.). Its array's are mutable.

    >
    > - Python has import where it loads and runs the module
    > right where it hits that import statement. If the module's
    > already been imported, subsequent imports don't do anything
    > special. Is ruby like this?
    >
    >


    the method is called "require".

    > - Python uses _foo, __bar, and __baz__ underscore notation
    > loosely for private references. Does Ruby have similar
    > notions of "privacy"?
    >


    Method visibility can be controlled via the private, public, and
    protected key words. You can always get past these of course by use
    of #instance_eval for instance.

    >
    > - Python has the pydoc command that can read docstrings
    > right there in your .py file and present them as a man page.
    > Can ruby's "ri" command do this too? Or must "rdoc" get
    > involved somehow?
    >


    I don't believe ri can do on the spot parsing and viewing of the docs
    for a given file.

    >
    > Any other "In Python it's like {this}, but in Ruby you
    > do {that}" you can think of would most likely be useful
    > here.
    >
    > Thanks,
    > ---John
    > --
    > (remove zeez if demunging email address)
    >
     
    Logan Capaldo, Mar 11, 2006
    #2
    1. Advertising

  3. On Sun, Mar 12, 2006 at 07:41:20AM +0900, Logan Capaldo wrote:
    > >- With Python, strings and tuples are immutable (for
    > >speed, I believe). Does Ruby have immutables like this,
    > >or are most object mutable?
    > >

    > Strings are mutable, symbols, fixnums, floats and bignums are
    > immutable (among others)
    > For the most part if it makes sense that something should be
    > mutable, it is. I don't think that mutability is ever determined on
    > the basis of performance ( except for maybe symbols)
    >
    > Ruby doesn't have tuples (If these are the same tuples from ML,
    > etc.). Its array's are mutable.


    Any object can be made immutable by freezing it.

    >> array = %w(a b c d)

    => ["a", "b", "c", "d"]
    >> array << 'e'

    => ["a", "b", "c", "d", "e"]
    >> array.freeze
    >> array << 'f'

    TypeError: can't modify frozen array
    from (irb):3:in `<<'
    from (irb):3

    marcel
    --
    Marcel Molina Jr. <>
     
    Marcel Molina Jr., Mar 11, 2006
    #3
  4. John M. Gabriele

    Mc Osten Guest

    Logan Capaldo ha scritto:

    > For the most part if it makes sense that something should be mutable,
    > it is. I don't think that mutability is ever determined on the basis of
    > performance ( except for maybe symbols)


    Having some object immutable allows some optimization otherwise not
    possible. On the other hand makes some algorithms *slow*.

    The typical case is concatenating a lot of strings. In python it is
    terribly unefficient, it's better to use StringIO objects (kind of file
    in memory) or joining arrays.

    However, I think the real reason is:
    in Python dictionary (hash) keys are supposed to be immutable (again,
    for performance reasons, I've been told). Since hashes that could not
    use strings as keys would be quite useless, strings are immutable.

    ObjectiveC has both mutable and unmutable. But since in Python "there
    should be only one way to do it", strings are just unmutable.

    But not to go too off-topic...

    I noticed that strings are mutable in ruby since << adds to existing
    string. But I found out sometimes += creates a new string objetc...
     
    Mc Osten, Mar 12, 2006
    #4
  5. 2006/3/12, Mc Osten <>:
    >
    > I noticed that strings are mutable in ruby since << adds to existing
    > string. But I found out sometimes +=3D creates a new string objetc...
    >


    a +=3D b is the same as a =3D a + b. So, (a + b) creates a new string, and
    then assigns it to a. If you did a =3D b + c, you would not expect b to
    change, and so it is the same with a +=3D b.

    Douglas
     
    Douglas Livingstone, Mar 12, 2006
    #5
  6. John M. Gabriele

    Dave Burt Guest

    I find Logan's answers accurate and complete, except for one, which is a
    little complicated. Let me add a little to his answer.

    John M. Gabriele wrote:
    >> - Python uses _foo, __bar, and __baz__ underscore notation
    >> loosely for private references. Does Ruby have similar
    >> notions of "privacy"?


    Logan Capaldo wrote:
    > Method visibility can be controlled via the private, public, and
    > protected key words. You can always get past these of course by use of
    > #instance_eval for instance.


    In "foo.bar", bar is always a method, not a variable. What we call
    attributes are methods that behave like attributes. "foo.bar = baz" calls a
    method called bar=. We use attr_accessor, attr_reader and attr_writer to
    create attributes with their own variables. For example, "class Foo;
    attr_accessor :bar; end; foo = Foo.new"

    So private, public and protected modify methods. We use sigils for non-local
    variables: $global, @instance_variable, and @@class_variable. You can't say
    foo.@bar, and foo.bar bears no necessary relationship with @bar.

    Finally, the methods private, public and protected can be used in two ways.
    Without an argument, they modify the visibility of all the methods defined
    after them in the current scope. They can also be fed specific method names
    to modify the visibility of particular methods.

    Cheers,
    Dave
     
    Dave Burt, Mar 12, 2006
    #6
  7. On Mar 11, 2006, at 7:43 PM, Mc Osten wrote:

    > Logan Capaldo ha scritto:
    >
    >> For the most part if it makes sense that something should be
    >> mutable, it is. I don't think that mutability is ever determined
    >> on the basis of performance ( except for maybe symbols)

    >
    > Having some object immutable allows some optimization otherwise not
    > possible. On the other hand makes some algorithms *slow*.
    >
    > The typical case is concatenating a lot of strings. In python it is
    > terribly unefficient, it's better to use StringIO objects (kind of
    > file in memory) or joining arrays.
    >
    > However, I think the real reason is:
    > in Python dictionary (hash) keys are supposed to be immutable
    > (again, for performance reasons, I've been told). Since hashes that
    > could not use strings as keys would be quite useless, strings are
    > immutable.
    >
    > ObjectiveC has both mutable and unmutable. But since in Python
    > "there should be only one way to do it", strings are just unmutable.
    >
    > But not to go too off-topic...
    >
    > I noticed that strings are mutable in ruby since << adds to
    > existing string. But I found out sometimes += creates a new string
    > objetc...
    >
    >
    >


    I'm sorry I made that sound more general than I meant. I meant _in
    ruby_ generally immutablity/mutability was not decided on the basis
    of performance concerns
     
    Logan Capaldo, Mar 12, 2006
    #7
  8. John M. Gabriele

    Bill Guindon Guest

    On 3/11/06, Dave Burt <> wrote:
    > I find Logan's answers accurate and complete, except for one, which is a
    > little complicated. Let me add a little to his answer.
    >
    > John M. Gabriele wrote:
    > >> - Python uses _foo, __bar, and __baz__ underscore notation
    > >> loosely for private references. Does Ruby have similar
    > >> notions of "privacy"?

    >
    > Logan Capaldo wrote:
    > > Method visibility can be controlled via the private, public, and
    > > protected key words. You can always get past these of course by use o=

    f
    > > #instance_eval for instance.

    >
    > In "foo.bar", bar is always a method, not a variable. What we call
    > attributes are methods that behave like attributes. "foo.bar =3D baz" cal=

    ls a
    > method called bar=3D. We use attr_accessor, attr_reader and attr_writer t=

    o
    > create attributes with their own variables. For example, "class Foo;
    > attr_accessor :bar; end; foo =3D Foo.new"


    I found this a bit confusing. Maybe....
    attr_accessor, attr_reader and attr_writer can be used to create
    attributes with their own variables. They can also create the
    appropriate set/get methods for those (or other) variables.

    Creating variables and methods:

    class Foo
    attr_accessor :bar
    end

    f =3D Foo.new
    f.bar =3D 'test'
    puts f.bar

    Creating methods only (variable is created when Foo.new is called):

    class Foo
    attr_accessor :bar
    def initialize(bar=3D'')
    @bar =3D bar
    end
    end

    f =3D Foo.new
    f.bar =3D 'test'
    puts f.bar

    > So private, public and protected modify methods. We use sigils for non-lo=

    cal
    > variables: $global, @instance_variable, and @@class_variable. You can't s=

    ay
    > foo.@bar, and foo.bar bears no necessary relationship with @bar.
    >
    > Finally, the methods private, public and protected can be used in two way=

    s.
    > Without an argument, they modify the visibility of all the methods define=

    d
    > after them in the current scope. They can also be fed specific method nam=

    es
    > to modify the visibility of particular methods.


    The method names need to passed as symbols:
    class Foo
    private :bar
    end

    > Cheers,
    > Dave
    >


    Cheers to you also.
    Forgive me, I'm thinking in editor mode.

    --
    Bill Guindon (aka aGorilla)
    The best answer to most questions is "it depends".
     
    Bill Guindon, Mar 12, 2006
    #8
  9. John M. Gabriele

    Guest

    Hi --

    On Sun, 12 Mar 2006, Bill Guindon wrote:

    > On 3/11/06, Dave Burt <> wrote:
    >> I find Logan's answers accurate and complete, except for one, which is a
    >> little complicated. Let me add a little to his answer.
    >>
    >> John M. Gabriele wrote:
    >>>> - Python uses _foo, __bar, and __baz__ underscore notation
    >>>> loosely for private references. Does Ruby have similar
    >>>> notions of "privacy"?

    >>
    >> Logan Capaldo wrote:
    >>> Method visibility can be controlled via the private, public, and
    >>> protected key words. You can always get past these of course by use of
    >>> #instance_eval for instance.

    >>
    >> In "foo.bar", bar is always a method, not a variable. What we call
    >> attributes are methods that behave like attributes. "foo.bar = baz" calls a
    >> method called bar=. We use attr_accessor, attr_reader and attr_writer to
    >> create attributes with their own variables. For example, "class Foo;
    >> attr_accessor :bar; end; foo = Foo.new"

    >
    > I found this a bit confusing. Maybe....
    > attr_accessor, attr_reader and attr_writer can be used to create
    > attributes with their own variables. They can also create the
    > appropriate set/get methods for those (or other) variables.


    If I can join the word-tweaking sweepstakes: I don't think attributes
    really have "their own" variables. Give this:

    class C
    attr_accessor :x
    end

    the methods x and x= have no unique claim to, or ownership of, @x.

    Maybe one could say: The attr_* methods wrap instance variables in
    simple, like-named getter and/or setter methods. Given a pair of such
    methods x and x=, wrapped around @x, objects of the class are said to
    have an attribute "x". Or something.

    > The method names need to passed as symbols:
    > class Foo
    > private :bar
    > end


    You can use a string too (private "bar").


    David

    --
    David A. Black ()
    Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

    "Ruby for Rails" chapters now available
    from Manning Early Access Program! http://www.manning.com/books/black
     
    , Mar 12, 2006
    #9
  10. John M. Gabriele

    Bill Guindon Guest

    On 3/11/06, <> wrote:
    > Hi --
    >
    > On Sun, 12 Mar 2006, Bill Guindon wrote:
    >
    > > On 3/11/06, Dave Burt <> wrote:
    > >> I find Logan's answers accurate and complete, except for one, which is=

    a
    > >> little complicated. Let me add a little to his answer.
    > >>
    > >> John M. Gabriele wrote:
    > >>>> - Python uses _foo, __bar, and __baz__ underscore notation
    > >>>> loosely for private references. Does Ruby have similar
    > >>>> notions of "privacy"?
    > >>
    > >> Logan Capaldo wrote:
    > >>> Method visibility can be controlled via the private, public, and
    > >>> protected key words. You can always get past these of course by use =

    of
    > >>> #instance_eval for instance.
    > >>
    > >> In "foo.bar", bar is always a method, not a variable. What we call
    > >> attributes are methods that behave like attributes. "foo.bar =3D baz" =

    calls a
    > >> method called bar=3D. We use attr_accessor, attr_reader and attr_write=

    r to
    > >> create attributes with their own variables. For example, "class Foo;
    > >> attr_accessor :bar; end; foo =3D Foo.new"

    > >
    > > I found this a bit confusing. Maybe....
    > > attr_accessor, attr_reader and attr_writer can be used to create
    > > attributes with their own variables. They can also create the
    > > appropriate set/get methods for those (or other) variables.

    >
    > If I can join the word-tweaking sweepstakes: I don't think attributes
    > really have "their own" variables. Give this:
    >
    > class C
    > attr_accessor :x
    > end
    >
    > the methods x and x=3D have no unique claim to, or ownership of, @x.
    >
    > Maybe one could say: The attr_* methods wrap instance variables in
    > simple, like-named getter and/or setter methods. Given a pair of such
    > methods x and x=3D, wrapped around @x, objects of the class are said to
    > have an attribute "x". Or something.


    Perhaps best said with "when you have no other methods that set/get @x"?

    > > The method names need to passed as symbols:
    > > class Foo
    > > private :bar
    > > end

    >
    > You can use a string too (private "bar").


    I sit corrected (he says, hoping to keep his 'standings' in the
    'word-tweaking sweepstakes')

    If nothing else, it serves as a reminder that I should buy your book ;)

    >
    > David
    >
    > --
    > David A. Black ()
    > Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
    >
    > "Ruby for Rails" chapters now available
    > from Manning Early Access Program! http://www.manning.com/books/black
    >
    >



    --
    Bill Guindon (aka aGorilla)
    The best answer to most questions is "it depends".
     
    Bill Guindon, Mar 12, 2006
    #10
  11. John M. Gabriele

    Guest

    Hi --
    `
    On Sun, 12 Mar 2006, Bill Guindon wrote:

    > On 3/11/06, <> wrote:
    >> Hi --
    >>
    >> On Sun, 12 Mar 2006, Bill Guindon wrote:
    >>
    >>> On 3/11/06, Dave Burt <> wrote:
    >>>> I find Logan's answers accurate and complete, except for one, which is a
    >>>> little complicated. Let me add a little to his answer.
    >>>>
    >>>> John M. Gabriele wrote:
    >>>>>> - Python uses _foo, __bar, and __baz__ underscore notation
    >>>>>> loosely for private references. Does Ruby have similar
    >>>>>> notions of "privacy"?
    >>>>
    >>>> Logan Capaldo wrote:
    >>>>> Method visibility can be controlled via the private, public, and
    >>>>> protected key words. You can always get past these of course by use of
    >>>>> #instance_eval for instance.
    >>>>
    >>>> In "foo.bar", bar is always a method, not a variable. What we call
    >>>> attributes are methods that behave like attributes. "foo.bar = baz" calls a
    >>>> method called bar=. We use attr_accessor, attr_reader and attr_writer to
    >>>> create attributes with their own variables. For example, "class Foo;
    >>>> attr_accessor :bar; end; foo = Foo.new"
    >>>
    >>> I found this a bit confusing. Maybe....
    >>> attr_accessor, attr_reader and attr_writer can be used to create
    >>> attributes with their own variables. They can also create the
    >>> appropriate set/get methods for those (or other) variables.

    >>
    >> If I can join the word-tweaking sweepstakes: I don't think attributes
    >> really have "their own" variables. Give this:
    >>
    >> class C
    >> attr_accessor :x
    >> end
    >>
    >> the methods x and x= have no unique claim to, or ownership of, @x.
    >>
    >> Maybe one could say: The attr_* methods wrap instance variables in
    >> simple, like-named getter and/or setter methods. Given a pair of such
    >> methods x and x=, wrapped around @x, objects of the class are said to
    >> have an attribute "x". Or something.

    >
    > Perhaps best said with "when you have no other methods that set/get @x"?


    Perhaps, though I deliberately didn't qualify it, on the theory that
    you could have custom-written accessor methods and still refer to
    something as an "attribute". But that may be different from having
    multiple things going on with the same variable. I'm not sure....
    could you have one or more "changer" methods that weren't quite setter
    methods, and still have an "attribute"?

    I guess it does come down to word-play, at a certain point. After
    all, from Ruby's perspective, it's all just methods.

    >>> The method names need to passed as symbols:
    >>> class Foo
    >>> private :bar
    >>> end

    >>
    >> You can use a string too (private "bar").

    >
    > I sit corrected (he says, hoping to keep his 'standings' in the
    > 'word-tweaking sweepstakes')
    >
    > If nothing else, it serves as a reminder that I should buy your book ;)


    And think of all those friends and relatives who also might not know
    that private can take a string! :) (Disclaimer: I can't remember
    whether I mention this point in the book or not. But I approve of
    your logic :)

    It's also a reminder that strings can be used in a lot of places
    where, for whatever reason, it became customary to use symbols.


    David

    --
    David A. Black ()
    Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

    "Ruby for Rails" chapters now available
    from Manning Early Access Program! http://www.manning.com/books/black
     
    , Mar 12, 2006
    #11
  12. John M. Gabriele

    Mc Osten Guest

    Il 12-03-2006 Douglas Livingstone ha scritto:

    > a += b is the same as a = a + b. So, (a + b) creates a new string, and
    > then assigns it to a. If you did a = b + c, you would not expect b to
    > change, and so it is the same with a += b.


    Ok. Perfect: it makes sense even if in the first instance I found it
    misleading, since I expected it to have the same semantic of a simple
    "append" operation, but of course regarding a+=b a contracted form of a
    = a + b, it's fine.

    Probably it was prior C++ exposure that made me think that way.
     
    Mc Osten, Mar 12, 2006
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. tshad
    Replies:
    7
    Views:
    17,089
    tshad
    Mar 11, 2005
  2. 00_CP_D12
    Replies:
    3
    Views:
    8,984
    dilipv
    Feb 22, 2008
  3. Stu
    Replies:
    7
    Views:
    1,790
    Dave Thompson
    Mar 7, 2005
  4. Michael Tan
    Replies:
    32
    Views:
    1,026
    Ara.T.Howard
    Jul 21, 2005
  5. `p
    Replies:
    7
    Views:
    388
    Steve Litt
    Dec 14, 2005
Loading...

Share This Page