🏷️ 📅 👊🏽 पायथन के लिए लोकप्रिय सीएलआई पुस्तकालयों की तुलना: क्लिक, सीमेंट, फायर और अन्य 🤟🏼 👦🏾 🦂

कंसोल अनुप्रयोगों के लिए पायथन एक महान भाषा है, और यह इन कार्यों के लिए बड़ी संख्या में पुस्तकालयों को उजागर करता है। लेकिन क्या पुस्तकालयों मौजूद हैं? और कौन सा लेना बेहतर है? यह सामग्री कंसोल की दुनिया के लिए लोकप्रिय और बहुत उपकरण की तुलना नहीं करती है और दूसरे प्रश्न का उत्तर देने का प्रयास करती है।

पढ़ने में आसानी के लिए, समीक्षा को दो पदों में विभाजित किया गया है: पहला छह सबसे लोकप्रिय पुस्तकालयों की तुलना करता है, दूसरा - कम लोकप्रिय और अधिक विशिष्ट, लेकिन अभी भी ध्यान देने योग्य है।

प्रत्येक उदाहरण में, टॉडोलिब लाइब्रेरी के लिए एक कंसोल उपयोगिता पायथन 3.7 में लिखी जाएगी, जिसके साथ आप कार्यों को बना सकते हैं, देख सकते हैं, टैग कर सकते हैं और हटा सकते हैं। बाकी को एक विशेष ढांचे पर कार्यान्वयन की सादगी के अधीन जोड़ा जाएगा। कार्यों को स्वयं एक json फ़ाइल में संग्रहीत किया जाता है, जिसे एक अलग कॉल में सहेजा जाएगा - उदाहरणों के लिए एक अतिरिक्त स्थिति।
इसके अतिरिक्त, प्रत्येक कार्यान्वयन के लिए एक तुच्छ परीक्षण लिखा जाएगा। निम्नलिखित फिक्स्चर के साथ पाइस्ट को परीक्षण ढांचे के रूप में लिया गया था:

@pytest.fixture(autouse=True) def db(monkeypatch): """ monkeypatch     ,        """ value = {"tasks": []} monkeypatch.setattr(todolib.TodoApp, "get_db", lambda _: value) return value @pytest.yield_fixture(autouse=True) def check(db): """      """ yield assert db["tasks"] and db["tasks"][0]["title"] == "test" # ,      EXPECTED = "Task 'test' created with number 1.\n"

सिद्धांत रूप में, उपरोक्त सभी पुस्तकालयों को प्रदर्शित करने के लिए पर्याप्त होगा। इस रिपॉजिटरी में फुल सोर्स कोड उपलब्ध है।

argparse

अर्गपर्स के पास एक निर्विवाद लाभ है - यह मानक पुस्तकालय में है और इसके एपीआई को सीखना मुश्किल नहीं है: एक पार्सर है, तर्क हैं, तर्क में प्रकार , कार्रवाई , भाग्य , डिफ़ॉल्ट और मदद है । और सबपर है - तर्क और तर्क के अलग-अलग हिस्से को अलग-अलग कमांड में रखने की क्षमता।

पार्सर

पहली नज़र में - कुछ भी असामान्य नहीं है, पार्सर एक पार्सर की तरह है। लेकिन - मेरी राय में - अन्य पुस्तकालयों के साथ तुलना करने पर पठनीयता सबसे अच्छी नहीं है, क्योंकि विभिन्न आदेशों के तर्क एक ही स्थान पर वर्णित हैं।

स्रोत कोड

 def get_parser(): parser = argparse.ArgumentParser("Todo notes - argparse version") parser.add_argument( "--verbose", "-v", action="store_true", help="Enable verbose mode" ) parser.add_argument("--version", "-V", action="store_true", help="Show version") subparsers = parser.add_subparsers(title="Commands", dest="cmd") add = subparsers.add_parser("add", help="Add new task") add.add_argument("title", help="Todo title") show = subparsers.add_parser("show", help="Show tasks") show.add_argument( "--show-done", action="store_true", help="Include done tasks in the output" ) done = subparsers.add_parser("done", help="Mark task as done") done.add_argument("number", type=int, help="Task number") remove = subparsers.add_parser("remove", help="Remove task") remove.add_argument("number", type=int, help="Task number") return parser

