PyData.tokyo One-day Conference 2018 で登壇させていただきました pydatatokyo.connpass.com 発表資料 NumPyの歴史とPythonの並行処理 from Atsuo Ishimoto

これまで、python.jp ではSlackチームを用意していたが、こちらの利用は取り止めて、Discord に移行することにした。 書き込みはそれほどなかったものの、Python.jpチームには、約1000アカウントが登録されていた。そこそこな規模だろう。Slack->Discordへの大規模な移行としては Reactチーム の例があるが、こちらは別に Slack からなにかの制限を受けたというわけではない。 では、なぜDiscordに移行するかといえば、Slackというのはやはりオープンなコミュニティのチャットツールとしてはイマイチだと思うからだ。ReactさんのBlog にあるように、Slackのユーザ登録は面倒だし、複数のチームに所属する場合はそれぞれのチームでいちいちログインしなければならない。コミュニティ用のツールではないので特定ユーザのミュートやBanなどの機能もない。 また

bicycle1885.hatenablog.com こちらの記事を拝見していて、ちょっと気になったので注釈。 PythonやRを使っている人で、ある程度重い計算をする人達には半ば常識になっていることとして、いわゆる「for文を使ってはいけない。ベクトル化*1しろ。」という助言があります。 これは、PythonやRのようなインタープリター方式の処理系をもつ言語では、極めてfor文が遅いため、C言語やFortranで実装されたベクトル化計算を使うほうが速いという意味です。 昔からよくこういう言い方がよくされるが、本当にPythonのfor文は遅いのだろうか。 聞くところによるとRのfor文はガチで遅いそうだが、Pythonの計算が遅いのはインタープリタ方式だからでも、for文が遅いからでもない。もちろん、Pythonはインタープリタなので遅いし、for文だって極めて遅い。しかし、これはPyt