थंडरगैस: उपयोग का अभ्यास। भाग २

सृष्टि का इतिहास
भाग 1

शुभ दोपहर मैं संक्षेप में याद करूंगा कि थंडरगार्स एक पुस्तकालय है जो आपको आने वाले तर्कों को संसाधित करने के लिए एनोटेशन का उपयोग करने की अनुमति देता है।

इसके अलावा, यह केवल एक गेट फेंकना संभव बनाता है, जो कहीं और से फ़ंक्शन के लिए इन तर्कों को खींच लेगा। उदाहरण के लिए, फ्लास्क में अनुरोध ऑब्जेक्ट से। और अंत में, हम इसके बजाय

@app.route('/ugly_calc', dont_wrap=True) def ugly_calc(): x, y = int(request.args['x']), int(request.args['y']) op_key = request.args.get('op') if not op_key: op_key = '+' op = OPERATION.get(op_key) return str(op(x, y)) 

करना

 @app.route('/calc') def calc(x:Arg(int), y:Arg(int), op:Arg(str, default='+')): return str(OPERATION[op](x, y)) 

मुझे लगता है कि हर कोई कम से कम मोटे तौर पर समझ गया कि लेख किस बारे में होगा। इसमें वर्णित सभी परियोजना के भविष्य पर एक प्रतिबिंब है और उस पर "मील के पत्थर" की अनुमानित व्यवस्था है। खैर, निश्चित रूप से, विभिन्न विशेषताओं के सभी प्रकार के पहले ड्राफ्ट।

इस भाग में

• परियोजना में संरचनात्मक परिवर्तनों और मूल संरचना में कुछ महत्वपूर्ण त्रुटियों पर विचार करें
• आइए देखें कि सत्यापनकर्ता कैसे काम करते हैं और उन त्रुटियों को कैसे अनुकूलित करते हैं जो वे उत्पन्न करते हैं।
• विशेष तर्क (रूढ़ि, StrArg, ListArg, और इसी तरह) की अशिष्टता बनाएँ
• अनुरोध में प्राप्त आईडी से एक कक्षा तैयार करें जो डेटाबेस से किसी ऑब्जेक्ट को स्वचालित रूप से खींच लेगा
• हम मॉडल वर्ग द्वारा प्रवेश बिंदु उत्पन्न करेंगे
• हम श्रोताओं को लागू करेंगे और देखेंगे कि कैसे आप कई तर्कों के लिए एक वैध बना सकते हैं
• हम यह सुनिश्चित करेंगे कि तर्कों की संरचना के बारे में जानकारी सुरक्षित रूप से डेटाबेस में स्थानांतरित की जा सकती है, और हमारे लिए कुछ भी नहीं होगा
• और अंत में, हम उन छोटे हितों की चर्चा करेंगे जो इन प्रयोगों के ढांचे में कभी महसूस नहीं किए गए थे।

संरचनात्मक परिवर्तन, या मुझे क्यों लात मारनी चाहिए

खैर, अब संक्षेप में परियोजना के भाग्य में महत्वपूर्ण घटनाओं के बारे में। सबसे पहले, मैंने अंत में पढ़ा कि कैसे आर्मिन रोनाशर ने फ्लास्क को मॉड्यूल बनाने की सिफारिश की , और मेरे "पालतू" को सही तरह से लाया। ऐसा करने के लिए, मैंने मुख्य पुस्तकालय कार्यक्षमता को पूरी तरह से अलग कर दिया (यह काम और गड़गड़ाहट का नाम थंडरार्ग्स के नाम से बना रहा) कार्यात्मक से है जो आपको फ्लास्क के अतिरिक्त इसका उपयोग करने की अनुमति देता है (अब यह बकवास नाम फ्लास्क-थ्रेड्सग के तहत रखा जा सकता है, जैसा कि आप अनुमान लगा सकते हैं)। हां, संक्षेप में यह कर्नेल से इंटरफ़ेस का एक पृथक्करण है, जो इस इंटरफ़ेस के बिना व्यवहार्य है। और इसलिए इसे शुरू से ही किया जाना चाहिए था। मेरे दृष्टिकोण के लिए, मैंने पुनर्गठन पर खर्च किए गए लगभग पांच घंटे का भुगतान किया।
सामान्य तौर पर, मैं संक्षेप में बताऊंगा कि वास्तव में क्या बदल गया है और इसका क्या अर्थ है:

