シェルスクリプトとの対比で理解するPythonのsubprocess - 朝日ネット 技術者ブログ
はじめに 開発部の ikasat です。 皆さんは git, ssh, rsync のような外部コマンドを呼び出すスクリプトを書きたくなったことはありますか？ 個人的にこの類のスクリプトは最初はシェルスクリプトとして書くのですが、改修を重ねるうちに肥大化して処理も複雑になり、 後から Python のような汎用プログラミング言語で書き直すことがよくあります。 外部コマンド呼び出しを書き直す際に、Git 操作のために pygit2、 SSH 接続のために paramiko のようなライブラリをわざわざ使うのは大がかりだったり、 rsync に相当するようなこなれたライブラリが存在しなかったりする場合があります。 そのような時は標準ライブラリの subprocess モジュールを利用し、Python から外部コマンドを呼び出すことになるでしょう。 しかしながら、Python のチュートリアルペ
Python 内包表記の限界: 複雑な処理と実行速度の関係 - Qiita
初めに 本記事は実務上で速度的優位性を得るために内包表記を使うことが合理的かどうか検証したものです。 文中のコードは読者層を広くするために型ヒントを省いています。 更新履歴 詳細 追記 (2023/05/24) 計測環境はPython3.12.0a6です。 修正 (2023/05/24) 記事中のバイトコードがPython3.7.16のものだったのでPython3.12.0a6のものに差し替えました。 修正 (2023/05/27) 「list(generator) 使えよ」とのご指摘があったので 単純な例の内包表記を[i for i in range(ELEMENTS)]からlist(range(ELEMENTS))に修正しました。 ご指摘ありがとうございます。 追記 (2023/05/28) Twitterでの反応に対しての追記を行いました。
Mojo 🔥
先日プログラミング言語 Mojo と呼ばれるもののアナウンスメントがあった。この言語のデザインが私のスイートスポットに刺さる感じだったので、今のうちから注目している。使いたいなというか、将来使うことになりそうな言語なので簡単に何ができそうかを調査してまとめておきたい。 ウリとしては「C 並のパフォーマンスが出る Python」といったところだろうか。 k0kubun さんからコメントを裏でもらって、これって要するに並列化とか SIMD 化とか入れたら35,000倍のパフォーマンスが出るようだけど、これは Python の部分とは呼べなくて、素の Python 動かして本当にそういえるかは怪しくない？とのことで、判断保留します 🙇🏻♀️ k0kubun さんありがとう 言語のデザインとしては、AI 開発に向けたプログラミングを提供できるよう設計されていると感じる。表側は Python
PEP 8騒動について - methaneのブログ
今週PEP 8の小さい変更についてMLで騒動が起こってしまいました。 該当のコミットはこれです。 PEP 8: Change requirement to adhere to Standard English (#1470) · python/peps@0c6427d · GitHub 変更点はごくごくシンプルなものです。 - When writing English, follow Strunk and White. + Ensure that your comments are clear and easily understandable to other + speakers of the language you are writing in. 今まで知らなかったのですが、変更前の "Strunk and White" とは The Elements of Style というすご
pythonを三行でセグフォらせる - Qiita
$ docker run -ti python:3.8-slim bash # pip install mysql-connector-python==8.0.20 # python >>> import random >>> import mysql.connector Segmentation fault 何が起こっているのか。 前提 mysql-connector-pythonは8.0.20からlibcrypto.so.1.1 とlibssl.so.1.1をbundleするようになりました。 $ pip show -f mysql-connector-python | grep lib Location: /usr/local/lib/python3.8/site-packages mysql-vendor/libcrypto.so.1.1 mysql-vendor/libssl.s
Pythonの__init__なんて読むの問題 - Qiita
Pythonの__init__これなんて読むのかと思ってたら、"dunder init"と読むらしいです。 python wikiに書いてあることを抜粋すると、 とあるインターネット上のフォーラムにてMark Jacksonと言う人が以下のように提案したのが発端らしいです。 An awkward thing about programming in Python: there are lots of double underscores. My problem with the double underscore is that it's hard to say. How do you pronounce __init__? "underscore underscore init underscore underscore"? "under under init under under"?
pycallを使ってみての感想 - 環境構築・零
(RubyAdventCalendar2017の代わりに投稿記事にしました) github.com Rubyでpython3ライブラリを読むことができます。 こんな風に書いていけました。 Vimプラ銀まで進めていきたいと思います。 gem install pycall gem install matplotlib #coding: utf-8 require 'pycall/import' include PyCall::Import sys = PyCall.import_module('sys') puts sys.stdout.encoding pyimport :datetime puts datetime.date.today() pyimport :datetime puts datetime.datetime.now().strftime('%Y/%m/%d %H:%M:%S
Pythonにおける % と str.format() 。どっちを使うの？ - Qiita
当座の理解としては おそらく「どっちでもいい」です。チームに依ると言っても良いでしょう。 str.format() は導入当初 %-style を置き換える意図がありました。 実際に str.format() の方が推奨されていた時期もあるようです。 現時点では、どちらを推奨とされているか、明示的な規定はないように見受けられます。 将来どうなるかは分かりませんが、直近で %-style が消えるという議論にはなっていません。 (追記) 新しいバージョンでは f-stringと呼ばれるフォーマット方法も f'This is a {stuff}' も使えます 日本の書籍より Python本の隠れた(失礼！)名著『Python文法詳解』にこうあります (p128) Python3.2までは、Pythonチュートリアルなどで「古い%演算子による文字列化は、いずれ削除されます」とされていましたが、P
Rubyが今のPythonの地位にいない理由
_ Rubyが今のPythonの地位にいない理由 歴史のことなんぞなんも知らんけど、「技術的には今のPythonの地位はRubyでもよかったのに、そうならなかった」のが何故か、その理由を書いてみよう。僕はRubyの歴史なんて知らないし、以下の文章は全部、まるで見てきたかのように書いてますが、適当に書いたくせに何故か断言口調になっている怪文書の類いです。 https://twitter.com/mametter/status/741950239662170112 まめさんの書いた理由リストはどれも関係ない。いやカスってるけど。難しいというのも関係ない。 僕がRubyを知ったころ…最初に書いた通りRubyの歴史なんて知らないので、別に早くもないわけだけど…Rubyというのは全く使われていない言語だった。どっかの好き者がPerlの替わりに単純な処理に使って、「ウフ、美しくかけた、グフッ」とかつぶ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2019年Python商標事件 - 西尾泰和のScrapbox
「Excel」に「Python」が統合される？ Microsoftがアンケートを実施中／来年後半のリリースが予定されている「Office 2019」の目玉機能に……との期待も膨らむ【やじうまの杜】
http://kwatch.houkagoteatime.net/blog/2014/08/24/python-pitfalls/