Visual Studio Code is now shipping with Anaconda! - Python
Get notified in your email when a new post is published to this blog For everyone from enterprise programmers to data scientists, Python is one of the most popular dynamic languages for software development. Anaconda, the most popular Python data science platform, provides 6 million users with a streamlined Python environment on Windows, Mac or Linux. And starting today, Visual Studio Code, Micros
クラスブロックのひみつ - atsuoishimoto's diary
さて、 リスト内包のひみつ - atsuoishimoto's diary で、Python3では、リスト内包式は関数呼び出しとなることを説明した。 >>> a = [i*2 for i in range(3)] というスクリプトは、次のように展開される。 >>> def _listcomp(_it): ... ret = [] ... for i in it: ... ret.append(i*2) ... return ret ... >>> _it = range(3) >>> a = _listcomp(it) 通常、この点はあまり気にする必要はないが、問題となるケースもなくはない。 クラスブロックのリスト内包 クラスブロックで次の処理を実行してみよう。 class Foo: NUMS = [i*2 for i in range(3)] まあ、これは当然動作する。Foo.NUMS
ざっとわかるPythonの紹介 - はこべにっき ♨
普段Perlを書いている自分がざっくりPythonについて調べて発表した時の資料が手元に転がっていたので、せっかくなので公開した。 普段、別の言語でWeb開発している人が、自分の言語のアレはPythonだとコレなのねって雰囲気わかるようになっているといいなと思って作ったけど、見返すとそうでもない気がする。 自分もPython初心者なので、「おいおいまったくまちがっているぜ! 」といったことがあったら教えてほしいです。京都に住んでいるのだけど、関西のPythonコミュニティの雰囲気もよく知らないので情報募集です。 あと資料で紹介しているブログのコードは以下においてある。自分がよくやる感じの薄い設計でかんたんなブログシステムをPythonで書いたらこんな感じかな～ってコードになっている。 github.com
PyQ - 本気でプログラミングを学びたいあなたへ
必要なのはブラウザだけプログラミングを始める時に、最初につまづくのが環境構築です。 PyQでは環境構築なしで、ブラウザをひらけば10秒でプログラミングを始められます。 読む・書く・動かすサイクルで定着PyQのエディター画面では、実際にブラウザの後ろでPythonが動いています。これにより、教材を読む→コードを書く→実際に動かすという流れを画面内で完結できます。もちろん、自分で内容を変更して、動かして試してみることもできます。 あなたの興味に寄り添う、1500問以上から選べるコンテンツPyQでの学習は、数個の問題からなる「クエスト」という単位で進みます。 600クエスト・1500問以上存在するすべてのクエストは、好きな順に学び放題。 関連の深いクエストはパート・コースにまとめられており、 直感的に様々なクエストを組み合わせて、自分の興味のある分野を学べます。
ブラウザでPython学習ができるPyQ！のデザイナー視点 : まりっぺぶろぐ
こんばんは。知人のネトゲのPvPの愚痴を聞き終えたので、本日リリースしたPyQについて、闇のデザイナー視点で書いてみようと思います。 あの、2008年からいち早くPythonを採用し、Pythonといえばびーぴーと言わしめたか言わしめていないか定かではない、びーぴーの血と汗と涙とその他体液がつめこまれたと言っても過言ではなさそうなPyQ（ぱいきゅー）がリリースされました。 PyQについて 私がこのプロジェクトに加入したのはリリース目前になってから。売り出すためのLPを作ってほしいという内容からでした。 「自分でサービスのデザインできるかと思いきや、作られたものを宣伝するだけかよー、チェ」とも似て非なる想いもあり、「私は制作に関わっていないからこの子（PyQ）は私の子じゃない。他人の子をいい子だと宣伝するのは難しい。」みたいな風を吹かせながら、まずはPyQでの学習を試すことから始めました。
wheelのありがたさとAnacondaへの要望 - YAMAGUCHI::weblog
はじめに こんにちは、Python界のラファエル・ナダルです。全豪オープンテニス、盛り上がりましたね。さて、先日次のようなエントリーを立て続けに書いたんですが、「なぜAnacondaに関しての記述がないのか」という突っ込みをもらったので、参照用にメモを残しておきます。 Pythonの仮想環境構築 2017.01版 - YAMAGUCHI::weblog Pythonの環境設定でむかついてる人はとりあえずこれをコピペで実行してください 2017.01 - YAMAGUCHI::weblog なおこの記事の作成にあたっては @aodag に数多くのアドバイスをいただきました。この場を借りて感謝。 TL;DR condaの開発者はPyPAともっとコミュニケーションとってほしい。 前提 この記事はPythonを触り始めたばかりだけど、パッケージ管理ツール等々のスタンダードがどのようになっているかな
Pythonの仮想環境構築 2017.01版 - YAMAGUCHI::weblog
はじめに こんにちは、Python界のテリー・ギリアムです。こんな記事を見かけて、Pythonの開発環境を作るのが面倒という認識が広まるのは良くないなあと思って書きました。ただの突っ込み記事です。 qiita.com そのツールほんとに要りますか？ 出だしにこんなセクションタイトルがありました。 その仮想環境本当に必要ですか？ たしかに仮想環境要らないひとは要らないよねっていうのは同意です。その場合、入ってるPythonのsite-packagesにどんどんパッケージがインストールされるだけなので、手動で消せる人はそれでいいし、そもそもパッケージのバージョンとか知るかって人はそのままパッケージインストールすればいいと思います。 とはいえ、複数のプロジェクトでパッケージのバージョンがぶつかったら困る人とかいるし、そういう人は仮想環境を使うことになるでしょう。で、件の記事ではいろいろなツールを
Pythonの環境設定でむかついてる人はとりあえずこれをコピペで実行してください 2017.01 - YAMAGUCHI::weblog
はじめに こんにちは、最近Pythonをまた書き始めたマンです。なんか古い記事が参照されててだいぶ害があるので現状にあったやつにします。 Pythonの環境設定でむかついてる人はとりあえずこれをコピペで実行してください - YAMAGUCHI::weblog 要点 これからPythonを使い始める人、という前提に立っているので今更Python2系を使い始める意味はない。*1ということでPython3系（現時点最新安定版のPython3.6.0）を使いましょう。 標準を使うのがよい（venv + pip） 自分がよく分かってないツールは使わないほうがいい Python2系を使う人は、上にリンクしてある記事にあるとおりなんですが、Python2.7を使うのであれば pip + virtualenv 一択だと思います。やり方は下にある内容と変わりません。 以下コピペ macOS Homebrew
pyenvが必要かどうかフローチャート - Qiita
pyspaの統合思念体の渋川です。 「pyenv使いましょう！」系の記事、全部ゴミ — Yoshifumi YAMAGUCHI (@ymotongpoo) September 29, 2016 これはpyenvがダメではなくて、pyenvをとりあえずインストールしておきましょう記事がダメという意味だそうです。すでにとんぷーが5年前にこの問題について書いています。これを読んで分かる人には不要です。 この記事では「便利」と「必要」は分けて考えています。後者にフォーカスしています。 前提知識 Environment Isolation Tool(環境分離ツール)というカテゴリの開発補助ツールがあります。pip install Sphinxとか書いたら、ライブラリはグローバル空間に入っちゃいます。複数バージョン入れられません。そんなときに使うのが、この環境分離ツールです。最近はいろいろな言語がこれ
Exceptional Logging of Exceptions in Python
Aaron Maxwell is author of Powerful Python. Exceptions happen. And as developers, we simply have to deal with them. Even when writing software to help us find burritos. Wait, I’m getting ahead of myself… we’ll come back to that. As I was saying: How we deal with exceptions depends on the language. And for software operating at scale, logging is one of the most powerful, valuable tools we have for
複数バージョンのPythonを使い分ける
なんとなくネタとして。 Pythonは大きく2系と3系になってますが、そろそろ3系に移行しつつも2系のケアをしてあげないといけません。 なので必然的に複数バージョンのPythonを使い分けることになります。 なんかそういうの簡単にできちゃうよーという 超便利ツール があるらしいですが なんでわざわざツールの使い方覚えないといけないのかさっぱり理解不能なので、 超便利ツール にさっぱりついてけないなりのやり方をメモっておきます。 方針とか プロジェクト内ごとの環境は virtualenv を使う tox を使ってバージョンごとのテストなどを実行する /opt/python-{version} にインストールする バージョンつきの pythonコマンド(python3.4,``python2.7`` など) は PATHに常に含まれるようにする とりあえずvirtualenvするには pyth
Python 2/3 両対応のために `unicode_literals` を使うべきか - methaneのブログ
背景 Python 2 用のコードを書くときは、 Python 3 対応を見越して # -*- coding: utf-8 -*- from __future__ import division, print_function, absolute_import をテンプレとして書いています。 __future__ はファイルごとにバラバラだと混乱を招くので、今関わってるプロジェクトでもこれを新規ファイルのテンプレとして登録してもらってます。 Python 3 の構文、リテラルを有効にする __future__ のうち、 unicode_literals だけは今まで使っていなかったのですが、ふと「あ、やっぱり使うべきだな」と思いついたので、そのへんをまとめます。 第三の文字列型 native string Python 2 には2つの文字列型 str (bytes) と unicode が
言語としての一貫性を重視したPython 3の進化
言語としての一貫性を重視したPython 3の進化：よりPythonicなPythonを目指して（後編）（1/2 ページ） Python 3.0では、Python 2で書かれたスクリプトが動かなくなるような実装が行われた。なぜ、後方互換性を崩してまで大きな仕様変更を行ったのか。それは、PythonがよりPythonらしくあるためだ。 前編「Python 3が後方互換性を捨てても求めたもの」では、後方互換性を犠牲にしてでも、よりPythonらしくあるために仕様を変更したことに触れながら、いくつかの機能変更を見てきました。 それは、「誰もが正しいと考える、たった1つの方法をできる限り採用する（There should be one-and preferably only one-obvious way to do it）」というPythonの設計思想を、より高次元で実現するために必要だったから
Python 3が後方互換性を捨ててでも求めたもの
Python 3が後方互換性を捨ててでも求めたもの：よりPythonicなPythonを目指して（前編）（1/2 ページ） Python 3.0では、Python 2で書かれたスクリプトが動かなくなるような実装が行われた。なぜ、後方互換性を崩してまで大きな仕様変更を行ったのか。それは、PythonがよりPythonらしくあるためだ。 2008年12月4日、Python 3.0がリリースされました。これまで「Python 3000」や「Py3k」という愛称で呼ばれ、Pythonの次期メジャーバージョンとして開発されていたものです。 メジャーバージョンアップといっても、基本的な文法、インデントを使ったブロック表記や基本的な機能の多くはPython 2から引き継いでいます。Pythonの持つシンプルで一貫性のある設計思想を受け継ぎ、よりPythonicなPythonへと言語をステップアップさせる
Pythonにサヨナラを - HackerNews翻訳してみた
「HackerNews翻訳してみた」が POSTD (ポスト・ディー) としてリニューアルしました！ この記事はここでも公開されています。 Original article: Saying Goodbye To Python by Ian Bicking ずっと先延ばしにしてきた記事を書きます。決別宣言ではなく（ずいぶん前に離れていますし）、ただ自分が歩んできた道を振り返ったに過ぎません。Pythonの世界に別れを告げてずいぶん経つのに、これまでサヨナラを言う勇気がなかったのです。 何年も前にPythonを卒業したとはいえ多少の愛着は残っており、戻る可能性もあると思っていました。PyCon 2013への提議が却下されたことは頭にきましたが（面白い話をしようと思っていたのに！）、この件で自分はもうPythonコミュニティの一員ではないのだと確信しました。 Pythonは私が初めて（もしかした
pipのsetuptools離れ
年明けに pip 1.5 がリリースされ、1.4でのpreリリースの扱いに加えて、外部サイトにおいてあるライブラリがインストールできなくなった(allow-externalオプションが必要)り、httpsじゃないサイトからのダウンロードができなくなった(allow-unverified )り、阿鼻叫喚のようです。 そのあたりはエラーメッセージの通りにしてよね！ってことで、そことは別の話です。 pip1.5以降はpkg_resourcesというsetuptoolsに入ってたモジュールをpip内に同梱するようになりました。 1.4のときにdistlibも同梱されるようになっているため、pythonのパッケージングに関するユーティリティライブラリを新旧ともにpipは同梱するようになったわけです。 さらに get-pip はsetuptoolsがなければそれもインストールするようになりました。 っ
効果的なunittest - または、callFUTの秘密
Contents unittest を効果的に使うための覚書 目的 ルール: テスト対象のモジュール(module-under-test)をテストモジュールに直接importしない ガイドライン: モジュールスコープでの依存を最小限にする ルール: 各テストメソッドでは、１つの事実だけを確認する ルール： テストメソッドは内容を表すようにしよう ガイドライン: setupはヘルパーメソッドで提供しよう。テストケースのselfで共有するのはやめよう。 ガイドライン: フィクスチャは可能な限り簡潔に ガイドライン： フックやレジストリなどの利用は注意深く ガイドライン: 依存関係を明確にするためにモックを利用する ルール: テストモジュール間でテキストを共有しない まとめ https://twitter.com/tokibito/status/412074246026698753 ということで
Python の名前空間とスコープ
プログラムのロジックを考え、実装を行う上で、変数の名前空間やスコープはとても重要です。 これらはロジックを組み立てる上での複雑さに直結し、ソースコードの読みやすさにダイレクトに関係してくるためです。 この記事では、私が Python で開発をする上で気をつけるようにしている名前空間やスコープに関するお話をします。 コーディングスタイルについて 名前空間やスコープの前に、まずは基本的なコーディングスタイルについて軽くお話しします。 Python のコーディングスタイルというと、 PEP 8 – Style Guide for Python Code (日本語訳は こちら )が有名です。 これは、 Python でプログラムを書く上で守っておくとよいお作法について書かれており、 Python のコーディングスタイルとしてはデファクトスタンダードといえるでしょう。 この PEP8、例えば以下のよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Simple way to distribute your private Python packages within your organization | Democratizing Data
http://www.gembook.org/2010-09-20.html