मुख्य

और यहाँ एक ही बात है - पार्स करने वाले तर्कों को छोड़कर और अधिक कुछ नहीं कर सकते, इसलिए तर्क को स्वतंत्र रूप से और एक स्थान पर लिखना होगा। एक तरफ - यह जीवित रहना संभव है, दूसरे पर - यह बेहतर संभव है, लेकिन यह अभी तक स्पष्ट नहीं है कि कैसे।

UPD: जैसा कि नोट किया गया है, वास्तव में, subparsers set_defaults (func = foo) के माध्यम से फ़ंक्शंस सेट कर सकते हैं, अर्थात, argparse आपको छोटे आकारों में मुख्य को छोटा करने की अनुमति देता है। जियो और सीखो।

स्रोत कोड

 def main(raw_args=None): """ Argparse example entrypoint """ parser = get_parser() args = parser.parse_args(raw_args) logging.basicConfig() if args.verbose: logging.getLogger("todolib").setLevel(logging.INFO) if args.version: print(lib_version) exit(0) cmd = args.cmd if not cmd: parser.print_help() exit(1) with TodoApp.fromenv() as app: if cmd == "add": task = app.add_task(args.title) print(task, "created with number", task.number, end=".\n") elif cmd == "show": app.print_tasks(args.show_done) elif cmd == "done": task = app.task_done(args.number) print(task, "marked as done.") elif cmd == "remove": task = app.remove_task(args.number) print(task, "removed from list.")

परीक्षण

उपयोगिता के आउटपुट की जांच करने के लिए, कैप्सिस स्थिरता का उपयोग किया जाता है , जो स्टडआउट और स्टेडर से पाठ तक पहुंच प्रदान करता है।

 def test_argparse(capsys): todo_argparse.main(["add", "test"]) out, _ = capsys.readouterr() assert out == EXPECTED

परिणाम

फायदे की - पार्सिंग के लिए सुविधाओं का एक अच्छा सेट, मानक पुस्तकालय में एक मॉड्यूल की उपस्थिति।

विपक्ष - तर्क केवल पार्स करने वाले तर्कों में शामिल है, मुख्य तर्क में से अधिकांश को स्वयं द्वारा लिखा जाना था। और यह स्पष्ट नहीं है कि परीक्षणों में निकास कोड का परीक्षण कैसे किया जाए।

docopt

docopt एक छोटी (<600 लाइनें, argparse के साथ 2500 की तुलना में) पार्सर है, जो आपको GitHub पर एक विवरण उद्धृत करते हुए, मुस्कान देगा। डॉकॉप्ट का मुख्य विचार इंटरफ़ेस का शाब्दिक रूप से पाठ के साथ वर्णन करना है, उदाहरण के लिए, डॉकस्ट्रिंग में।

इसी गितुब पर, डॉकटॉप> 6700 स्टार, इसका उपयोग कम से कम 22 हजार अन्य परियोजनाओं में किया जाता है। और यह केवल अजगर के कार्यान्वयन के साथ है! डॉकॉप्ट प्रोजेक्ट पेज में विभिन्न भाषाओं के लिए C और PHP से लेकर कॉफ़ीस्क्रिप्ट और यहां तक कि R. के लिए कई विकल्प हैं। इस तरह के क्रॉस-प्लेटफ़ॉर्म को केवल कोड की कॉम्पैक्टनेस और सरलता द्वारा समझाया जा सकता है।

पार्सर

झगड़े की तुलना में, यह पार्सर एक बड़ा कदम है।

 """Todo notes on docopt. Usage: todo_docopt [-v | -vv ] add <task> todo_docopt [-v | -vv ] show --show-done todo_docopt [-v | -vv ] done <number> todo_docopt [-v | -vv ] remove <number> todo_docopt -h | --help todo_docopt --version Options: -h --help Show help. -v --verbose Enable verbose mode. """

