[OFF] Python 2.4 released

Discussion in 'Ruby' started by Zach Dennis, Nov 30, 2004.

  1. Zach Dennis

    Zach Dennis Guest

    A coworker of mine came and hollarred at me because on /. it mentioned
    that Python 2.4 was released...so I went to check it out.

    I read the What's new section but isn't the majority of stuff they added
    in 2.4 stuff Ruby already does?

    (ruby does/has) 1 PEP 218: Built-In Set Objects
    (ruby does/has) 2 PEP 237: Unifying Long Integers and Integers
    (dont know) 3 PEP 289: Generator Expressions
    (ruby does/has) 4 PEP 292: Simpler String Substitutions
    (ruby does/has?)5 PEP 318: Decorators for Functions and Methods
    (ruby does/has) 6 PEP 322: Reverse Iteration
    (dont know) 7 PEP 324: New subprocess Module
    (ruby dont have) 8 PEP 327: Decimal Data Type
    (ruby dont have) 8.1 Why is Decimal needed?
    (ruby dont have) 8.2 The Decimal type
    (dont know) 8.3 The Context type
    (dont know) 9 PEP 328: Multi-line Imports
    (dont know) 10 PEP 331: Locale-Independent Float/String Conversions

    Zach
    Zach Dennis, Nov 30, 2004
    #1
    1. Advertising

  2. Hi,

    In message "Re: [OFF] Python 2.4 released"
    on Wed, 1 Dec 2004 02:35:02 +0900, Zach Dennis <> writes:

    |(ruby does/has) 1 PEP 218: Built-In Set Objects
    We have. Not built-in, though.

    |(dont know) 3 PEP 289: Generator Expressions
    We have enumerator module.

    |(ruby does/has?)5 PEP 318: Decorators for Functions and Methods
    Partially.

    |(ruby dont have) 8 PEP 327: Decimal Data Type
    We have bigdecimal.

    |(dont know) 10 PEP 331: Locale-Independent Float/String Conversions
    Partially.

    matz.
    Yukihiro Matsumoto, Nov 30, 2004
    #2
    1. Advertising

  3. On Wed, 1 Dec 2004 02:35:02 +0900, Zach Dennis <>
    wrote:
    > A coworker of mine came and hollarred at me because on /. it
    > mentioned that Python 2.4 was released...so I went to check it
    > out.
    >
    > I read the What's new section but isn't the majority of stuff they
    > added in 2.4 stuff Ruby already does?


    > (dont know) 3 PEP 289: Generator Expressions


    This may be similar to Enumerable#inject.

    > (ruby does/has) 4 PEP 292: Simpler String Substitutions


    This is just bizarre as something to put into Core Python; however,
    given that Ruby ships with RDoc, which gives you the RDoc templating
    engine, you have something like this already.

    > (ruby does/has?)5 PEP 318: Decorators for Functions and Methods


    Ruby has this implicitly, because its object model is far more
    consistent. The only thing that may improve this is an RCR that
    makes it easier to deal with custom decorators by having def return
    the Symbol of the method name. Probably :)

    > (dont know) 7 PEP 324: New subprocess Module


    This basically introduces popen.

    > (ruby dont have) 8 PEP 327: Decimal Data Type


    I think that BigDecimal handles this just fine. Note as well that
    with the Rational class (require 'rational'), you get support for
    real rational numbers. If you add 'mathn', you get full support
    including with division, etc.

    require 'rational'
    Rational.reduce(22, 7) # => Rational(22, 7)

    require 'mathn'
    "%0.9f" % [ 22 / 7 ] # => "3.142857143"
    (22 / 7).class # => Rational

    BigDecimal works with Numerics, BigIntegers, and Floats, I think.

    > (dont know) 9 PEP 328: Multi-line Imports


    Not needed.

    > (dont know) 10 PEP 331: Locale-Independent Float/String Conversions


    I don't think that this is needed.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Nov 30, 2004
    #3
  4. Austin Ziegler wrote:

    > I think that BigDecimal handles this just fine. Note as well that
    > with the Rational class (require 'rational'), you get support for
    > real rational numbers. If you add 'mathn', you get full support
    > including with division, etc.
    >
    > require 'rational'
    > Rational.reduce(22, 7) # => Rational(22, 7)
    >
    > require 'mathn'
    > "%0.9f" % [ 22 / 7 ] # => "3.142857143"
    > (22 / 7).class # => Rational
    >
    > BigDecimal works with Numerics, BigIntegers, and Floats, I think.


    It's impressive how much you can do with Standard Ruby. Add some glue
    (see attachment) to it and you can do things like this one and get exact
    results:

    (1 .. 100).inject(0) { |state, item| state + 1 / item }.to_s(50)
    # => "5.18737751763962026080511767565825315790897212670845"

    Where 50 is the number of floating point digits. Increase it and you get
    more and more detail. It's wonderful how simple things can be with Ruby.

    It all kind of makes me wonder if Rationals could be added with a
    different notation to Ruby -- maybe 0.5R + 0.4R. You would always need
    to specify the precision on output, but I think that is okay.


    require 'mathn'
    require 'bigdecimal'
    require 'bigdecimal/util'

    class Rational
    alias :eek:ld_to_s :to_s

    def to_s(precision = nil)
    if precision then
    if precision == 0 then
    self.to_d(1).to_s("F").to_i.to_s
    else
    self.to_d(precision + 1).to_s("F")
    end
    else
    old_to_s
    end
    end
    end
    Florian Gross, Nov 30, 2004
    #4
  5. Austin Ziegler ha scritto:
    > On Wed, 1 Dec 2004 02:35:02 +0900, Zach Dennis <>
    > wrote:
    >
    >>A coworker of mine came and hollarred at me because on /. it
    >>mentioned that Python 2.4 was released...so I went to check it
    >>out.
    >>
    >>I read the What's new section but isn't the majority of stuff they
    >>added in 2.4 stuff Ruby already does?

    >
    >
    >>(dont know) 3 PEP 289: Generator Expressions

    >
    >
    > This may be similar to Enumerable#inject.



    not really. to understand generator expression you first think of list
    comprehensions:

    ary=[ f(x) for x in sequence if somecondition on x ]

    Basically a #map + #select in a single loop
    (I'd like to have an Enumerable#map_filter, btw)

    Then think of a lazy version of it (returning a generator) instead of a
    whole constructed list, so that you can write:

    function(f(x) for x in seq)

    instead of
    function([f(x) for x in seq])


    withouth building a whole array when calling the function.

    Notice that we have generator.rb wich can transform a internal (rubyish)
    iterator into a lazy generator


    >>(ruby does/has?)5 PEP 318: Decorators for Functions and Methods

    >
    >
    > Ruby has this implicitly, because its object model is far more
    > consistent. The only thing that may improve this is an RCR that
    > makes it easier to deal with custom decorators by having def return
    > the Symbol of the method name. Probably :)


    this does not relate to the object model.
    A common python idiom is always been:
    class Foo(object):
    def foo():
    ...
    foo=somedecorator(foo)

    wich is basically what we do in ruby with:
    class Foo
    def foo
    ...
    end
    somedecorator :foo
    end

    Btw, I hope matz will accept RCR 277 soon
    http://rcrchive.net/rcr/show/277



    >
    >>(dont know) 7 PEP 324: New subprocess Module

    >
    >
    > This basically introduces popen.


    no, they already had popen they just 'refactored'

    >
    >>(dont know) 10 PEP 331: Locale-Independent Float/String Conversions

    >
    >
    > I don't think that this is needed.


    I can't see an use for it, but they have a rational for this, and
    actually the code is borrowed from GLIb so others seem to think it is useful


    Just playing devil's advocate :)
    gabriele renzi, Nov 30, 2004
    #5
  6. On Wed, 1 Dec 2004 03:37:21 +0900, Austin Ziegler <> wrote:
    > On Wed, 1 Dec 2004 02:35:02 +0900, Zach Dennis <>
    > wrote:
    >
    > > (dont know) 10 PEP 331: Locale-Independent Float/String Conversions

    >
    > I don't think that this is needed.
    >


    Just wondering, aren't these conversions what allow different formats
    for float numbers? For example "3.141592654" in English, "3,141592654"
    in Spanish.

    Kind Regards,
    Ed
    --
    The downside of being better than everyone else is that people tend to
    assume you're pretentious.
    Edgardo Hames, Nov 30, 2004
    #6
  7. Zach Dennis ha scritto:
    > A coworker of mine came and hollarred at me because on /. it mentioned
    > that Python 2.4 was released...so I went to check it out.
    >
    > I read the What's new section but isn't the majority of stuff they added
    > in 2.4 stuff Ruby already does?


    some, then some is unneeeded in ruby, and some is simply done
    differently (i.e. set). Python and ruby are converging anyway ;)
    http://c2.com/cgi/wiki?PythonAndRubyAreConverging
    gabriele renzi, Nov 30, 2004
    #7
  8. On Wed, 1 Dec 2004 04:52:47 +0900, itsme213 <> wrote:
    > > > (ruby does/has?)5 PEP 318: Decorators for Functions and Methods

    > >
    > > Ruby has this implicitly, because its object model is far more
    > > consistent. The only thing that may improve this is an RCR that
    > > makes it easier to deal with custom decorators by having def return
    > > the Symbol of the method name. Probably :)

    > A convenient decorator syntax would be very nice.


    Very. It's been asked for a lot.

    > Also, I believe Python manipulates the method as an object. I don't think
    > manipulating a symbol (without the context of the class in which that symbol
    > serves to name a method) can be equivalent. Maybe def should return
    > something like a
    > - Method (for def x.foo...) or
    > - UnboundMethod or [Symbol, Class] pair (for class X; def foo ... )


    Well, the case of def x.foo is the only case where a Symbol by itself
    isn't going to be useful, really -- so maybe [Symbol, "Class"] is the
    better choice. Other manipulations of thse things in Ruby -- are done
    with the Symbol, and there's not a lot you can do to manipulate a
    Method object.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Nov 30, 2004
    #8
  9. On Wed, 1 Dec 2004 04:54:15 +0900, Edgardo Hames <> wrote:
    > On Wed, 1 Dec 2004 03:37:21 +0900, Austin Ziegler <> wrote:
    > > On Wed, 1 Dec 2004 02:35:02 +0900, Zach Dennis <>
    > > wrote:
    > > > (dont know) 10 PEP 331: Locale-Independent Float/String Conversions

    > > I don't think that this is needed.

    > Just wondering, aren't these conversions what allow different formats
    > for float numbers? For example "3.141592654" in English, "3,141592654"
    > in Spanish.


    That's locale-dependent. Basically, Python's numeric output appears to
    be locale-dependent in all cases, except when using these new
    features.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Nov 30, 2004
    #9
  10. Austin Ziegler wrote:

    > Well, the case of def x.foo is the only case where a Symbol by itself
    > isn't going to be useful, really -- so maybe [Symbol, "Class"] is the
    > better choice. Other manipulations of thse things in Ruby -- are done
    > with the Symbol, and there's not a lot you can do to manipulate a
    > Method object.


    Symbols are really the only option here because of the overhead involved
    when creating a Method object for every def. I agree that it would only
    make sense in private def other.method; end cases, but I think class
    << other; private def method; end; end is not too troublesome to use.

    I am wondering why matz stays so silent on this. Are there issues
    frequently overseen? Would returning a Symbol instead of nil make a
    difference in terms of performance?
    Florian Gross, Nov 30, 2004
    #10
  11. gabriele renzi wrote:
    > Austin Ziegler ha scritto:
    > >>(ruby does/has?)5 PEP 318: Decorators for Functions and Methods

    > >
    > >
    > > Ruby has this implicitly, because its object model is far more
    > > consistent. The only thing that may improve this is an RCR that
    > > makes it easier to deal with custom decorators by having def return
    > > the Symbol of the method name. Probably :)

    >
    > this does not relate to the object model.
    > A common python idiom is always been:
    > class Foo(object):
    > def foo():
    > ...
    > foo=somedecorator(foo)
    >
    > wich is basically what we do in ruby with:
    > class Foo
    > def foo
    > ...
    > end
    > somedecorator :foo
    > end
    >
    > Btw, I hope matz will accept RCR 277 soon
    > http://rcrchive.net/rcr/show/277


    If the Ruby parser could determine, whether a "def" statement is used inside
    another expression (e.g. "public def"), then it would be great if it would
    return a Method object. If it's in no expression (plain class/module scope),
    it should return nil. Not sure, if this is possible at all. A Method object
    is much better than a Symbol!

    Regards,

    Michael
    Michael Neumann, Dec 1, 2004
    #11
  12. Hello gabriele,

    gr> this does not relate to the object model.
    gr> A common python idiom is always been:
    gr> class Foo(object):
    gr> def foo():
    gr> ...
    gr> foo=somedecorator(foo)

    gr> wich is basically what we do in ruby with:
    gr> class Foo
    gr> def foo
    gr> ...
    gr> end
    gr> somedecorator :foo
    gr> end

    gr> Btw, I hope matz will accept RCR 277 soon
    gr> http://rcrchive.net/rcr/show/277


    Again you get a "no" from me about RCR 277.

    I can't see any real value of your notation, it just makes the use of
    public even more unclear. I would instead vote for not even allow
    "public" to be state sensitiv.



    --
    Best regards, emailto: scholz at scriptolutions dot com
    Lothar Scholz http://www.ruby-ide.com
    CTO Scriptolutions Ruby, PHP, Python IDE 's
    Lothar Scholz, Dec 1, 2004
    #12
  13. On Wednesday, December 1, 2004, 9:51:11 PM, Lothar wrote:

    gr>> Btw, I hope matz will accept RCR 277 soon
    gr>> http://rcrchive.net/rcr/show/277

    > Again you get a "no" from me about RCR 277.


    > I can't see any real value of your notation, it just makes the use of
    > public even more unclear.


    What on earth can be considered unclear about

    public def foo
    ...
    end

    ?

    > I would instead vote for not even allow "public" to be state
    > sensitive.


    It's not state-sensitive; it just has a default behaviour and a
    specific (i.e. when given an argument) behaviour.

    Gavin
    Gavin Sinclair, Dec 1, 2004
    #13
  14. Lothar Scholz <> wrote in message news:<>...
    > Hello gabriele,
    >
    > gr> this does not relate to the object model.
    > gr> A common python idiom is always been:
    > gr> class Foo(object):
    > gr> def foo():
    > gr> ...
    > gr> foo=somedecorator(foo)
    >
    > gr> wich is basically what we do in ruby with:
    > gr> class Foo
    > gr> def foo
    > gr> ...
    > gr> end
    > gr> somedecorator :foo
    > gr> end
    >
    > gr> Btw, I hope matz will accept RCR 277 soon
    > gr> http://rcrchive.net/rcr/show/277
    >
    >
    > Again you get a "no" from me about RCR 277.
    >
    > I can't see any real value of your notation, it just makes the use of
    > public even more unclear. I would instead vote for not even allow
    > "public" to be state sensitiv.


    How does it make it more unclear? How is it unclear in the first
    place? Curious statement.

    Dan
    Daniel Berger, Dec 1, 2004
    #14
  15. On Wed, 1 Dec 2004 19:14:25 +0900, Michael Neumann <> wrote:
    > If the Ruby parser could determine, whether a "def" statement is used inside
    > another expression (e.g. "public def"), then it would be great if it would
    > return a Method object. If it's in no expression (plain class/module scope),
    > it should return nil. Not sure, if this is possible at all. A Method object
    > is much better than a Symbol!


    Why?

    I ask this in all seriousness, because just about the only thing
    (currently) that you can get from a Method and not from a Symbol is
    #arity. While I certainly wish I could get other information, there's
    little value in returning a heavyweight object. Beyond that, I don't
    think that it's useful to have a dynamic return (similar to Perl's
    "wantsarray" -- ick!).

    Most operations where this is desired are things that work better with
    the name of the method than the Method or UnboundMethod itself. As far
    as I can tell, there's no method to get the name of the Method or
    UnboundMethod, so you're stuck with parsing #inspect.

    I do think that we have to figure out what "def self.foo; ... ; end"
    should return if we do this and have commented such on RCR 277.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Dec 1, 2004
    #15
  16. Austin Ziegler schrieb:
    > On Wed, 1 Dec 2004 19:14:25 +0900, Michael Neumann <> wrote:
    >
    >>If the Ruby parser could determine, whether a "def" statement is used inside
    >>another expression (e.g. "public def"), then it would be great if it would
    >>return a Method object. If it's in no expression (plain class/module scope),
    >>it should return nil. Not sure, if this is possible at all. A Method object
    >>is much better than a Symbol!

    >
    >
    > Why?


    Okay, it's not *much* better ;-)

    Symbols are fine most of the time.

    Well, you may remeber that I tried to implement Pythons decorators in
    Ruby: http://www.ntecs.de/blog/Blog/PythonDecorators2.rdoc

    And then I tried to implement the same in other ways, e.g.

    synchronize |
    def f
    end

    or

    synchronize private <=
    def f
    end

    (or use other operators).

    But that does not work with symbols, as synchronize would create an
    object which does not have the current binding (I tried
    binding_of_caller IIRC, but that didn't worked either).

    In this case, the method object would be nice.

    But that is a very rare case.

    > I ask this in all seriousness, because just about the only thing
    > (currently) that you can get from a Method and not from a Symbol is
    > #arity. While I certainly wish I could get other information, there's
    > little value in returning a heavyweight object. Beyond that, I don't
    > think that it's useful to have a dynamic return (similar to Perl's
    > "wantsarray" -- ick!).


    No. I fully agree.

    > Most operations where this is desired are things that work better with
    > the name of the method than the Method or UnboundMethod itself. As far
    > as I can tell, there's no method to get the name of the Method or
    > UnboundMethod, so you're stuck with parsing #inspect.


    Maybe this could be implemented.

    > I do think that we have to figure out what "def self.foo; ... ; end"
    > should return if we do this and have commented such on RCR 277.


    Hm, here, a method object would help.
    Or, as someone else suggested, a [scope, :symbol] as return value should
    help, right? That's of course more overhead than just a simple symbol.
    The question is how much more expensive would a method object be?

    Regards,

    Michael
    Michael Neumann, Dec 1, 2004
    #16
  17. On Wednesday 01 December 2004 10:34 am, Austin Ziegler wrote:
    | I do think that we have to figure out what "def self.foo; ... ; end"
    | should return if we do this and have commented such on RCR 277.

    Considering that it doesn't return anything at all now, I don't see why this
    should be a sticking point. How frequent will such usage be anyway? IMHO:

    def self.foo; ... ; end
    ==> :foo

    If you need the class ask for it.

    self.class

    I'm not sure what #export is supposed to do (its not part of 1.8+ AFAICT), but
    in this _assumely_ rare case maybe one can do something like:

    export (def self.foo
    #...
    end), self.class.intern

    Or whatever export needs as a second parameter.

    BTW, this makes me think of another idea: HERE "blocks" (vs. HERE docs)

    export <<~(, self.class.intern
    def self.foo
    #...
    end
    )

    T.
    trans. (T. Onoma), Dec 1, 2004
    #17
  18. Michael Neumann ha scritto:

    > If the Ruby parser could determine, whether a "def" statement is used inside
    > another expression (e.g. "public def"), then it would be great if it would
    > return a Method object. If it's in no expression (plain class/module scope),
    > it should return nil. Not sure, if this is possible at all. A Method object
    > is much better than a Symbol!
    >


    well, in an old thread matz said that returning a Method object is a
    cost too high for the current implementation (as in performance).
    not that I understand why :)
    gabriele renzi, Dec 1, 2004
    #18
  19. Lothar Scholz ha scritto:

    > Again you get a "no" from me about RCR 277.
    >
    > I can't see any real value of your notation, it just makes the use of
    > public even more unclear. I would instead vote for not even allow
    > "public" to be state sensitiv.
    >


    well this RCR is not mine :)
    Anyway this does not look like state based to me, it's not like
    class Foo
    public
    def bla..

    but like
    class Foo
    def bla
    public :bla
    gabriele renzi, Dec 1, 2004
    #19
    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. Steve
    Replies:
    0
    Views:
    444
    Steve
    Jan 31, 2006
  2. Wayne...
    Replies:
    15
    Views:
    757
    Toby Inkster
    Jul 23, 2004
  3. robert112
    Replies:
    1
    Views:
    431
    Juan T. Llibre
    Apr 26, 2007
  4. Paul Moore
    Replies:
    0
    Views:
    600
    Paul Moore
    Mar 1, 2008
  5. Martin v. Löwis
    Replies:
    0
    Views:
    641
    Martin v. Löwis
    Mar 1, 2008
Loading...

Share This Page