अब हमारे दो काम हैं - कर्नेल और फ्लास्क के इंटरफ़ेस

मुख्य पुस्तकालय, जैसा कि मैंने पहले ही कहा है, किसी भी बाहरी इंटरफेस के बिना अच्छी तरह से उपयोग किया जा सकता है। और, ज़ाहिर है, इसका उपयोग आपके स्वयं के इंटरफेस बनाने के लिए किया जा सकता है। उदाहरण के लिए, अन्य वेब फ्रेमवर्क के लिए। या अर्गपर्स के लिए। या जैबर बॉट को। हाँ, सामान्य तौर पर, कुछ भी करने के लिए।
वास्तव में, इस बिंदु से परियोजना केवल काले रंग में है।

फ्लास्क-थंडरार्ग्स अब एक पूर्ण फ्लास्क मॉड्यूल है

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

 from flask import Flask from flask.ext.thunderargs import ThunderargsProxy from thunderargs import Arg app = Flask(__name__) ThunderargsProxy(app) @app.route('/max') def find_max(x: Arg(int, multiple=True)): return str(max(x)) if __name__ == '__main__': app.run() 

ऐसी बातें।

गलतियाँ करना

पिछले भाग में, हमने पहले ही पता लगा लिया था कि अपने स्वयं के सत्यापनकर्ता कैसे बनाएं। और यह सुनिश्चित किया कि यह काफी सरल है। मुझे आपको याद दिलाना है:

 def less_than_21(x): return x < 21 @app.route('/step5_alt') def step5_1(offset: Arg(int, default=0, validators=[lambda x: x >= 0 and x < len(elements)]), limit: Arg(int, default=20, validators=[less_than_21])): return str(elements[offset:offset+limit]) 

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

अंतिम भाग के प्रयोगों की जांच करने वाला व्यक्ति यह नोटिस कर सकता है कि कारखाने द्वारा बनाए गए सत्यापनकर्ता बहुत सुंदर और समझने योग्य त्रुटियां फेंकते हैं:

 thunderargs.errors.ValidationError: Value of `limit` must be less than 21 

लेकिन हमारा उदाहरण अकल्पनीय और बातूनी त्रुटियाँ पैदा करता है:

 thunderargs.errors.ValidationError: Argument limit failed at validator #0.Given value: 23 

इससे निपटना बहुत सरल है। इसके अलावा, हमारी त्रुटि मूल से भी बेहतर होगी:

 experiments.custom_error.LimitError: limit must be less than 21 and more than 0. Given: 23 

इस परिणाम के लिए, हमें इस कोड की आवश्यकता है:

 class LimitError(ValidationError): pass 

 from thunderargs.errors import customize_error from experiments.custom_error import LimitError message = "{arg_name} must be less than 21 and more than 0. Given: {value}" @customize_error(message=message, error_class=LimitError) def limit_validator(x): return x < 21 and x>0 @app.route('/step5_alt2') def step5_2(offset: Arg(int, default=0, validators=[lambda x: x >= 0 and x < len(elements)]), limit: Arg(int, default=20, validators=[limit_validator])): return str(elements[offset:offset+limit]) 

सामान्य तौर पर, त्रुटि को अनुकूलित करने के लिए, आपको बस सत्यापनकर्ता फ़ंक्शन पर custom_error डेकोरेटर को लटका देना होगा। निम्न चर हमेशा त्रुटि पाठ में दिए जाते हैं:

