"David Masover" <ninja / slaphack.com> schrieb im Newsbeitrag 
news:200905251330.22874.ninja / slaphack.com...
> On Wednesday 20 May 2009 05:28:34 pm Tony Arcieri wrote:
>
> The social aspect seems to be the larger issue, here.
>

This is pointing to the right direction.
 But it depends on your particular semantic of "social".

(1) It would not only be a beer-table issue.
(Although many resources are always useless wasted for holy wars.)

It would probably spoil team projects and code reuse.
Given a team where one developer is familiar to pythonesque insertion.
Even if he is not one of these talibanesque people, he would probably use 
this technique somewhere in his scripts.
Even if it's explicitely forbidden in the project, danger is, it would be 
used unintentionally.
When this code is reused, other people which are not familiar to pythonesque 
insertion may be trapped.
Maybe when trying to adapt the code, maybe by some automatic beautifying by 
the editor, maybe when forced to debug this code.
This would possibly waste hours by hours while timelines fly by.

As OPoster unintentionally demonstrated in OP, some people aren't even able 
to format postings in NG's properly.
(As I get caught already in this trap too, I rely on capabilities of modern 
news_readers_.)

So, it would effectively split Rubyists into two fractions. Those, who use 
PyI and those who don't.
We used Ruby for writing test scripts for safety related software. PyI would 
have been a serious issue against using Ruby.
For not breaking existing code it would be necessary to be explicitely 
allowed by a special switch, not to be allowed by default. This would limit 
number of users.
(Maybe it is possible to implement it as a gem? This would change the 
picture completely.)

(2) Further, resources needed for a clean implementation and maintenance of 
PyI could be used for more urgent issues. (IMHO)
For example (I currently do not know the kernel of current Ruby-versions nor 
all current extensions because I'm still forced to use 1.6.8 or 1.8.6 for 
compatibility reasons.):
I would like to wait for generic Events in the central loop, not only for 
file descriptors and timeouts. (Limitations of "C-Lib"-select()).
Independence of OS-platform should be increased in the kernel.
Real-Time capabilities would be nice.
There are, fore sure, many issues on the wish-list for future Ruby kernels 
which have a higher priority.

(3) Isn't there a list where such issues are discussed? I think, Ruby is 
mature enough to establish such a process.
For further development, it should be tried to implement a standard like 
this one for "C" or "C++".
IMO, Ruby is so widely used there is more than enough reason for doing so.

Best Regards,
Michael B.