मुख्य

सामान्य तौर पर, सब कुछ argparse के साथ ही होता है, लेकिन अब वर्बोज़ में कई मान (0-2) हो सकते हैं, और तर्कों तक पहुंच अलग-अलग है: docopt रिटर्न विशेषताओं के साथ एक नाम स्थान नहीं है, लेकिन सिर्फ एक शब्दकोश है, जहां एक कमांड का विकल्प इंगित किया गया है उसके बूलियन के माध्यम से, जैसा कि देखा गया है :

स्रोत कोड

 def main(argv=None): args = docopt(__doc__, argv=argv, version=lib_version) log.setLevel(levels[args["--verbose"]]) logging.basicConfig() log.debug("Arguments: %s", args) with TodoApp.fromenv() as app: if args["add"]: task = app.add_task(args["<task>"]) print(task, "created with number", task.number, end=".\n") elif args["show"]: app.print_tasks(args["--show-done"]) elif args["done"]: task = app.task_done(args["<number>"]) print(task, "marked as done.") elif args["remove"]: task = app.remove_task(args["<number>"]) print(task, "removed from list.")

परीक्षण

आर्गन परीक्षण के समान:

 def test_docopt(capsys): todo_docopt.main(["add", "test"]) out, _ = capsys.readouterr() assert out == EXPECTED

परिणाम

लाभों में से - पार्सर के लिए बहुत कम कोड, आदेशों और तर्कों के विवरण और पढ़ने में आसानी, अंतर्निहित संस्करण।

विपक्ष, सबसे पहले, समान रूप से समान - मुख्य में बहुत सारे तर्क, आप बाहर निकलने के कोड का परीक्षण नहीं कर सकते। इसके अलावा, डॉकटॉप का वर्तमान संस्करण (0.6.2) अभी तक स्थिर नहीं है और हमेशा के लिए होने की संभावना नहीं है - परियोजना 2012 से 2013 के अंत तक सक्रिय रूप से विकसित हो रही थी, आखिरी प्रतिबद्ध दिसंबर 17 में था। और इस समय सबसे अप्रिय बात यह है कि कुछ डॉकटॉप नियमित परीक्षण करते समय DeprecationWarning को उत्तेजित करते हैं।

क्लिक करें

क्लिक, सुविधाओं की संख्या और सज्जाकारों के माध्यम से आदेशों और मापदंडों का वर्णन करने के दृष्टिकोण से संख्या के आधार पर मूल रूप से अलग है, और तर्क को एक बड़े मुख्य के बजाय अलग-अलग कार्यों में विभाजित करने का प्रस्ताव है। लेखकों का दावा है कि क्लिक में बहुत सारी सेटिंग्स हैं, लेकिन मानक पैरामीटर पर्याप्त होना चाहिए। सुविधाओं के बीच, नेस्टेड कमांड और उनके आलसी लोडिंग पर जोर दिया जाता है।

यह परियोजना अत्यंत लोकप्रिय है:> 8100 सितारे होने और कम से कम 174 हजार (!) परियोजनाओं में इसका उपयोग करने के अलावा, यह अभी भी विकसित हो रहा है: संस्करण 7.0 शरद ऋतु 2018 में जारी किया गया था, और इस दिन के लिए नए कमिट और मर्ज अनुरोध दिखाई देते हैं दिन।

पार्सर

दस्तावेज़ीकरण पृष्ठ पर, मुझे पुष्टिकरण_ दायक डेकोरेटर मिला, जो कमांड निष्पादित करने से पहले उपयोगकर्ता से पुष्टि के लिए कहता है। इसे प्रदर्शित करने के लिए, वाइप कमांड जोड़ा गया, जो कार्यों की पूरी सूची को साफ करता है।