• error_code - त्रुटि संख्या प्रदर्शित करने के लिए; सिस्टमैटाइजेशन के प्रशंसकों के लिए इंट्रासिस्टम बकवास;
• arg_name उस तर्क का नाम है जो फ़ंक्शन घोषणा के तर्क को सौंपे गए नाम से मेल खाता है; हमारे मामले में, यह है, उदाहरण के लिए, सीमा;
• value - सत्यापनकर्ता द्वारा प्राप्त मूल्य; फ्लास्क-थंडरगार्स के मामले में, यह सबसे अधिक बार स्ट्रिंग है, क्योंकि हर कोई reques.json को छोड़कर और reques.files उसे देता है;
• validator_no - validator_no क्रम संख्या; मुझे बहुत संदेह है कि यह उचित रूप से रचित मान्यताओं में काम आएगा;

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

 def val_in(x): @customize_error("Value of `{arg_name}` must be in {possible_values}", possible_values=x) def validator(value): return value in x return validator 

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

निहित वैरिएबल कक्षाएं

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

 class IntArg(Arg): def __init__(self, max_val=None, min_val=None, **kwargs): kwargs['p_type'] = int if not 'validators' in kwargs or kwargs['validators'] is None: kwargs['validators'] = [] if min_val is not None: if not isinstance(min_val, int): raise TypeError("Minimal value must be int") kwargs['validators'].append(val_gt(min_val-1)) if max_val is not None: if not isinstance(max_val, int): raise TypeError("Maximal value must be int") kwargs['validators'].append(val_lt(max_val+1)) if min_val is not None and max_val is not None: if max_val < min_val: raise ValueError("max_val is greater than min_val") super().__init__(**kwargs) 

और यहाँ इस वर्ग का अनुप्रयोग है:

 from experiments.inherited_args import IntArg @app.route('/step7') def step7(x: IntArg(default=0, max_val=100, min_val=0)): return str(x) 

ऐसी कक्षाओं की मुख्य विशेषता यह है कि आने वाले तर्क के कुछ मापदंडों को मैन्युअल रूप से वर्णित करने की आवश्यकता नहीं है। इसके अलावा, कुछ सत्यापनकर्ताओं को मैन्युअल रूप से वर्णन करने की आवश्यकता नहीं है। और कोड में उनके अर्थ को निर्दिष्ट करना संभव हो जाता है, जो पठनीयता के लिए बहुत महत्वपूर्ण है।
अनुमानित संस्करण: 0.4

ORM के लिए निहित कक्षाएं

मान लें कि हमारे पास एक दस्तावेज वर्ग है जो मोंगोएंगाइन के माध्यम से बनाया गया है:

 class Note(Document): title = StringField(max_length=40) text = StringField(min_length=3, required=True) created = DateTimeField(default=datetime.now) 

हमारे पास एक गेटर होना चाहिए जो एक विशिष्ट दस्तावेज़ लौटाए। आइए इस कार्य के लिए एक स्वतंत्र वर्ग बनाएं:

 class ItemArg(Arg): def __init__(self, collection, **kwargs): kwargs['p_type'] = kwargs.get('p_type') or ObjectId kwargs['expander'] = lambda x: collection.objects.get(pk=x) super().__init__(**kwargs) 

वह सब करता है इनपुट तर्कों को बदल रहा है। बस उन्हें आवश्यक सेट तक विस्तारित करें। और यहां तक ​​कि इस तरह के एक न्यूनतम विकल्प हमें ऐसा करने की अनुमति देता है:

 @app.route('/step9/get') def step9_2(note: ItemArg(Note)): return str(note.text) 

बहुत सुंदर, सही?

अनुमानित संस्करण: यह एक स्वतंत्र पुस्तकालय में रखने के लिए समझ में आता है

फ्लास्क गेटर्स जेनरेट करें

कल्पना करें कि हमारे पास मॉडल में कुछ वर्ग हैं जिनके गेटर्स कोई विशेष क्रिया नहीं करते हैं। आपको एक गेटर लिखने की ज़रूरत है जो उपयोगकर्ता को उसी रूप में जानकारी देगा जैसे वह डेटाबेस में संग्रहीत होता है। इस मामले में, गेट्टर जनरेटर हमें परेशान नहीं करता है। चलो इसे करते हैं:

 def make_default_serializable_getlist(cls, name="default_getter_name"): @Endpoint def get(offset: IntArg(min_val=0, default=0), limit: IntArg(min_val=1, max_val=50, default=20)): return list(map(lambda x: x.get_serializable_dict(), cls.objects.skip(offset).limit(limit))) get.__name__ = name return get 

