Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Active development, making library async compatible, client agnostic etc.

オープン
#248 コメント 0 件 リアクション 4 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
15/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
python
領域
backend

調査の方向性

まず、既存の完全なテストスイートを、リンクされている httpx-caching の fork、および参照されている pull request 240 と 225、さらに issue 232 と併せて確認してください。提案されている方向性は、sans-IO テストを備えた、クライアントに依存しない sync/async キャッシュライブラリです。完了とするには、単一の局所的な変更ではなく、合意された設計と実装計画が必要になります。

索引モデルが issue の本文から書いたものです。

説明

Just wanted to create a bit of a point of discussion regarding "the big picture".

It would seem that @ionrock doesn't have masses of time to spend on this project at the moment. It works great, and a lot of people use it. Smaller changes are being merged but the occasional burst of more extensive input / PRs by contributors tend to fizzle out. This is totally understandable. But would be great if this energy could be put to use!

At the end of last year I got excited about httpx and decided I wanted to try and port this library to work with it. I then got larger aspirations and decided to try and separate the caching logic from the IO following the sans-io philosophy (and therefor also the requests specific stuff). This would mean it could have a transport for requests and a transport for httpx, and would also be fully asyncio compatible.

To be honest it was more a bit of fun than anything, but I had a bee in my bonnet and got it working, with the full test suite passing, sync and async. The caching policy is implemented as a coroutine, which seemed a pretty neat abstraction at the time. It works with async, but there's only an in-memory cache backend at the moment. Other backends could be added with full asyncio compatibility which would be cool!

I guess the big question is, is there enough interest / energy out there to make something happen.

My vision would be a httpx/requests agnostic, sync async compatible library. The test suite would be all data in and out of the sans-io protocol, no need for mocking requests etc. (this isn't something I got round to doing but shouldn't be hard to do with the existing test suite).

My fork may or may not be a good starting point! I'm quite happy with it..

I wish I could say I had loads of time and energy to put into something like this, but health issues mean I might not be able to offer much more than discussion and code reviews, and my fork if someone wanted to use it as a starting point. I also hope I'm not treading on any toes, just don't want to see good intentions and code go to waste.

https://github.com/ionrock/cachecontrol/pull/240
@Flameeyes's large refactor PR (would have based my fork on this if I'd known about it)
https://github.com/ionrock/cachecontrol/pull/225
https://github.com/ionrock/cachecontrol/issues/232

@Flameeyes @hexagonrecursion

主要言語
Python
スター
505
フォーク
153
平均マージ
5日 6時間
マージ済み PR(30日)
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

psf/cachecontrol のほかの issue

psf/cachecontrol の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。