स्रोत कोड

 levels = [logging.WARN, logging.INFO, logging.DEBUG] pass_app = click.make_pass_decorator(TodoApp) @click.group() @click.version_option(lib_version, prog_name="todo_click") @click.option("-v", "--verbose", count=True) # click   ,     @click.option("--db", help="Path to the database file") @click.pass_context def cli(ctx, verbose, db): """Todo notes - click version.""" level = levels[min(verbose, 2)] logging.basicConfig(level=level) logging.getLogger("todolib").setLevel(level) ctx.obj = TodoApp.fromenv(db) atexit.register(ctx.obj.save) @cli.command() @click.argument("task") @pass_app def add(app, task): """ Add new task. """ task = app.add_task(task) click.echo(f"{task} created with number {task.number}.") @cli.command() @click.option("--show-done", is_flag=True, help="Include done tasks") @pass_app def show(app, show_done): """ Show current tasks. """ app.print_tasks(show_done) @cli.command() @click.argument("number", type=int) @pass_app def done(app, number): """ Mark task as done. """ task = app.task_done(number) click.echo(f"{task} marked as done.") @cli.command() @click.argument("number", type=int) @pass_app def remove(app, number): """ Remove task from the list. """ task = app.remove_task(number) click.echo(f"{task} removed from the list.") @cli.command() @click.confirmation_option(prompt="Are you sure you want to remove database") @pass_app def wipe(app): for task in app.list_tasks(): task.remove()

मुख्य

और यहां हम क्लिक के मुख्य लाभ के साथ मिलते हैं - इस तथ्य के कारण कि कमांड के तर्क को उनके कार्यों के अनुसार बाहर रखा गया है, लगभग कुछ भी मुख्य नहीं रहता है। यह भी प्रदर्शित किया जाता है कि पर्यावरण चर से तर्क और मापदंडों को प्राप्त करने के लिए पुस्तकालय की क्षमता है।

 if __name__ == "__main__": cli(auto_envvar_prefix="TODO")

परीक्षण

क्लिक के मामले में, sys.stdout को इंटरसेप्ट करने की कोई आवश्यकता नहीं है, क्योंकि इस तरह की चीजों के लिए रनर के साथ क्लिकिंग मॉड्यूल है। और न केवल CliRunner ही आउटपुट को इंटरसेप्ट करता है, बल्कि यह आपको एक्ज़िट कोड की जाँच करने की भी अनुमति देता है, जो ठंडा भी है। यह सब pytest का उपयोग किए बिना क्लिक-यूटिलिटीज का परीक्षण करने और मानक unittest मॉड्यूल को बायपास करने की अनुमति देता है।

 import click.testing def test_click(): runner = click.testing.CliRunner() result = runner.invoke(todo_click.cli, ["add", "test"]) assert result.exit_code == 0 assert result.output == EXPECTED

परिणाम

यह केवल एक छोटा सा हिस्सा है जो क्लिक कर सकता है। एपीआई के बाकी हिस्सों से - मूल्यों का सत्यापन, टर्मिनल के साथ एकीकरण (रंग, पेजर ए ला कम, प्रगति बार, आदि), परिणाम कॉलबैक, ऑटो-पूरा और बहुत कुछ। आप उनके उदाहरण यहां देख सकते हैं।

पेशेवरों: किसी भी अवसर के लिए बहुत सारे उपकरण, एक मूल, लेकिन एक ही समय में टीमों का वर्णन करने के लिए सुविधाजनक दृष्टिकोण, परीक्षण में आसानी और सक्रिय परियोजना जीवन।

विपक्ष: "क्लिक" के नुकसान क्या हैं - यह एक मुश्किल सवाल है। हो सकता है कि वह कुछ नहीं जानता हो कि निम्नलिखित पुस्तकालय क्या करने में सक्षम हैं?

आग