इस फ़ंक्शन को MongoEngine संग्रह के लिए एक गेट्टर बनाना चाहिए। एकमात्र अतिरिक्त शर्त यह है कि get_serializable_dict पद्धति को संग्रह वर्ग पर परिभाषित किया जाना चाहिए। लेकिन मुझे लगता है कि इससे किसी को कोई विशेष परेशानी नहीं होगी। और यहाँ इस चीज़ के लिए उपयोग में से एक है:

 getter = make_default_serializable_getlist(Note, name='step11_getter') app.route('/step11_alt3')(json_resp(getter)) 

json_resp हेल्पर फ़ंक्शन का उपयोग json_resp किया जाता json_resp , लेकिन वास्तव में यह दिलचस्प कुछ भी नहीं करता है, यह बस flask.jsonify में नियंत्रक प्रतिक्रिया को लपेटता है। flask.jsonify (यदि यह हो सकता है)। इसके अलावा, इस उदाहरण में, मैंने क्लासिक सिंटैक्स का उपयोग किए बिना एक डेकोरेटर का उपयोग किया। मेरी राय में, यह उचित है, अन्यथा एक रैपर-परिवहन करना आवश्यक होता जो किसी भी उपयोगी गतिविधि को निष्पादित नहीं करता था।

अनुमानित संस्करण: पिछले के समान

कॉल लॉगिंग और अधिक

आइए उपयोगकर्ता के प्रत्येक बॉडी मूवमेंट को लॉग करें जो हमारे द्वारा वर्णित नियमों में फिट बैठता है। ऐसा करने के लिए, हम एक साधारण डेकोरेटर फेंकते हैं, जो कॉलबैक फ़ंक्शन में ले जाएगा:

 def listen_with(listener): def decorator(victim): @wraps(victim) def wrapper(**kwargs): listener(func=victim, **kwargs) return victim(**kwargs) return wrapper return decorator 

और कॉलबैक खुद:

 def logger(func, **kwargs): print(func.__name__) print(kwargs) 

यह कॉलबैक स्क्रीन पर प्राप्त सभी तर्कों को प्रदर्शित करता है। अब एक और उपयोगी उदाहरण पर विचार करें:

 def denied_for_john_doe(func, firstname, lastname): if firstname == 'John' and lastname == 'Doe': raise ValueError("Sorry, John, but you are banned") @app.route('/step13') @listen_with(denied_for_john_doe) def step13(firstname: Arg(str, required=True), lastname: Arg(str, required=True)): return "greeting you, {} {}".format(firstname, lastname) 

यहां, जैसा कि हम देखते हैं, मूल्यों के संयोजन का उपयोग करने की संभावना का परीक्षण है। सामान्य तौर पर, विशुद्ध रूप से औपचारिक रूप से, इस तरह की डिजाइन एक फेंडर नहीं है, और उन्हें, श्रोताओं से अलग किया जाना चाहिए। लेकिन अब, प्रयोग के भाग के रूप में, इसे ऐसे ही छोड़ दें। यहाँ एक और अधिक वास्तुशिल्प रूप से सही उदाहरण है:

 def mail_sender(func, email): if func.__name__ == 'step14': #   ,    #  ,      :( pass @app.route('/step14') @listen_with(mail_sender) def step14(email: Arg(str, required=True)): """   ,    ,     :( """ return "ok" 

खैर, एक उदाहरण नहीं, बल्कि इसकी तैयारी।

अनुमानित संस्करण: 0.5

डेटाबेस में तर्कों की संरचना

अब चलो मिठाई के लिए नीचे उतरो। आज, "स्वादिष्ट" में हमारे पास डेटाबेस में आने वाले तर्कों की संरचना का भंडारण है।
तथ्य यह है कि इस तरह की वास्तुकला डेटा प्राप्त करने और प्रसंस्करण के लिए जिम्मेदार कोड को कम करती है, वास्तव में, डेटा को। और हम इस डेटा को कहीं से भी ले सकते हैं। उदाहरण के लिए, एक विन्यास फाइल से। या डेटाबेस से। वास्तव में, यदि आप दो डेटा स्रोतों के बीच अंतर के बारे में सोचते हैं? चलिए शुरू करते हैं।

