[OFF] Python 2.4 released

[Zach Dennis]

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

 

[Yukihiro Matsumoto]

Hi,

In message "Re: [OFF] Python 2.4 released"

|(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.

 

[Austin Ziegler]

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

 

[Florian Gross]

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 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

 

[gabriele renzi]

Austin Ziegler ha scritto:

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 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

This basically introduces popen.

no, they already had popen they just 'refactored'

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

 

[Edgardo Hames]

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

 

[gabriele renzi]

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

 

[Austin Ziegler]

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]

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

 

[Florian Gross]

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?

 

[Michael Neumann]

Austin Ziegler ha scritto:

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

 

[Lothar Scholz]

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.

 

[Gavin Sinclair]

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

 

[Daniel Berger]

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

 

[Austin Ziegler]

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

 

[Michael Neumann]

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

 

[trans. (T. Onoma)]

; 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.

 

[gabriele renzi]

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]

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