आग Google से कंसोल इंटरफेस के लिए सिर्फ एक युवा (2017 में दिखाई गई) लाइब्रेरी नहीं है, यह शाब्दिक रूप से कंसोल इंटरफेस उत्पन्न करने के लिए एक पुस्तकालय है, जिसका शाब्दिक रूप से कोई भी पायथन ऑब्जेक्ट है ।
अन्य बातों के अलावा, यह कहा गया है कि आग कोड के विकास और डिबगिंग में मदद करती है, सीएलआई में मौजूदा कोड को अनुकूलित करने में मदद करती है, बैश से पायथन में संक्रमण की सुविधा प्रदान करती है, और इंटरैक्टिव काम के लिए इसका अपना REPL है। क्या हम देखेंगे?

पार्सर और मुख्य

फायर.फेयर वास्तव में किसी भी वस्तु को स्वीकार करने में सक्षम है: एक मॉड्यूल, एक श्रेणी उदाहरण, कमांड नाम और संबंधित कार्यों के साथ एक शब्दकोश, और इसी तरह।

हमारे लिए जो महत्वपूर्ण है वह यह है कि फायर एक वर्ग वस्तु के हस्तांतरण की अनुमति देता है। इस प्रकार, क्लास कंस्ट्रक्टर सभी आदेशों के लिए तर्क को स्वीकार करता है, और इसके तरीके और गुण अलग-अलग कमांड होते हैं। हम इसका उपयोग करेंगे:

स्रोत कोड

 class Commands: def __init__(self, db=None, verbose=False): level = logging.INFO if verbose else logging.WARNING logging.basicConfig(level=level) logging.getLogger("todolib").setLevel(level) self._app = todolib.TodoApp.fromenv(db) atexit.register(self._app.save) def version(self): return todolib.__version__ def add(self, task): """Add new task.""" task = self._app.add_task(task) print(task, "created with number", task.number, end=".\n") def show(self, show_done=False): """ Show current tasks. """ self._app.print_tasks(show_done) def done(self, number): """ Mark task as done. """ task = self._app.task_done(number) print(task, "marked as done.") def remove(self, number): """ Removes task from the list. """ task = self._app.remove_task(number) print(task, "removed from the list.") def main(args=None): fire.Fire(Commands, command=args)

इनलाइन झंडे

विशेष सिंटैक्स के साथ आग के अपने झंडे होते हैं (उन्हें "-" के बाद पारित किया जाना चाहिए), जो आपको पार्सर के हुड के नीचे देखने की अनुमति देता है और एक पूरे के रूप में आवेदन:

कॉल उदाहरण

 $ ./todo_fire.py show -- --trace Fire trace: 1. Initial component 2. Instantiated class "Commands" (todo_fire.py:9) 3. Accessed property "show" (todo_fire.py:25) $ ./todo_fire.py -- --verbose | head -n 12 #    , ,  Commands._app NAME todo_fire.py - SYNOPSIS todo_fire.py - GROUP | COMMAND GROUPS GROUP is one of the following: _app Todo Application definition. $ ./todo_fire.py show -- --interactive Fire is starting a Python REPL with the following objects: Modules: atexit, fire, logging, todolib Objects: Commands, args, component, main, result, self, todo_fire.py, trace Python 3.7.4 (default, Aug 15 2019, 13:09:37) [GCC 7.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> self <__main__.Commands object at 0x7fd0a6125bd0> >>> self._app.db {'tasks': [{'title': 'test', 'done': False}]}

परीक्षण

मुख्य फ़ंक्शन का परीक्षण करना argparse और docopt के परीक्षण के समान है, इसलिए मैं यहां बिंदु नहीं देखता।

इसी समय, यह ध्यान देने योग्य है कि, आग की आत्मनिरीक्षण प्रकृति के कारण, आप कमांडर वर्ग को दूर से भी देख सकते हैं।

परिणाम

आग एक उपकरण है जो क्लिक से कम रोचक नहीं है। यह पार्सर में कई विकल्पों को सूचीबद्ध करने की आवश्यकता नहीं है, कॉन्फ़िगरेशन न्यूनतम है, डिबगिंग के लिए विकल्प हैं, और लाइब्रेरी खुद ही रहती है और क्लिक की तुलना में और भी अधिक सक्रिय रूप से विकसित होती है (60 इस गर्मी को पूरा करती है)।