शुरू करने के लिए, हमें डेटाबेस से आयात किए गए डेटा के साथ वर्तमान में निष्पादित कार्यक्रम की वस्तुओं के पत्राचार की एक तालिका को संकलित करने की आवश्यकता है। उदाहरण में, हम केवल एक प्रकार का उपयोग करेंगे, जो पहले से ही ऊपर वर्णित है। इसलिए, अब तक केवल वह यहां रहेगा:

 TYPES = {'IntArg': IntArg} 

अब हमें एक मॉडल का वर्णन करने की आवश्यकता है, जो वास्तव में, प्रवेश बिंदुओं के आने वाले तर्कों के बारे में जानकारी संग्रहीत और प्रदर्शित करेगा।

 class DBArg(Document): name = StringField(max_length=30, min_length=1, required=True) arg_type = StringField(default="IntArg") params = DictField() def get_arg(self): arg = TYPES[self.arg_type](**self.params) arg.db_entity = self return arg 

यहां, जैसा कि हम देखते हैं, तर्क का नाम, इसके प्रकार और अतिरिक्त पैरामीटर जो इस प्रकार के निर्माणकर्ता को दिए जाएंगे, संकेत दिए गए हैं। हमारे मामले में, यह IntArg है, और हमारे पास जो पैरामीटर हो सकते हैं वे max_val, min_val, आवश्यक, डिफ़ॉल्ट और अन्य सभी हैं जो ORM द्वारा सही तरीके से संसाधित किए जाते हैं।
get_arg फ़ंक्शन get_arg उद्देश्य डेटाबेस में संग्रहीत कॉन्फ़िगरेशन के साथ एक Arg इंस्टेंस प्राप्त करना है। अब हमें संरचनाओं के लिए समान बालिका की आवश्यकता है, जिसे हम आमतौर पर एनोटेशन के माध्यम से व्यक्तिगत तर्कों का वर्णन करते हुए कार्यों में जोड़ते हैं। हां, हां, यह सब एक विशिष्ट निर्माण में विलीन हो जाता है, जिसे बाद में तर्क पार्सर को खिलाया जाता है।

 class DBStruct(Document): args = ListField(ReferenceField(DBArg)) def get_structure(self): return {x.name: x.get_arg() for x in self.args} 

यह बहुत सरल है, और यह शायद ही अलग से वर्णन करने लायक है। शायद यह उन लोगों के लिए स्पष्ट है, जिन्होंने मोंगोईनिन के साथ "बात नहीं" की है कि ListField(ReferenceField(DBArg)) निर्माण का अर्थ है कि इस क्षेत्र में डेटाबेस में हम DBArg वर्ग के तत्वों की एक सूची संग्रहीत करेंगे।

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

 class Category(Document): name = StringField(primary_key=True) label = StringField() parent = ReferenceField('self') arg_structure = ReferenceField(DBStruct) def get_creator(self): @Endpoint @annotate(**self.arg_structure.get_structure()) def creator(**kwargs): return Item(data=kwargs).save() creator.__name__ = "create_" + self.name return creator def get_getter(self): pass 

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

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

 class Item(Document): data = DictField() category = ReferenceField(Category) 

मुझे लगता है कि किसी विशेष स्पष्टीकरण की आवश्यकता नहीं है।

खैर, अब उत्पादों की पहली श्रेणी बनाते हैं:

 >>> weight = DBArg(name="weight", params={'max_val': 500, 'min_val':0, 'required': True}).save() >>> height = DBArg(name="height", params={'max_val': 290}).save() >>> human_argstructure = DBStruct(args=[weight, height]).save() >>> human = Category(name="human", arg_structure=human_argstructure).save() 

हां, मुझे पता है कि लोगों को बेचना बहुत नैतिक नहीं है, लेकिन ऐसा सिर्फ हुआ है :)

