alive progress
1.0.0
長い処理がどこで行われ、いつ終わるのか考えたことはありますか?通常、クラッシュしていないか、SSH 接続がフリーズしていないかを確認するために、 RETURN数回押しますか?手間をかけずに一部の処理を一時停止し、Python プロンプトに戻っていくつかの項目を手動で修正し、その後シームレスに再開できたら素晴らしいと思ったことはありませんか?やった...
私はこれらすべてを考えながら、この新しいプログレスバーを開始しました。生き生きとしたプログレスを見てください! ?
Python のプログレスバーに最新のコンセプトが導入されました。 alive-progress 、他とは一線を画す優れた機能を多数備えた、独自のクラスにあります。以下にいくつかのハイライトを示します。
check()ツールもあります。生成されたフレームとアニメーション サイクルがどのように見えるか、画面上で展開されるかを確認することができます。さらに、 alive-progressでインストールする前に、実際に動作していることも確認できます。それは世界で最もクールなツールです！あなたの創造力を解き放ちましょう！ この README は常に進化しているため、時々より包括的な内容を確認してください。他のセクションで素晴らしい新しい詳細が見つかる可能性があります。 ?
alive-progressの使用bar()ハンドラー約 1 年間の安定した安定性を経て、新しいalive-progressがついに上陸しました。
主な機能と改善点は次のとおりです。
0および-Nを指定してbar()を呼び出して逆方向に戻すことができます。反復処理で何も進められなかった場合、または何かをロールバックする必要がある場合に便利です。さらに！
enrich_offset指定できるようになりました。これにより、 on 1:開始することも、前の計算から離れたところから続行することもできます。とてもクールなアップデートがここにあります!磨きをかけ、端末サポートを改善することに加えて、 alive-progress計算の再開をサポートするようになりました。
巨大なデータセットや長時間かかるものを処理する場合、バッチを使用するか、部分的な結果をキャッシュすることがあります。その後、停止して再起動した場合に、すでに完了したアイテムをすべて非常に早くスキップすることになり、 alive_bar 1 秒あたり数千のアイテムを処理していると認識し、ETA が完全に台無しになります...しかし、もうそのようなことはありません。 ！項目をスキップしたことをbar()に伝えるだけです...?
次の 2 つの方法で使用できます。
1.どこで停止したかがわかっている場合:
with alive_bar ( 120000 ) as bar :
bar ( 60000 , skipped = True )
for i in range ( 60000 , 120000 ):
# process item
bar ()はい、項目の数を指定してbar(N, skipped=True) 1 回呼び出すだけです。
2.分からない場合、またはアイテムが散乱している場合：
with alive_bar ( 120000 ) as bar :
for i in range ( 120000 ):
if done ( i ):
bar ( skipped = True )
continue
# process item
bar ()はい、それはとても簡単です!項目がすでに完了している場合はbar(skipped=True)を呼び出すか、それ以外の場合は通常どおりbar()呼び出します。最後に単一のbar(skipped=?)呼び出しを共有し、その項目をスキップしたかどうかをブール値で示すこともできます。クールですね？
このバージョンでは次のことも可能です。
max_cols構成設定、Jupyter やサイズをサポートしていない他のプラットフォームのようにフェッチできない場合に使用する列の数はい、ついにこのバージョンをリリースすることができました!新しいグッズは次のとおりです。
B 、 bytes 、さらには°Cなどのラベルを付けることができるようになりました。sys.stdoutの代わりにsys.stderrおよびその他のファイルの使用をサポートします。大いに期待される修正:
TypeError: unhashable type: 'types.SimpleNamespace'はなくなりました。RotatingFileHandler使用時のロギングのサポート!はい、サポートを求めるのはここです。そして最後に、上達を楽しむためのより洗練されたレイアウトも重要です。
現在、 alive_barデュアル ラインテキスト モードをサポートしています。
バー内に長い状況メッセージを含めたい場合は、おそらく 1 行に詰め込まれていると感じたことがあるでしょう。必要なものを表示するには、美しくアニメーション化されたバーを縮小するか、さらに悪いことにウィジェット (!) を削除する必要がありました...
もうない！！これで、バーをDual Lineにして、その下にテキストを配置できるようになりました。
はい、バー全体の下にメッセージがあり、他の印刷/ログメッセージはその上にスクロールします。
letters = [ chr ( ord ( 'A' ) + x ) for x in range ( 26 )]
with alive_bar ( 26 , dual_line = True , title = 'Alphabet' ) as bar :
for c in letters :
bar . text = f'-> Teaching the letter: { c } , please wait...'
if c in 'HKWZ' :
print ( f'fail " { c } ", retry later' )
time . sleep ( 0.3 )
bar ()出力：
on 7: fail "H", retry later
on 10: fail "K", retry later
Alphabet |███████████████████████████▊ | ▃▅▇ 18/26 [69%] in 6s (3.2/s, eta: 3s)
-> Teaching the letter: S, please wait...
また、 alive_itには新しいfinalize関数パラメータがあり、最終レシートのタイトルやテキストを設定できるようになり、カスタマイズされたロガーを検出するロギング サポートが強化されました。
これはすべてカスタマイズに関するものです。コア ウィジェットを変更できるようになりました。
monitor 、 elapsed 、およびstatsウィジェットに文字列を送信して、希望どおりに表示できるようにします。これらの文字列がすべての Python 形式機能をサポートしていることは驚くべきことであり、たとえば、
{percent:.1%}が可能です。
最終レシートではさらにカスタマイズすることができます。
monitor_end 、 elapsed_end 、およびstats_end 、標準のものから継承された動的フォーマットを備えています。以前にレシートに表示されないようにいくつかのウィジェットを非表示にしたことがある場合は、今ではそのすべての機能を表示し、レシートのウィジェットだけを非表示にすることができます。それともその逆ですか？
もう 1 つの追加として、 alive-progress途中で CTRL+C を押した場合でも、停止するたびにクールな最終レシートを美しくレンダリングするようになりました。なぜ今までそのことを考えなかったのかわかりません...
Download |██████████████████︎ | (!) 45/100 [45%] in 4.8s (9.43/s)
そして最後に、CTRL+C をまったく無効にすることもできます。デフォルトはより安全なctrl_c=Trueで、これにより CTRL-C が通常どおり機能します。
インタラクティブなalive_barよりスムーズに使用するには (停止するとスタック トレースがなくなります)、またはプログラムのトップレベルにある場合は、 ctrl_c=False無効にします。
注意してください: たとえば、for ループ内にある場合は、次の反復に進むだけですが、これは希望どおりになる場合とそうでない場合があります。
for i in range ( 10 ):
with alive_bar ( 100 , ctrl_c = False , title = f'Download { i } ' ) as bar :
for i in range ( 100 ):
time . sleep ( 0.02 )
bar ()出力：
Download 0 |████████▊︎ | (!) 22/100 [22%] in 0.6s (36.40/s)
Download 1 |████████████████▊︎ | (!) 42/100 [42%] in 1.0s (41.43/s)
Download 2 |██████▍︎ | (!) 16/100 [16%] in 0.4s (39.29/s)
Download 3 |█████▋︎ | (!) 14/100 [14%] in 0.4s (33.68/s)
Download 4 |█████████████▎︎ | (!) 33/100 [33%] in 0.8s (39.48/s)
Download 5 |███████▎︎ | (!) 18/100 [18%] in 0.5s (37.69/s)
Download 6 |█████▎︎ | (!) 13/100 [13%] in 0.3s (37.28/s)
Download 7 |████████████︎ | (!) 30/100 [30%] in 0.8s (38.43/s)
Download 8 |██████︎ | (!) 15/100 [15%] in 0.4s (36.26/s)
...
リクエストの多かったいくつかの主要な新機能がついに登場しました。
click.echo()印刷の新しいサポートはい！現在、 alive-progress Jupyter Notebook をサポートし、無効状態も含まれています。どちらも大変人気があり、ついに入荷しました！
さらに良いことに、jupyter ノートブック用の自動検出メカニズムを実装したので、コードを変更することなく、すぐに機能します。
自分の目で見てください:
非常にうまく機能しているように見えますが、現時点では実験的であると考えるべきです。
2 つのalive_bar更新が互いにではなく連結されるなど、いくつかの視覚的な不具合が発生する例がありました...そして、これはおそらく回避できないと思います。Jupyter は時々奇妙なタイミングでキャンバスを更新するようです。これにより、一部のデータが失われます。もっとおかしなことが起こった場合は、問題についてお知らせください。
これは、 alive-progressにおける大きな進歩です。
開発には 1 年かかりましたが、自分が達成したことをとても誇りに思っています o/
.check()ツール。完全なフレーム データ、内部コードポイント、アニメーションさえも含めることができます。 ?alive-progressウィジェットの無効化のサポートなど、外観をカスタマイズするためのいくつかの新しい構成オプション。alive_itが含まれており、イテラブルを受け入れてbar()を呼び出します。これはメジャー バージョンの変更であるため、直接の下位互換性は保証されません。最初に何かが機能しない場合は、新しいインポートと関数のシグネチャを確認するだけで問題ありません。以前の機能はすべてここでも動作するはずです。 ?
alive-progressの使用pip でインストールするだけです。
❯ pip install alive-progressどのようなスタイルが組み込まれているのか気になるなら、今こそshowtimeです! ;)
from alive_progress . styles import showtime
showtime ()注: 下のアニメーション GIF のパスは無視してください。正しいパスは上にあります。これらの長い GIF は生成に非常に時間がかかるため、変更を加えるたびに別の GIF を作成することはできません。ご理解いただきありがとうございます。
私が作成したすべてのアニメーション ファクトリーを試すためにこれらのスタイルを作成しましたが、そのうちのいくつかは非常に非常にクールに仕上がったと思います。自由に使って、思う存分混ぜてください！
自分で試してみる前に、実際のalive-progressバーがシステム内で見事に実行されているのを見てみたいですか?
❯ python -m alive_progress.tools.demoかっこいいですね??次に、 ipython REPL を入力して、これを試してください。
from alive_progress import alive_bar
import time
for x in 1000 , 1500 , 700 , 0 :
with alive_bar ( x ) as bar :
for i in range ( 1000 ):
time . sleep ( .005 )
bar ()プロセス全体でクールなアニメーションが表示される、次のような画面が表示されます。
|████████████████████████████████████████| 1000/1000 [100%] in 5.8s (171.62/s)
|██████████████████████████▋︎ | (!) 1000/1500 [67%] in 5.8s (172.62/s)
|████████████████████████████████████████✗︎ (!) 1000/700 [143%] in 5.8s (172.06/s)
|████████████████████████████████████████| 1000 in 5.8s (172.45/s)
いいですね。気に入りましたか?きっとそうしてくれると思っていました、ありがとう?
実際に使用するには、次のように、 alive_barコンテキスト マネージャーで通常のループをラップするだけです。
with alive_bar ( total ) as bar : # declare your expected total
for item in items : # <<-- your original loop
print ( item ) # process each item
bar () # call `bar()` at the endそしてそれは生きています！ ?
つまり、簡単に言うと、いつものように項目を取得し、項目の数を指定してalive_barコンテキスト マネージャーに入り、最後にbar()を呼び出してそれらの項目を反復/処理します。それはとても簡単です！ :)
itemsを指定できます。alive_barの最初の引数は、クエリセットのqs.count()長さのある反復可能オブジェクトのlen(items) 、さらには静的な数値など、予想される合計です。bar()呼び出しは、バーを前進させるものです。通常、反復ごとに、項目を終了した直後に呼び出します。bar()呼び出しが多すぎると (または最後に少なすぎると)、バーは予想されるtotalからの偏差をグラフィカルに表示するため、オーバーフローとアンダーフローに非常に気づきやすくなります。bar.currentを呼び出します。クリエイティブになれる！バーは
bar()を呼び出したときにのみ前進するため、ループとは独立しています。したがって、これを使用して、保留中のトランザクション、壊れたアイテムなど、必要なものを監視したり、同じ反復内で複数回呼び出すこともできます。したがって、最終的には、それらの「特別な」イベントが何件あったか、全体に対する割合も含めて知ることができます。
alive_barコンテキスト内で、現在表示されている進行状況バーと緊密に統合されたメッセージを簡単に表示できます。決して壊れることはなく、メッセージを豊かにすることもできます。
bar.text('message')とbar.text = 'message'状況に応じたメッセージをバー内に設定します。ここで、現在の項目や処理のフェーズに関する情報を表示できます。bar.title('Title')およびbar.title = 'Title'でいつでも変更できます。バーが変更されないようにtitle_lengthと組み合わせます。長さ;print()ステートメントでは、 alive_bar行を適切にクリーンアップし、その時点の現在のバー位置の横にメッセージを出力し、そのすぐ下のバーを継続します。loggingフレームワークも、以前のものとまったく同様に強化されています。click.echo()使用してスタイル付きテキストを印刷することもできます。すごいですよね？これらはすべて、ターミナルでも Jupyter ノートブックでも同じように機能します。
あらゆるものをより迅速に監視できるようになりました。ここでは、アイテムは自動的に追跡されます。
alive_it => alive_barイテレータ アダプタを見てください。
アイテムを包んで、いつものようにループをかけるだけです。
バーはそのまま機能します。それはとても簡単です！
from alive_progress import alive_it
for item in alive_it ( items ): # <<-- wrapped items
print ( item ) # process each itemなんてクールなんでしょう?! ?
すべてのalive_barパラメータが適用されますが、 total方が賢明です(指定しない場合は、 lenまたはlength_hint使用してデータから自動推論されます)。 manualはここでは意味がありません。
そこにはbarハンドルがまったくないことに注意してください。しかし、テキスト メッセージを設定したり、現在の進行状況を取得したりしたい場合はどうすればよいでしょうか?
次のように、 alive_it変数に割り当てるだけで、内部のalive_barを操作できます。
bar = alive_it ( items ) # <<-- bar with wrapped items
for item in bar : # <<-- iterate on bar
print ( item ) # process each item
bar . text ( f'ok: { item } ' ) # WOW, it works!これは少し特殊なbarであり、イテレータ アダプタが項目を自動的に追跡するため、 bar()サポートしていないことに注意してください。また、 finalizeもサポートされており、最終的な領収書のタイトルやテキストを設定できます。
alive_it ( items , finalize = lambda bar : bar . text ( 'Success!' ))
...一言で言えば:
- 完全に使用するには、常に
with alive_bar() as bar、必要なときにいつでもbar()を反復して呼び出します。- クイック アダプターの使用は、
for item in alive_it(items)行われ、項目は自動的に追跡されます。- アダプターの完全な使用は
bar = alive_it(items)です。ここでは、項目が自動的に追跡されることに加えて、内部のalive_progress必要に応じてカスタマイズできる特別な反復可能なbarを取得します。
デフォルトのモードはautoおよびunknownで、内部的にカウンターを使用して進行状況を追跡します。処理されたアイテムの数をカウントし、それを使用して進行状況バーを更新します。
total引数はオプションです。これを指定すると、バーは自動モードになります。このモードでは、操作の進行状況が自動的に追跡され、 alive-progressが提供するすべてのウィジェット (正確なバー、スピナー、パーセンテージ、カウンター、スループット、ETA) が利用可能です。
total指定しない場合、バーは不明モードに入ります。このモードでは、進行状況が確定できないため、ETA が確定できないため、進行状況バー全体が継続的にアニメーション化されます。使用可能なウィジェットは、アニメーション バー、スピナー、カウンター、およびスループットです。
クールなスピナーはアニメーション バーとは完全に独立して実行され、両方とも独自のアニメーションを同時に実行し、端末内で独自のショーをレンダリングします。 ?
最後になりましたが、自動モードにはユニークな機能があります。項目をスキップ済みとしてマークし、スループットと到着予定時刻をより正確にします。それについては後で詳しく説明します。
手動モードは、 manual=True引数によって手動でアクティブ化され、内部的にパーセンテージを使用して進行状況を追跡します。これにより、バーの位置を完全に制御できるようになります。通常、完了率のみを通知するプロセスを監視するため、またはランダムな特殊効果を生成するために使用されます。
これは、 alive_barで直接使用することも、 config_handler経由で使用することもでき、 bar()ハンドラーにパーセンテージを送信することもできます。たとえば、完了率 15% に設定するには、 bar(0.15) (15 / 100) を呼び出すだけです。
ここでtotalを指定することもできます。そうする場合、 alive-progress内部カウンターを自動的に推論し、自動モードで利用可能な同じウィジェットをすべて提供できるようになります。
totalを指定しない場合は、少なくともスループットと ETA ウィジェットの大まかなバージョンが取得され、それぞれ "%/s" (1 秒あたりのパーセンテージ) として計算され、100% まで計算されます。どちらもあまり正確ではありませんが、何もしないよりはマシです。
totalが提供されると、すべてがクールになります:
| モード | カウンタ | 割合 | スループット | 到着予定時刻 | オーバー/アンダーフロー |
|---|---|---|---|---|---|
| 自動 | ✅ (ユーザーのチェックマーク) | ✅ (推測) | ✅ | ✅ | ✅ |
| マニュアル | ✅ (推測) | ✅ (ユーザー設定) | ✅ | ✅ | ✅ |
そうでない場合は、いくつかの妥協をする必要があります。
| モード | カウンタ | 割合 | スループット | 到着予定時刻 | オーバー/アンダーフロー |
|---|---|---|---|---|---|
| 未知 | ✅ (ユーザーのチェックマーク) | ✅ | |||
| マニュアル | ✅ (ユーザー設定) | ✅ |
しかし、実際には理解するのは簡単です。どのモードを使用するかを考える必要はありません。
totalがある場合は常に送信し、必要な場合はmanual使用してください。それでおしまい！最大限の効果を発揮します！ ? o/
bar()ハンドラーbar()ハンドラーは、モードに応じて相対セマンティクスまたは絶対セマンティクスをサポートします。
bar()呼び出してカウンターを 1 つインクリメントするか、 bar(200)のような他の増分を送信して一度に 200 ずつインクリメントすることができます。必要に応じて保持または減分する
bar(0)とbar(-5)もサポートしています。
bar(0.35)を呼び出して、バーを即座に 35% の進行状況にジャンプさせることができます。どちらのモードでも創造性を発揮できます。バーを任意の位置に即座に移動させることができるので、次のことができます。
- 逆方向に移動します。たとえば、何かのタイムアウトをグラフィカルに表示します。
- 特殊効果を作成します。たとえば、ある種のリアルタイムのアナログ ゲージを模倣します。
bar()何度でも呼び出すことができます。端末のリフレッシュ レートは、現在のスループットと進行状況に応じて常に非同期的に計算されるため、必要以上の更新を端末にスパム送信する危険はありません。
いずれの場合でも、現在のカウンター/パーセンテージを取得するには、 bar.currentを呼び出すだけです。
最後に、 bar()ハンドラーは自動モードの固有の機能を利用します。これを使用するには、 bar(skipped=True)またはbar(N, skipped=True)を呼び出すだけです。 skipped Trueに設定されている場合、関連するアイテムはスループット計算から除外され、スキップされたアイテムが ETA に不正確な影響を与えるのを防ぎます。
オープンソース プロジェクトを維持するのは大変で時間もかかりますが、私はこれに多くの❤️と努力を費やしてきました。
私の仕事を評価していただけましたら、寄付で私をサポートしていただけます!ありがとう ？
showtime展示には、どのショーを提示するかを選択するためのオプションの引数、 Show.SPINNERS (デフォルト)、 Show.BARSまたはShow.THEMESがあります。ぜひ見てください。 ;)
from alive_progress . styles import showtime , Show
showtime ( Show . BARS )
showtime ( Show . THEMES )注: 下のアニメーション GIF のパスは無視してください。正しいパスは上にあります。これらの長い GIF は生成に非常に時間がかかるため、変更を加えるたびに別の GIF を作成することはできません。ご理解いただきありがとうございます。
そしてテーマ 1 (? 2.0 の新機能):
showtime展示では、いくつかのカスタマイズ オプションも利用できます。
たとえば、海洋ショーを表示するには、 showtime(pattern='boat|fish|crab')実行します。
これらのショーには、短縮形
show_bars()、show_spinners()、およびshow_themes()を使用してアクセスすることもできます。
print_chars()と呼ばれる小さなユーティリティもあります。これは、カスタマイズされたスピナーやバーに入れるクールな文字を見つけたり、端末が Unicode 文字をサポートしているかどうかを判断したりするのに役立ちます。
外観と動作の両方をカスタマイズするためのオプションがいくつかあります。
これらはすべて、 alive_barで直接設定することも、 config_handlerでグローバルに設定することもできます。
これらはオプションです - 括弧内のデフォルト値は次のとおりです。
title : オプションの、常に表示されるバーのタイトルlength : [ 40 ] アニメーション化されたプログレスバーをレンダリングする列の数max_cols : [ 80 ] jupyter のように取得できない場合に使用する最大列数spinner : バーの隣にレンダリングされるスピナー スタイルbar : 既知のモードでレンダリングされるバーのスタイルunknown : 不明なモードでレンダリングされるバーのスタイルtheme : [ 'smooth' ] 一致するスピナー、バー、および不明のセットforce_tty : [ None ] アニメーションをオン、オフ、または tty に従って強制します (詳細はこちら)file : [ sys.stdout ] 使用するファイル オブジェクト: sys.stdout 、 sys.stderr 、または同様のTextIOWrapperdisable : [ False ] True の場合、すべての出力を完全に無効にし、フックをインストールしません。manual : [ False ] バーの位置を手動で制御するように設定しますenrich_print : [ True ] print() とログメッセージをバーの位置で強化します。enrich_offset : [ 0 ] rich_print に適用するオフセットreceipt : [ True ] は適切な最終領収書を印刷します。 False の場合は無効になります。receipt_text : [ False ] 最後の受信メッセージで最後のテキスト メッセージを繰り返すように設定します。monitor (bool|str): [ True ] モニター ウィジェット152/200 [76%]を設定します。{count} 、 {total}および{percent}を含む文字列を送信してカスタマイズしますelapsed (bool|str): [ True ] 経過時間ウィジェットをin 12s構成します{elapsed}を含む文字列を送信してカスタマイズしますstats (bool|str): [ True ] 統計ウィジェットを構成します(123.4/s, eta: 12s){rate}と{eta}を含む文字列を送信してカスタマイズしますmonitor_end (bool|str): [ True ] 最終受信内でモニター ウィジェットを構成しますmonitorのフォーマットを継承します。elapsed_end (bool|str): [ True ] 最終受信内の経過時間ウィジェットを構成しますelapsedの形式を継承します。stats_end (bool|str): [ True ] 最終受信内で統計ウィジェットを構成します{rate}を含む文字列を送信してカスタマイズします（統計とは関係ありません）title_length : [ 0 ] タイトルの長さを固定するか、無制限の場合は 0spinner_length : [ 0 ] はスピナーの長さを強制するか、自然な長さの場合は0指定します。refresh_secs : [ 0 ] はリフレッシュ周期をこれに強制します0はリアクティブな視覚的フィードバックです。ctrl_c : [ True ] False の場合、CTRL+C を無効にします (キャプチャします)。dual_line : [ False ] True の場合、テキストをバーの下に配置しますunit : エンティティにラベルを付ける任意のテキストscale : 単位に適用するスケーリング: None 、 SI 、 IEC 、またはSI2Falseまたは'' -> None 、 True -> SI 、 10または'10' -> SI 、 2または'2' -> IECprecision : [ 1 ] スケーリング時に表示される小数点以下の桁数また、 alive_barコンテキストでローカルにのみ設定できるものもあります。
calibrate : アニメーション速度を調整するための理論上の最大スループット (詳細はこちら)これらをローカルに設定するには、それらをキーワード引数としてalive_barに送信するだけです。
with alive_bar ( total , title = 'Processing' , length = 20 , bar = 'halloween' ) as bar :
...これらをグローバルに使用するには、それらをconfig_handlerに送信します。その後作成されるすべてのalive_barには、それらのオプションが含まれます。それらを組み合わせて使用することもできます。ローカル オプションは常にグローバル オプションよりも優先されます。
from alive_progress import config_handler
config_handler . set_global ( length = 20 , spinner = 'wait' )
with alive_bar ( total , bar = 'blocks' , spinner = 'twirls' ) as bar :
# the length is 20, the bar is 'blocks' and the spinner is 'twirls'.
...はい、自分でスピナーを組み立てることができます。そしてそれは簡単です！
たくさんの特殊効果を作成したので、好きなように組み合わせてください。フレーム、スクロール、バウンス、シーケンシャル、横並び、遅延スピナーがあります。クリエイティブになろう！ ?
スピナーのアニメーションは、メタ ファクトリ、ファクトリ、ジェネレータのいくつかの層の奥深くにある、非常に高度なジェネレータ表現によって設計されています。
alive_barとconfig_handler両方に送信するオブジェクトです。これらのジェネレーターは、スピナーの動作に応じて複数の異なるアニメーション サイクルを実行できます。たとえば、バウンドするスピナーは 1 サイクルを実行して被写体をシーンにスムーズに移動させ、次に反対側に移動するまで繰り返し位置を変更し、シーンからスムーズに消えることができます = > そしてこれはすべてたったの 1 サイクルです。その後、別のサイクルを続けて、すべてを元に戻します。また、バウンドするスピナーは、右方向と左方向の両方で異なる交互のパターンを受け入れるため、すべての組み合わせのデカルト積を生成し、おそらくそれらを繰り返し始めるまで何十もの異なるサイクルを生成します。 ?
そしてさらに、このアニメーション システムで私が得た最も印象的な成果の 1 つは (スピナー コンパイラ自体を除けば) あると思います... 現在のサイクルが使い果たされるまで、より多くのアニメーション フレームを生成するだけで、その後は自動的に停止します。そう、次のサイクルはまだ始まっていません。この動作により、アニメーションが中断されずに正確に正しい場所で自然な中断が作成されるため、必要な他のアニメーションとスムーズにリンクできます。
これには、あらゆる種類の素晴らしい意味が含まれています。サイクルには、異なるフレーム数、異なる画面長を指定でき、同期する必要がなく、長い異なるシーケンスを単独で作成でき、協力してサイクルを連続または並行して再生できます。まったく異なるアニメーションを何の干渉もなしに同時に表示できるのは驚くべきことです。
まるで...生きているかのようです!! ?
==> はい、それがこのプロジェクト名の由来です。
現在、これらのサイクルとフレームのジェネレーターは、 Spinner Compilerによって事前に完全に消費されます。これは、セル アーキテクチャの取り組みの中で私が作成した非常にクールな新しいプロセッサで、ワイド キャラクタや複雑な書記素クラスタが存在する場合でも、これらすべてのアニメーションを機能させることができます。これらのクラスターが Unicode エンコーディングを壊さないようにしながら、特にすべてのフレームで元の長さを維持しながら、スムーズにフレームに徐々に出入りするようにするのは、非常に困難でした。はい、連続した複数の文字は別の完全に異なるシンボルを表すことができるため、分割することはできません。常に一緒にフレームに出入りしなければなりません。そうしないと、書記素 (たとえば絵文字) がまったく表示されなくなります。 Spinnerコンパイラを入力して……
これにより、いくつかの信じられないことが可能になりました!!このコンパイラはスピナー フレーム データ全体を事前に生成するため、次のようになります。
したがって、実行準備ができているアニメーションをすべて収集するだけで完了します。実行時のオーバーヘッドはまったくありません。 ?
また、完全なフレーム データがコンパイルされ永続化されているため、形状の変更、文字の置き換え、視覚的な一時停止 (フレームの繰り返し) の追加、コンテンツに対するオンデマンドでのバウンス効果の生成、さらにはサイクルの転置など、そのデータをリファクタリングするためのいくつかのコマンドを作成できます。フレーム付き!!
しかし、これらの効果はどのようにして確認できるのでしょうか?作成したエフェクトはうまくいきましたか?それとも思った通りに動かないのでしょうか？はい、生成されたすべてのサイクルとフレームを分析的に、非常に美しいレンダリングで確認できるようになりました。
私はここで達成したものが大好きです?、おそらくこれは私がこれまでに作成した中で最も美しいツールです... checkツールを見てください!!
自分で言うのもなんですが、すごいですよね？そして、私が誇りに思っている非常に複雑なソフトウェアです。もしよろしければ、そのコードを見てください。
そして、 checkツールははるかに強力です！たとえば、フレームのコードポイントを見ることができます!!!そして、なぜこのバージョンがそんなにそうであったのかを垣間見ることができます。
赤には、実際のサイズに関係なく、1つまたは2つの「論理的位置」を占めるグラフェメムクラスターが見えます...これらは新しいセルアーキテクチャの「セル」です...
絵文字の旗がどれほど素晴らしいか見てください：
フラグは「ハーフキャラクター」を使用しているため、非常にスムーズに動いているようです！それは幅広い文字であるため、 alive-progressそれが「2つの可視チャー」でレンダリングされることを知っており、アニメーションはこれを考慮しますが、1つだけを占めるスペースで構成されています。混合背景を使用すると、状況ははるかに複雑です...
私が作成した工場の種類は次のとおりです。
frames ：順番にフレームごとに再生されるキャラクターのシーケンスを自由に描画します。scrolling ：片側から他方への滑らかな流れを生成し、目に見えない境界線の後ろに隠れたり包んだりします。一度に1つずつ被験者を使用して、数サイクルの異なる文字を生成します。bouncing ： scrollingに似ていますが、アニメーションをスタートに戻したり、後ろに隠したり、目に見えない境界を跳ね返したりします。sequentialして、次のように順次演奏してください！それらをインターミックスできるかどうか。alongside入れて、同時に一緒に演奏するのに、なぜそれらをすべて手に入れることができるのかを選ぶのはなぜですか？！アニメーションのピボットを選択できます。delayed ：他の工場を取得して複数回コピーし、それぞれにいくつかのフレームをスキップすることがますます増えています！ここでは非常にクールな効果があります！詳細については、非常に完全なDocstringsをご覧ください。
バーのカスタマイズは、その近くにありません。それらが「即時」の受動的なオブジェクトであるとしましょう。彼らはアニメーションをサポートしていません。つまり、同じパラメーターを与えられた同じ演出を常に生成します。スピナーは無限の発電機であり、長く複雑なシーケンスを生成できることを忘れないでください。
まあ、バーにはメタファクトリーもあり、閉鎖を使用してスタイリングパラメーターを保存し、追加の操作パラメーターを受け取りますが、実際の工場ではそれ自体でコンテンツを生成できません。まだ追加のパラメーター、0〜1の間の浮動小数点数が必要です。これは、それ自体をレンダリングする割合です。
alive_barカウンターと合計に基づいてこの割合を自動的に計算しますが、manualモードのときに自分で送信できます！
バーにはバーコンパイラもありませんが、チェックツールを提供しています!! ?
スピナーと同じように、広いチャーと通常のチャーをミックスしてマッチすることもできます！ （そして、すべてが完全に揃っていますか？）
あなたの心のコンテンツにチェックツールを使用してください!!彼らはあなたを待っているさらに多くのグッズ、リアルタイムのアニメーションを持っています！
あなたができる最もワイルドでクールなアニメーションを作成し、それらを私に送ってください！
私は、ユーザーがコントリブしたスピナーとバーを使用して、ある種のcontribパッケージを作成することを考えています！
うわー、あなたがここまですべてを読んだなら、あなたは今、 alive-progressを使用することについて健全な知識を持っているはずです！ ?
しかし、さらにエキサイティングなものが先にあるので、自分自身を締めます！
オープンソースプロジェクトを維持することは困難で時間がかかります。私はこれに多くのことと努力を注いでいます。
あなたが私の仕事に感謝しているなら、あなたは寄付で私をバックアップすることができます！ありがとう ？
ああ、あなたはそれを完全に一時停止したいです、私は聞きますか？これは驚くべき斬新なコンセプトであり、どこにも見つかりません。
これにより、継続的な処理の真っin中に、自由に手動でいくつかのアイテムに行動することができます!!
はい、あなたはプロンプトに戻って修正し、変更し、物事を送信することができます、そして、バーはそれがあった場所で「覚えている」だけです...
支払いトランザクションを調整する必要があると仮定します（そこにあります、それをしました）。何千もの反復を繰り返し、何らかの形で誤ったものを検出し、それらを修正する必要があります。この修正は単純でも決定的でもありません。何をすべきかを理解するには、それぞれを研究する必要があります。彼らは受信者を逃したり、間違った量を持っているか、サーバーなどと同期しない可能性があります。すべての可能性を想像することさえ困難です。
通常、検出プロセスを完了するまで実行する必要があります。最終的に修正を開始できるまで、見つけた各矛盾と待機を潜在的に長い間リストに追加する必要があります...もちろん、チャンクで処理することでそれを軽減できます、またはそれらを印刷して別のシェルなどを介して行動しますが、それらには独自の欠点があります...？
今、より良い方法があります！しばらくの間、実際の検出プロセスを一時停止するだけです！次に、次の障害が見つかるまで待たなければならず、ほぼリアルタイムで行動します！
一時停止メカニズムを使用するには、関数を記述するだけで、コードが対話するアイテムをyieldできるようにします。あなたはおそらくあなたのコードですでにそれを使用していますが、 ipythonシェルまたは別のREPLでは、おそらくそうではありません。したがって、デバッグコードを関数にラップしてから、 bar.pause()コンテキスト内に入力してください!!
def reconcile_transactions ():
qs = Transaction . objects . filter () # django example, or in sqlalchemy: session.query(Transaction).filter()
with alive_bar ( qs . count ()) as bar :
for transaction in qs :
if faulty ( transaction ):
with bar . pause ():
yield transaction
bar ()それでおしまい！それはとても簡単です！ o/
次に、 gen = reconcile_transactions()を実行してジェネレーターをインスタンス化し、次の故障したトランザクションが必要なときはいつでも、 next(gen, None) ！大好きです...
alive-progress Barは通常どおり開始して実行されますが、矛盾が見つかるとすぐに、バーはそれ自体を一時停止し、更新スレッドをオフにし、正確な状態を思い出し、プロンプトで直接トランザクションをもたらします！それはほとんど魔法です！ ?
In [11]: gen = reconcile_transactions()
In [12]: next(gen, None)
|█████████████████████ | 105/200 [52%] in 5s (18.8/s, eta: 4s)
Out[12]: Transaction<#123>
その後、通常の_ ipythonのショートカットでトランザクションを検査できます（または、 t = next(gen, None)で直接割り当てます）、すべて修正するように設定されています。
完了したら、以前と同じnext電話でバーを再アクティブ化するだけです!!バーは再び現れ、すべてを元に戻し、止まらなかったように続きます!!わかりました、それは魔法ですか？
In [21]: next(gen, None)
|█████████████████████ | ▁▃▅ 106/200 [52%] in 5s (18.8/s, eta: 4s)
最終的な領収書が表示されるまですすぎ、繰り返しますが、トランザクションが誤っていなくなります。 ?
だから、ループなしで固定操作を監視する必要がありますよね？
確かにうまくいくでしょう！ここに素朴な例があります（私たちはすぐにうまくやります）：
with alive_bar ( 4 ) as bar :
corpus = read_file ( file )
bar () # file was read, tokenizing
tokens = tokenize ( corpus )
bar () # tokens generated, processing
data = process ( tokens )
bar () # process finished, sending response
resp = send ( data )
bar () # we're done! four bar calls with `total=4`すべてのステップに同じ時間がかかると想定しているため、それは素朴ですが、実際には、それぞれが非常に異なる時間がかかる場合があります。 read_fileとtokenize非常に高速である可能性があるため、パーセンテージが50％に急増し、 processステップで長時間停止します...ポイントを獲得し、ユーザーエクスペリエンスを台無しにし、非常に誤解を招くETAを作成する可能性があります。
それを改善するには、それに応じて手順を配布する必要があります！ alive_barに4つのステップがあると言ったので、最初のステップが完了したとき、処理全体の1/4または25％が完了したと理解しています...したがって、手順を実際に取る時間を測定し、手動モードを使用して使用する必要があります。各ステップで適切な量だけバーの割合を増やしてください！
他のオープンソースプロジェクトを頃に使用して、これらの期間を簡単に測定できます！より良い結果を得るために、いくつかの代表的な入力でシミュレートするようにしてください。次のようなもの:
from about_time import about_time
with about_time () as t_total : # this about_time will measure the whole time of the block.
with about_time () as t1 : # the other four will get the relative timings within the whole.
corpus = read_file ( file ) # `about_time` supports several calling conventions, including one-liners.
with about_time () as t2 : # see its documentation for more details.
tokens = tokenize ( corpus )
with about_time () as t3 :
data = process ( tokens )
with about_time () as t4 :
resp = send ( data )
print ( f'percentage1 = { t1 . duration / t_total . duration } ' )
print ( f'percentage2 = { t2 . duration / t_total . duration } ' )
print ( f'percentage3 = { t3 . duration / t_total . duration } ' )
print ( f'percentage4 = { t4 . duration / t_total . duration } ' )さあ！これで、すべての手順の相対的なタイミングを知っており、それらを使用して元のコードを改善できます！累積タイミングを取得して、それらを手動モードalive_barに入れてください！
たとえば、見つけたタイミングが10％、30％、20％、40％の場合、0.1、0.4、0.6、および1.0を使用します（最後の0.4、0.6は常に1.0でなければなりません）：
with alive_bar ( 4 , manual = True ) as bar :
corpus = read_big_file ()
bar ( 0.1 ) # 10%
tokens = tokenize ( corpus )
bar ( 0.4 ) # 30% + 10% from previous steps
data = process ( tokens )
bar ( 0.6 ) # 20% + 40% from previous steps
resp = send ( data )
bar ( 1. ) # always 1. in the last stepそれでおしまい！ユーザーエクスペリエンスとETAは、今大幅に改善する必要があります。
はい、スピナー速度を校正できます！
alive-progressバーには、現在のスループットのクールな視覚的フィードバックがあるため、スピナーがより速くまたは遅くなるため、実際に処理の速さがわかります。
これを実現するために、私はいくつかのFPS曲線をまとめて実装して、どれが最高の速度の感触を与えたかを経験的に見つけました。
（インタラクティブバージョン[here]（https://www.desmos.com/calculator/ema05elsux）））
グラフは、対数（赤）、放物線（青）、線形（緑）曲線を示しています。これらは私が始めたものです。それは簡単な作業ではありませんでした、私は何十ものテストをしました、そして、私が探していたスピードの感覚に本当にインスピレーションを与えたものを決して見つけませんでした。最良のものは対数的なもののように見えましたが、少数とはうまく反応しませんでした。私はそれらの少数のためにいくつかのひねりで動作させることができることを知っているので、私は多くの実験をし、最終的に私が期待した動作を見つけるまで、対数曲線（点線オレンジ）を調整しました！それは、全体のスペクトル全体で数十億から数十億の最高のオールアラウンドの速度変化を提供するように思われたものです...それは私が落ち着いた曲線であり、それはすべてのモードと条件で使用される曲線です。将来的には、誰かがそれを役立つと思うなら、その曲線は構成可能である可能性があります。
さて、デフォルトのalive-progressキャリブレーションは、限界モードで1,000,000です。つまり、バーが毎秒60フレームで更新するには1秒あたり100万回の反復が必要です。マニュアルなしのモードでは、 1.0 （100％）です。どちらも膨大な動作範囲を有効にし、一般的に非常にうまく機能します。
たとえば、これらの非常に異なるキャリブレーションが持つ効果を見て、まったく同じ速度で同じコードを実行してください！スピナーがユーザーに渡される感触に注意してください、この処理は遅くなっていますか、それとも速く進んでいますか？そして、それはスピナーだけでなく、バーの演出とすべてのウィジェットを備えたライン全体であることを忘れないでください。
したがって、処理が毎秒20項目に到達することはほとんどなく、
alive-progress鈍化していると思う場合、40キャリブレーションすることでその速度を高めることができます。常にヘッドルームを離れて、50％から100％の間の何かにキャリブレーションし、そこから微調整して、最も好きなものを見つけることをお勧めします！ :)
これらの驚くべきalive-progressアニメーションは表示を拒否しますか？
Pycharmは素晴らしいです、私はそれが大好きです！しかし、なぜ彼らがデフォルトで端末をエミュレートすることを無効にしたのか理解できません... Pycharmの出力コンソールを使用している場合、すべての実行構成でこれを有効にしてください。
File>New Projects Setup>Run Configuration Templates、Python選択し、そこで有効にすることもお勧めします。そのため、作成した新しいものはすでにこのセットを持っています。
それに加えて、一部の端子は、実際のターミナル（たとえばPycharmやJupyter）を使い果たしたとき、シェルパイプライン（ cat file.txt | python program.py ）で、またはバックグラウンドで自分自身を「非相互作用」と報告しています。プロセス（TTYに接続されていません）。
alive-progress非対話端末に自分自身を見つけると、あらゆる種類のアニメーションを自動的に無効にし、最終領収書のみを印刷します。これは、パイプラインの出力を台無しにし、数千のalive-progressリフレッシュでログファイルをスパムすることを避けるために作られています。
だから、それが安全であることがわかったら、あなたは彼らにその栄光の中でalive-progress見るように強制することができます！これがforce_tty引数です：
with alive_bar ( 1000 , force_tty = True ) as bar :
for i in range ( 1000 ):
time . sleep ( .01 )
bar ()受け入れられている値は次のとおりです。
force_tty=True >常にアニメーションを有効にし、jupyterノートブックを自動検出します！force_tty=False >は常にアニメーションを無効にし、最終領収書のみを保持しますforce_tty=None （default） - >ターミナルのTTY状態に応じて自動検出config_handler使用してシステム全体に設定することもできるため、手動で渡す必要はありません。
PycharmのコンソールとJupyterのノートブックは非常に計装されているため、頭上がはるかに大きいため、結果は予想されるほど流動的ではない可能性があります。それに加えて、JupyterノートブックはANSIエスケープコードをサポートしていないため、「Clear the Line」や「Clear from Cursor」などの機能をエミュレートするためにいくつかの
alive_bar策を開発する必要がありました... 、常に本格的な端末を好みます。
alive-progressは依存関係がありませんでした。現在、2つがあります。1つは、スピナーコンピレーションにかかる時間を追跡し、人間に優しい演出を生み出すために使用されるために使用される、1つは頃です（私のもう1つの興味深いプロジェクトです）。もう1つは、グラフェメムクラスターブレークを検出するためのグラフェメムです（そこで将来と正確性について尋ねる問題を開き、著者は彼がすべての新しいUnicodeバージョンでプロジェクトを更新することを保証します）。alive-progressには1つのPythonクラスがありませんでした！現在、非常に具体的な理由でいくつかの小さなものがあります（Callables、Iterator Adapters、およびalive_barウィジェットのいくつかの記述子）。alive_bar自体でさえ単なる機能です！ただし、公平を期すためには、「ただの」機能であり、内部からいくつかの閉鎖を動的にプラグインします（Python関数には、クラスと同じように__dict__があることを忘れないでください）。 alive_bar端子サイズの変更に気付いていますが、それに応じてラインを切り捨てます）。contribシステムを作成します。skippedアイテムで計算サポートを再開しますstdoutの代わりにstderrおよびその他のファイルを使用するためのサポートmonitor 、 elapsed 、 statsなどのウィジェットレンディションをカスタマイズします
ここで完了します。
alive_it呼び出しのより良いエラー処理、Alive_Progressのネストされた使用を検出し、より明確なエラーメッセージをスローするalive_itで注釈を入力するskippedアイテム、jupyter用の新しいmax_cols構成設定、stderrを使用する際の端末のサイズの取得を修正する新しい再開計算サポート、python 3.11を正式にサポートするsys.stderrおよびその他のファイルを使用するためのスケーリング、 sys.stdoutのサポート、レートの推定をスムーズにし、現在実行中のウィジェットへのクエリをスムーズにしました。データ、構成エラーのシステムをヘルプしますmonitor 、 elapsed 、およびstatsコアalive_bar 、new monitor_end 、 elapsed_end 、およびstats_endコアウィジェット、Ctrl+Cのより良いサポート。click.echo()サポート;より速いパフォーマンス。ターミナルカラムのより安全な検出。 bar.currentプロパティのように機能します。 Python 3.6を削除します.check()スピナーとバーの両方のツール。バーとスピナーのエンジンの刷新。並んで、シーケンシャルスピナーの新しいアニメーションモード。新しいビルトインスピナー、バー、テーマ。テーマ、スクロール保護、フィルターパターンを備えたダイナミックショータイム。ファイルのロギングの改善。外観をカスタマイズするためのいくつかの新しい構成オプション。新しいイテレーターアダプターalive_it ; time.perf_counter()高解像度クロックを使用します。 Python 3.6+が必要です（およびPython 3.9および3.10を正式にサポートしています）bar.current()メソッド。 NewlinesはVanilla Python Replに印刷されます。バーは、Windowsで80枚のcharに切り捨てられますbar.text()メソッド、いつでも状況メッセージを設定し、ポジションを増やすことなく（ bar()のテキストパラメーターを非難する）。パフォーマンスの最適化blankの代わりにbackgroundパラメーターを受け入れます。show_spinners show_bars show_bars print_chars濃縮は、（ローカルおよびグローバルに）無効になるようになりました。alive_progress常にPythonに追いつくことを試みますので、バージョン2.0から始めて、EOLに入るすべてのPythonバージョンのサポートをドロップします。こちらのスケジュールをご覧ください。
しかし、まだ移行できない場合でも心配しないでください： alive_progressバージョンは多年生ですので、あなたのために働くものを使い続けてください。
以下の形式を備えたrecumation.txtファイルに古いalive_progressパッケージを強く設定することを強くお勧めします。これらは、特定のバージョンの前に常に最新のビルドリリースを取得するため、バグ修正をリリースした場合は、それらも取得できます。
❯ pip install -U " alive_progress<2 "❯ pip install -U " alive_progress<2.2 "❯ pip install -U " alive_progress<3.2 " このソフトウェアは、MITライセンスの下でライセンスされています。完全なライセンス テキストについては、最上位の配布ディレクトリにある LICENSE ファイルを参照してください。
オープンソースプロジェクトを維持することは困難で時間がかかります。私はこれに多くのことと努力を注いでいます。
あなたが私の仕事に感謝しているなら、あなたは寄付で私をバックアップすることができます！ありがとう ？