विपक्ष: क्लिक और अन्य पार्सर की तुलना में काफी कम हो सकता है; अस्थिर एपीआई (वर्तमान संस्करण 0.2.1 है)।

सीमेंट

वास्तव में, सीमेंट वास्तव में एक सीएलआई पुस्तकालय नहीं है, बल्कि कंसोल अनुप्रयोगों के लिए एक रूपरेखा है, लेकिन यह दावा किया जाता है कि यह स्क्रिप्ट और विभिन्न अनुप्रयोगों के साथ जटिल अनुप्रयोगों के लिए उपयुक्त है।

पार्सर

सीमेंट में पार्सर असामान्य दिखता है, लेकिन यदि आप मापदंडों को करीब से देखते हैं, तो यह अनुमान लगाना आसान है कि परिचित अरगर्स हुड के नीचे है। लेकिन शायद यह सबसे अच्छा के लिए है - नए मापदंडों को सीखने की कोई आवश्यकता नहीं है।

स्रोत कोड

 from cement import Controller, ex class Base(Controller): class Meta: label = "base" arguments = [ ( ["-v", "--version"], {"action": "version", "version": f"todo_cement v{todolib.__version__}"}, ) ] def _default(self): """Default action if no sub-command is passed.""" self.app.args.print_help() @ex(help="Add new task", arguments=[(["task"], {"help": "Task title"})]) def add(self): title = self.app.pargs.task self.app.log.debug(f"Task title: {title!r}") task = self.app.todoobj.add_task(title) print(task, "created with number", task.number, end=".\n") @ex( help="Show current tasks", arguments=[ (["--show-done"], dict(action="store_true", help="Include done tasks")) ], ) def show(self): self.app.todoobj.print_tasks(self.app.pargs.show_done) @ex(help="Mark task as done", arguments=[(["number"], {"type": int})]) def done(self): task = self.app.todoobj.task_done(self.app.pargs.number) print(task, "marked as done.") @ex(help="Remove task from the list", arguments=[(["number"], {"type": int})]) def remove(self): task = self.app.todoobj.remove_task(self.app.pargs.number) print(task, "removed from the list.")

ऐप और मुख्य

सीमेंट, अन्य चीजों के अलावा, अभी भी अपवादों में संकेतों को लपेटता है। यह यहाँ SIGINT / SIGTERM के साथ शून्य-कोड आउटपुट पर प्रदर्शित होता है।

स्रोत कोड

 class TodoApp(App): def __init__(self, argv=None): super().__init__(argv=argv) self.todoobj = None def load_db(self): self.todoobj = todolib.TodoApp.fromenv() def save(self): self.todoobj.save() class Meta: # application label label = "todo_cement" # register handlers handlers = [Base] hooks = [("post_setup", lambda app: app.load_db()), ("pre_close", lambda app: app.save())] # call sys.exit() on close close_on_exit = True def main(): with TodoApp() as app: try: app.run() except CaughtSignal as e: if e.signum not in (signal.SIGINT, signal.SIGTERM): raise app.log.debug(f"\n{e}") app.exit_code = 0

यदि आपको मुख्य की समझ मिलती है, तो आप देख सकते हैं कि लोडिंग और बचत todolib.TodoApp को ओवरराइड __enter __ / __ एक्जिट__ में भी किया जा सकता है, लेकिन सीमेंट हुक को प्रदर्शित करने के लिए इन चरणों को अंततः अलग-अलग तरीकों से अलग किया गया।

परीक्षण

परीक्षण के लिए, आप उसी एप्लिकेशन वर्ग का उपयोग कर सकते हैं:

 def test_cement(capsys): with todo_cement.TodoApp(argv=["add", "test"]) as app: app.run() out, _ = capsys.readouterr() assert out == EXPECTED #     jinja,       assert app.last_rendered is None

परिणाम

पेशेवरों: एपीआई का सेट स्विस चाकू के एक सेट की तरह है, हुक और प्लगइन्स के माध्यम से विस्तार, एक स्थिर इंटरफ़ेस और सक्रिय विकास।