अब हमें एक रैपर की आवश्यकता है जिसके साथ हम सामानों के नाम बनाएंगे:

 @app.route('/step15_abstract') def abstract_add_item(category: ItemArg(Category, required=True, p_type=str)): creator = category.get_creator() wrapped_creator = app._arg_taker(creator) return str(wrapped_creator().id) 

अब यह बहुत बदसूरत लग रहा है। यह वास्तुकला में एक और गलती के कारण है। हालांकि, पिछले एक की तुलना में बहुत कम महत्वपूर्ण है। ओह ठीक है। अब मैं समझाता हूँ कि यहाँ क्या हो रहा है।

सबसे पहले, हम उस श्रेणी में श्रेणी उदाहरण प्राप्त करते हैं जो पहले से ही ऊपर वर्णित था ( Note मॉडल के साथ उदाहरण देखें)। तदनुसार, यदि उपयोगकर्ता किसी गैर-मौजूद श्रेणी में उत्पाद को जोड़ने का प्रयास करता है, तो उसे DoNotExist प्राप्त होगा। इस श्रेणी में प्राथमिक कुंजी इसका सिस्टम नाम है, और यह उसका उपयोगकर्ता है जिसे पहचानकर्ता के रूप में पास होना चाहिए। हमारे मामले में, यह human । तदनुसार, संपूर्ण अनुरोध इस तरह दिखना चाहिए:
localhost:5000/step15_abstract?category=human&weight=100&height=200
बाकी को तथाकथित निर्माता को अन्य मापदंडों को प्राप्त करने के लिए है। app._arg_taker - एक डेकोरेटर जो समापन बिंदु को स्रोत से लापता तर्क को "प्राप्त" करने की अनुमति देता है। हमारे मामले में, यह request.args है, लेकिन, सिद्धांत रूप में, स्रोत कोई भी हो सकता है। दरअसल, इस खंड में मेरी वास्तु गलती है। एक अच्छे तरीके से, इस तरह के डेकोरेटर में नेस्टेड एंडपॉइंट्स लपेटने की आवश्यकता नहीं होनी चाहिए।

अनुमानित संस्करण: कभी नहीं, यह सिर्फ एक अनुभव है

निष्कर्ष और भविष्य

खैर, शायद यह वह जगह है जहां हम आज समाप्त हो जाएंगे। अब आप लंबे विषयों पर अटकलें लगा सकते हैं। सबसे पहले, मैं उन सभी को धन्यवाद देना चाहूंगा जिन्होंने पहली पोस्ट का जवाब दिया। इस तथ्य के बावजूद कि किसी ने एक भी रचनात्मक प्रस्ताव नहीं किया है, आपने वास्तव में नैतिक रूप से मेरी मदद की :)

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

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

बाद में मैं एक और, अंतिम लेख लिखूंगा। वह पहले से ही "वास्तविक जीवन" से दृढ़ता से जुड़ी होगी। मेरा मानना ​​है कि कुछ सेवा की कोडिंग प्रक्रिया का विवरण होगा। अब मेरे पास केवल एक ही विचार है, और यह एक दिलचस्प साइट (एक उदास पांडा के साथ) पर टैग सिस्टम से जुड़ा हुआ है। लेकिन अन्य सुझावों को सुनकर मुझे खुशी होगी। माइक्रोब्लॉगिंग, क्यू एंड ए मंचों, जो भी हो। मैं प्रतिबंध या इस तरह की किसी भी चीज़ के बारे में ध्यान नहीं देता। यह महत्वपूर्ण है कि इस कोड के उदाहरण पर आप मेरे "पालतू" के कई पहलुओं को दिखा सकते हैं। अन्य बातों के अलावा, यह आपको अभ्यास में इसकी जांच करने की अनुमति देगा, और संभवतः कुछ बग या वास्तु दोषों का पता लगाएगा।

आपका ध्यान देने के लिए धन्यवाद। हमेशा की तरह, मैं किसी भी आलोचना और किसी भी इच्छा से खुश हूं।

मुख्य शलजम
फ्लास्क-गेट (लेख से सभी प्रयोगों का कोड यहाँ है)