アカウント名:
パスワード:
今でもマクロというかアドインは Python(IPython) で書いてるけど、何が変わるのだろうか。.NET な Office Interop で書けてるのが便利なので、VBA 相当になったら不便になるだけだし。
アドインとかOffice Tools相当だと配布が面倒でねぇ。(ソース管理や開発はこっちの方が断然いいんだけど)
アンケートにはNative Supportって文字があったから、追加でなんも入れなくて使えるようになる(オプションではあるのだろうけど)なら便利かな。ただアドインとちがってxlsmでしか使えないだろうから、それが障壁になる環境もあるかもしれないが。
VBAも関数が第一級オブジェクトになってくれてプロジェクトの自動エクスポート(で、それをコミットする)とかあればまだ使えなくもないんだけどな。
使い勝手が多少良くなるだけだろう。おそらく、Excelの行や列をPythonの配列に直接変換したり、その逆をやったりなんて、一発で直接には出来なかろう。スクリプトの文法がPythonになるというだけで、実装された結果を見てがっかりというのが落ちだと思う。
COMに縛られてる限り.NET上での実装はどうしても不安定さを伴うからなぁ(なまじ旧来のInteropとCCWが混在してるとややこしくなるし)
PythonでのCOMリソースの解放ってどう実装されるんだろう
元々の Python (CPython) は参照カウントでの寿命管理だし、スレッドも GIL とか使った微妙なものなのであまり問題は無いんじゃない?
> 元々の Python (CPython) は参照カウントでの寿命管理だし、COMと.NETは違う世界で、Interopが橋渡しをしてるだけだから、.NET側のオブジェクトを参照カウントでの寿命管理するだけでは駄目なの。.NET側のランタイム(GC含む)がリソース解放する前に終了しちゃったらCOM側のリソースが解放されない(=メモリリークの原因になる)から。
# だからちゃんとReleaseComObjectしないといけないのが原則になる
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
IronPythonとの差は (スコア:1)
今でもマクロというかアドインは Python(IPython) で書いてるけど、何が変わるのだろうか。
.NET な Office Interop で書けてるのが便利なので、VBA 相当になったら不便になるだけだし。
Re:IronPythonとの差は (スコア:1)
アドインとかOffice Tools相当だと配布が面倒でねぇ。(ソース管理や開発はこっちの方が断然いいんだけど)
アンケートにはNative Supportって文字があったから、追加でなんも入れなくて使えるようになる(オプションではあるのだろうけど)なら便利かな。
ただアドインとちがってxlsmでしか使えないだろうから、それが障壁になる環境もあるかもしれないが。
VBAも関数が第一級オブジェクトになってくれてプロジェクトの自動エクスポート(で、それをコミットする)とかあればまだ使えなくもないんだけどな。
Re: (スコア:0)
使い勝手が多少良くなるだけだろう。
おそらく、Excelの行や列をPythonの配列に直接変換したり、その逆をやったりなんて、一発で直接には出来なかろう。
スクリプトの文法がPythonになるというだけで、実装された結果を見てがっかりというのが落ちだと思う。
Re: (スコア:0)
COMに縛られてる限り.NET上での実装はどうしても不安定さを伴うからなぁ
(なまじ旧来のInteropとCCWが混在してるとややこしくなるし)
PythonでのCOMリソースの解放ってどう実装されるんだろう
Re: (スコア:0)
元々の Python (CPython) は参照カウントでの寿命管理だし、
スレッドも GIL とか使った微妙なものなのであまり問題は無いんじゃない?
Re:IronPythonとの差は (スコア:1)
> 元々の Python (CPython) は参照カウントでの寿命管理だし、
COMと.NETは違う世界で、Interopが橋渡しをしてるだけだから、.NET側のオブジェクトを参照カウントでの寿命管理するだけでは駄目なの。
.NET側のランタイム(GC含む)がリソース解放する前に終了しちゃったらCOM側のリソースが解放されない(=メモリリークの原因になる)から。
# だからちゃんとReleaseComObjectしないといけないのが原則になる