विपक्ष: खाली प्रलेखन स्थानों में; छोटी सीमेंट-आधारित स्क्रिप्ट थोड़ी जटिल लग सकती हैं।

क्लियो

क्लियो इस तरह के एक लोकप्रिय ढांचे के रूप में दूर है क्योंकि यहां सूचीबद्ध अन्य (कुल मिलाकर गीथहब पर लगभग 400 सितारे) हैं, और फिर भी मैं यह जानने में कामयाब रहा कि जब मैंने अध्ययन किया कि पोएट्री कैसे आउटपुट है।

तो, क्लियो पहले से ही वर्णित कविता के लेखक की परियोजनाओं में से एक है, जो निर्भरता, वर्चुअल्स और एप्लिकेशन बिल्ड का प्रबंधन करने के लिए एक उपकरण है। कविता पर कविता के बारे में पहले से ही एक से अधिक बार लिखा है, और इसके कंसोल भाग के बारे में - नहीं।

पार्सर

क्लियो, जैसे सीमेंट, वस्तु सिद्धांतों पर बनाया गया है, अर्थात्। कमांड क्लास और उसके डॉकस्ट्रिंग के माध्यम से कमांड को परिभाषित किया जाता है, मापदंडों को विकल्प () विधि, और इसी तरह एक्सेस किया जाता है। इसके अलावा, लाइन () विधि, जो पाठ को आउटपुट करने के लिए उपयोग की जाती है, बॉक्स से बाहर वर्बोज़ फ़्लैग की संख्या के आधार पर शैलियों (यानी रंग) और आउटपुट फ़िल्टरिंग का समर्थन करती है। क्लियो में टेबल आउटपुट भी है। और सलाखों की प्रगति भी। और फिर भी ... सामान्य तौर पर, देखें:

स्रोत कोड

 from cleo import Command as BaseCommand # cleo    clikit,          from clikit.api.io import flags as verbosity class Command(BaseCommand): def __init__(self): super().__init__() self.todoapp = None def handle(self): with todolib.TodoApp.fromenv() as app: self.todoapp = app self.do_handle() def do_handle(self): raise NotImplementedError class AddCommand(Command): """ Add new task. add {task : Task to add} """ def do_handle(self): title = self.argument("task") task = self.todoapp.add_task(title) # will be printed only on "-vvv" self.line(f"Title: {title}", style="comment", verbosity=verbosity.DEBUG) self.line(f"Task <info>{task.title}</> created with number {task.number}.") class ShowCommand(Command): """ Show current tasks. show {--show-done : Include tasks that are done.} """ def do_handle(self): tasks = self.todoapp.list_tasks(self.option("show-done")) if not tasks: self.line("There is no TODOs.", style="info") self.render_table( ["Number", "Title", "Status"], [ [str(task.number), task.title, "" if task.done else "✘"] for task in tasks ], ) class DoneCommand(Command): """ Mark task as done. done {number : Task number} """ def do_handle(self): task = self.todoapp.task_done(int(self.argument("number"))) self.line(f"Task <info>{task.title}</> marked as done.") class RemoveCommand(Command): """ Removes task from the list. remove {number : Task number} """ def do_handle(self): task = self.todoapp.remove_task(int(self.argument("number"))) self.line(f"Task <info>{task.title}</> removed from the list.")

मुख्य

सभी की जरूरत है कि एक cleo.Application ऑब्जेक्ट बनाने के लिए और फिर इसे करने के लिए add_commands को कमांड पास करें। परीक्षण के दौरान दोहराना नहीं करने के लिए, यह सब मुख्य से कंस्ट्रक्टर में स्थानांतरित किया गया था:

 from cleo import Application as BaseApplication class TodoApp(BaseApplication): def __init__(self): super().__init__(name="ToDo app - cleo version", version=todolib.__version__) self.add_commands(AddCommand(), ShowCommand(), DoneCommand(), RemoveCommand()) def main(args=None): TodoApp().run(args=args)

परीक्षण

क्लियो में कमांड का परीक्षण करने के लिए, कमांडटेस्टर है , जो फ्रेमवर्क के सभी वयस्क ~~चाचाओं की~~ तरह, I / O को स्वीकार करता है और बाहर निकलता है:

 def test_cleo(): app = todo_cleo.TodoApp() command = app.find("add") tester = cleo.CommandTester(command) tester.execute("test") assert tester.status_code == 0 assert tester.io.fetch_output() == "Task test created with number 0.\n"

परिणाम

पेशेवरों: प्रकार के संकेत के साथ वस्तु संरचना, जो विकास को सरल बनाता है (चूंकि कई आईडीई और संपादकों को ओओपी कोड और टाइपिंग मॉड्यूल के लिए अच्छा समर्थन है); न केवल तर्कों के साथ काम करने के लिए कार्यक्षमता की एक अच्छी मात्रा, बल्कि I / O भी।

प्लस या माइनस: इसका वर्बोसिटी पैरामीटर, जो केवल I / O क्लियो / क्लिट के साथ संगत है। यद्यपि आप लॉगिंग मॉड्यूल के लिए एक कस्टम हैंडलर लिख सकते हैं, यह क्लियो के विकास के साथ बनाए रखना मुश्किल हो सकता है।

विपक्ष: स्पष्ट रूप से - एक व्यक्तिगत राय - एक युवा एपीआई: ढांचे में पोएट्री को छोड़कर एक और "बड़े" उपयोगकर्ता का अभाव है, और क्लियो विकास के समानांतर और एक की जरूरतों के लिए विकसित हो रहा है; कभी-कभी दस्तावेज़ीकरण पुराना होता है (उदाहरण के लिए, लॉगिंग स्तर अब क्लिट मॉड्यूल में नहीं है, लेकिन clikit.api.io.flags में है), और सामान्य तौर पर यह खराब है और संपूर्ण API को प्रतिबिंबित नहीं करता है।

सीमेंट की तुलना में क्लियो, सीएलआई पर अधिक केंद्रित है, और वह एकमात्र ऐसा व्यक्ति है जिसने डिफ़ॉल्ट आउटपुट में अपवादों के प्रारूपण (डिफ़ॉल्ट स्टैक ट्रेस को छिपाने) के बारे में सोचा है। लेकिन वह - फिर से एक व्यक्तिगत राय - अपनी युवावस्था और एपीआई स्थिरता में सीमेंट को खो देता है।

निष्कर्ष में

इस बिंदु पर, हर किसी के पास पहले से ही अपनी राय है, जो बेहतर है, लेकिन निष्कर्ष यह होना चाहिए: मुझे सबसे अधिक पसंद है, क्योंकि इसमें बहुत सारी चीजें हैं और इसके साथ एप्लिकेशन विकसित करना और परीक्षण करना काफी आसान है। यदि आप कोड को न्यूनतम लिखने की कोशिश करते हैं - आग से शुरू करें। आपकी स्क्रिप्ट को मेम्नेच्ड तक पहुंचने की आवश्यकता है, जिन्जा और एक्स्टेंसिबिलिटी के साथ प्रारूपण - सीमेंट ले लो और आपको इसका अफसोस नहीं होगा। आपके पास एक पालतू परियोजना है या कुछ और कोशिश करना चाहते हैं - क्लियो को देखें।

पायथन के लिए लोकप्रिय सीएलआई पुस्तकालयों की तुलना: क्लिक, सीमेंट, फायर और अन्य

argparse

पार्सर

मुख्य

परीक्षण

परिणाम

docopt

पार्सर

मुख्य

परीक्षण

परिणाम

क्लिक करें

पार्सर

मुख्य

परीक्षण

परिणाम

आग

पार्सर और मुख्य

इनलाइन झंडे

परीक्षण

परिणाम

सीमेंट

पार्सर

ऐप और मुख्य

परीक्षण

परिणाम

क्लियो

पार्सर

मुख्य

परीक्षण

परिणाम

निष्कर्ष में

More articles: