python पाइथन लैम्बडा क्यों उपयोगी हैं?




function lambda (21)

मैं पाइथन लैम्बदास को समझने की कोशिश कर रहा हूं। क्या लैम्ब्डा उन "रोचक" भाषा वस्तुओं में से एक है जो वास्तविक जीवन में भुला दिया जाना चाहिए?

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

यह मुझे सी प्रकारों के अतिप्रवाह (बफर ओवरफ्लो) की याद दिलाता है - अन्य चर मूल्यों को सेट करने के लिए शीर्ष चर और ओवरलोडिंग को इंगित करता है। यह एक तकनीकी शोषण की तरह लगता है लेकिन रखरखाव कोडर दुःस्वप्न।


I'm a python beginner, so to getter a clear idea of lambda I compared it with a 'for' loop; in terms of efficiency. Here's the code (python 2.7) -

import time
start = time.time() # Measure the time taken for execution

def first():
    squares = map(lambda x: x**2, range(10))
    # ^ Lambda
    end = time.time()
    elapsed = end - start
    print elapsed + ' seconds'
    return elapsed # gives 0.0 seconds

def second():
    lst = []
    for i in range(10):
        lst.append(i**2)
    # ^ a 'for' loop
    end = time.time()
    elapsed = end - start
    print elapsed + ' seconds'
    return elapsed # gives 0.0019998550415 seconds.

print abs(second() - first()) # Gives 0.0019998550415 seconds!(duh)

मैं लैम्ब्डा को उन कार्यों की सूची के लिए उपयोगी लगता हूं जो समान करते हैं, लेकिन विभिन्न परिस्थितियों के लिए। मोज़िला बहुवचन नियमों की तरह

plural_rules = [
    lambda n: 'all',
    lambda n: 'singular' if n == 1 else 'plural',
    lambda n: 'singular' if 0 <= n <= 1 else 'plural',
    ...
]
# Call plural rule #1 with argument 4 to find out which sentence form to use.
plural_rule[1](4) # returns 'plural'

यदि आपको उन सभी के लिए एक फ़ंक्शन परिभाषित करना होगा जो आप इसके अंत तक पागल हो जाएंगे। साथ ही यह plural_rule_1 , plural_rule_2 , आदि जैसे फ़ंक्शन नामों के साथ अच्छा नहीं होगा और जब आप एक चर फ़ंक्शन आईडी पर निर्भर करते हैं तो आपको इसे eval() करना होगा।


दो-पंक्ति सारांश:

  1. Closures : बहुत उपयोगी। उन्हें जानें, उनका इस्तेमाल करें, उन्हें प्यार करें।
  2. पायथन का lambda कीवर्ड: अनावश्यक, कभी-कभी उपयोगी। यदि आप अपने आप को दूरस्थ रूप से जटिल बनाते हैं, तो इसे हटा दें और एक वास्तविक कार्य को परिभाषित करें।

I use it quite often, mainly as a null object or to partially bind parameters to a function.

Here are examples:

to implement null object pattern:

{
    DATA_PACKET: self.handle_data_packets
    NET_PACKET: self.handle_hardware_packets
}.get(packet_type, lambda x : None)(payload)

for parameter binding:

let say that I have the following API

def dump_hex(file, var)
    # some code
    pass

class X(object):
    #...
    def packet_received(data):
        # some kind of preprocessing
        self.callback(data)
    #...

Then, when I wan't to quickly dump the recieved data to a file I do that:

dump_file = file('hex_dump.txt','w')
X.callback = lambda (x): dump_hex(dump_file, x)
...
dump_file.close()

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

मेरा सुझाव है कि आप Closures और मैप फ़ंक्शन (जो कि पाइथन दस्तावेज़ों से लिंक होते हैं, पर चर्चा करते हैं, लेकिन यह लगभग हर भाषा में मौजूद है जो कार्यात्मक संरचनाओं का समर्थन करता है) यह देखने के लिए कि यह उपयोगी क्यों है।


lambda साथ आप बहुत कुछ कर सकते हैं आप या तो नामित कार्यों या सूची और जनरेटर अभिव्यक्तियों के साथ बेहतर कर सकते हैं।

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


A useful case for using lambdas is to improve the readability of long list comprehensions . In this example loop_dic is short for clarity but imagine loop_dic being very long. If you would just use a plain value that includes i instead of the lambda version of that value you would get a NameError .

>>> lis = [{"name": "Peter"}, {"name": "Josef"}]

>>> loop_dic = lambda i: {"name": i["name"] + " Wallace" }
>>> new_lis = [loop_dic(i) for i in lis]

>>> new_lis
[{'name': 'Peter Wallace'}, {'name': 'Josef Wallace'}]

के बजाय

>>> lis = [{"name": "Peter"}, {"name": "Josef"}]

>>> new_lis = [{"name": i["name"] + " Wallace"} for i in lis]

>>> new_lis
[{'name': 'Peter Wallace'}, {'name': 'Josef Wallace'}]

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

Lambdas भ्रमित हो जाते हैं, लेकिन एक बार ठोस समझ प्राप्त हो जाने के बाद, आप इस तरह के स्वच्छ सुरुचिपूर्ण कोड लिख सकते हैं:

squared = map(lambda x: x*x, [1, 2, 3, 4, 5])

कोड की उपरोक्त पंक्ति सूची में संख्याओं के वर्गों की एक सूची देता है। अशुभ, आप इसे भी कर सकते हैं:

def square(x):
    return x*x

squared = map(square, [1, 2, 3, 4, 5])

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

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

एक और व्यावहारिक दृष्टिकोण से, हाल ही में मेरे लिए लैम्बडास के सबसे बड़े फायदों में से एक जीयूआई और घटना संचालित प्रोग्रामिंग में रहा है। यदि आप टिंकर में कॉलबैक पर नज़र डालते हैं, तो वे जो भी तर्क लेते हैं, वे घटनाएं होती हैं जो उन्हें ट्रिगर करती हैं। उदाहरण के लिए

def define_bindings(widget):
    widget.bind("<Button-1>", do-something-cool)

def do-something-cool(event):
    #Your code to execute on the event trigger

अब क्या होगा यदि आपके पास पास करने के लिए कुछ तर्क थे? माउस-क्लिक के निर्देशांक को संग्रहीत करने के लिए 2 तर्कों को पार करने के रूप में सरल कुछ। आप आसानी से ऐसा कर सकते हैं:

def main():
    # define widgets and other imp stuff
    x, y = None, None
    widget.bind("<Button-1>", lambda event: do-something-cool(x, y))

def do-something-cool(event, x, y):
    x = event.x
    y = event.y
    #Do other cool stuff

अब आप तर्क दे सकते हैं कि यह वैश्विक चर का उपयोग करके किया जा सकता है, लेकिन क्या आप वास्तव में मेमोरी प्रबंधन और रिसाव के बारे में चिंतित अपने सिर को धक्का देना चाहते हैं, खासकर यदि वैश्विक चर का उपयोग केवल एक विशेष स्थान पर किया जाएगा? यह सिर्फ खराब प्रोग्रामिंग शैली होगी।

संक्षेप में, भेड़ का बच्चा भयानक है और कभी कम करके आंका नहीं जाना चाहिए। पाइथन लैम्बदास LISP lambdas के समान नहीं हैं (जो अधिक शक्तिशाली हैं), लेकिन आप वास्तव में उनके साथ बहुत जादुई सामान कर सकते हैं।


I use lambdas to avoid code duplication. It would make the function easily comprehensible Eg:

def a_func()
  ...
  if some_conditon:
     ...
     call_some_big_func(arg1, arg2, arg3, arg4...)
  else
     ...
     call_some_big_func(arg1, arg2, arg3, arg4...)

I replace that with a temp lambda

def a_func()
  ...
  call_big_f = lambda args_that_change: call_some_big_func(arg1, arg2, arg3, args_that_change)
  if some_conditon:
     ...
     call_big_f(argX)
  else
     ...
     call_big_f(argY)

पहली बधाई जो लैम्ब्डा को समझने में कामयाब रही। मेरी राय में यह वास्तव में कार्य करने के लिए शक्तिशाली निर्माण है। इन दिनों प्रवृत्ति प्रोग्रामिंग भाषाओं की ओर प्रवृत्ति निश्चित रूप से एक संकेतक है कि न तो इससे बचा जाना चाहिए और न ही निकट भविष्य में इसे फिर से परिभाषित किया जाएगा।

आपको बस थोड़ा अलग सोचना है। मुझे यकीन है कि जल्द ही आप इसे प्यार करेंगे। लेकिन सावधान रहें यदि आप केवल अजगर के साथ सौदा करते हैं। चूंकि लैम्ब्डा वास्तविक बंद नहीं होता है, इसलिए यह किसी भी तरह से "टूटा हुआ" होता है: पाइथन लैम्ब्डा टूट जाता है


लैम्ब्डा फ़ंक्शन यह एक फ़ंक्शन बनाने के लिए एक गैर-नौकरशाही तरीका है।

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

पारंपरिक तरीका:

def main():
...
...
y = square(some_number)
...
return something

def square(x):
    return x**2

लैम्ब्डा रास्ता:

def main():
...
square = lambda x: x**2
y = square(some_number)
return something

फर्क देखें?

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

>>>a = [1,2,3,4]
>>>[x**2 for x in a]
[1,4,9,16]

चलिए देखते हैं कि वाक्यविन्यास के प्रत्येक तत्व का अर्थ क्या है:

[]: "मुझे एक सूची दें"

एक्स ** 2: "इस नए जन्म वाले फ़ंक्शन का उपयोग करना"

एक्स में एक के लिए: "प्रत्येक तत्व में एक" में

यह सुविधाजनक है ओह? इस तरह के कार्यों का निर्माण। चलो लैम्बडा का उपयोग कर इसे फिर से लिखें:

>>> square = lambda x: x**2
>>> [square(s) for x in a]
[1,4,9,16]

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

(i) एक समारोह

(ii) एक पुनरावृत्त

और आपको एक सूची देता है जहां प्रत्येक तत्व यह क्रिया है जो हर तत्व के प्रत्येक तत्व पर लागू होता है।

तो, मानचित्र का उपयोग करके हमारे पास होगा:

>>> a = [1,2,3,4]
>>> squared_list = map(lambda x: x**2, a)

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


Lambda is a procedure constructor. You can synthesize programs at run-time, although Python's lambda is not very powerful. Note that few people understand that kind of programming.


I use lambda to create callbacks that include parameters. It's cleaner writing a lambda in one line than to write a method to perform the same functionality.

उदाहरण के लिए:

import imported.module

def func():
    return lambda: imported.module.method("foo", "bar")

as opposed to:

import imported.module

def func():
    def cb():
        return imported.module.method("foo", "bar")
    return cb

Lambdas सामान्य रूप से कार्यात्मक प्रोग्रामिंग शैली से गहराई से जुड़े हुए हैं। यह विचार कि आप कुछ डेटा में फ़ंक्शन लागू करके समस्याओं को हल कर सकते हैं, और परिणामों को विलय कर सकते हैं, यह Google अपने अधिकांश एल्गोरिदम को लागू करने के लिए उपयोग करता है।

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


मैंने डेविड मर्टज़ की पुस्तक आज 'टेक्स्ट प्रोसेसिंग इन पायथन' पढ़ना शुरू कर दिया। जबकि लैम्ब्डा के पहले अध्याय में उदाहरणों के बारे में उनके बारे में काफी जानकारी है, जिसमें परिशिष्ट ए में स्पष्टीकरण के साथ संयुक्त रूप से उन्हें मेरे लिए पृष्ठ से कूद दिया गया है (अचानक) और अचानक मैं उनके मूल्य को समझ गया। That is not to say his explanation will work for you and I am still at the discovery stage so I will not attempt to add to these responses other than the following: I am new to Python I am new to OOP Lambdas were a struggle for me Now that I read Mertz, I think I get them and I see them as very useful as I think they allow a cleaner approach to programming.

He reproduces the Zen of Python, one line of which is Simple is better than complex. As a non-OOP programmer reading code with lambdas (and until last week list comprehensions) I have thought- This is simple? । I finally realized today that actually these features make the code much more readable, and understandable than the alternative-which is invariably a loop of some sort. I also realized that like financial statements-Python was not designed for the novice user, rather it is designed for the user that wants to get educated. I can't believe how powerful this language is. When it dawned on me (finally) the purpose and value of lambdas I wanted to rip up about 30 programs and start over putting in lambdas where appropriate.


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

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

असल में यह कई बिंदुओं पर उबाल जाता है:

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

उन्हें गोल करने और नामित बंद करने के लिए उन्हें बदलने के लिए पर्याप्त कारण है। हालांकि, मैं अज्ञात बंद करने के खिलाफ दो अन्य परेशानियों को पकड़ता हूं।

पहला रुख यह है कि वे भाषा को अपनाने वाले एक और अनावश्यक कीवर्ड हैं।

दूसरा रुख गहरा है और प्रतिमान स्तर पर, यानी मुझे यह पसंद नहीं है कि वे एक कार्यात्मक-प्रोग्रामिंग शैली को बढ़ावा दें, क्योंकि यह शैली संदेश उत्तीर्ण, ऑब्जेक्ट उन्मुख या प्रक्रियात्मक शैलियों की तुलना में कम लचीली है, क्योंकि लैम्ब्डा कैलकुलेशन ट्यूरिंग नहीं है- पूरा (सौभाग्य से पायथन में, हम अभी भी एक लैम्ब्डा के अंदर भी उस प्रतिबंध से बाहर हो सकते हैं)। मुझे लगता है कि लैम्बास इस शैली को बढ़ावा देने के कारण हैं:

  • एक निहित वापसी है, यानी वे प्रतीत होते हैं कि उन्हें 'कार्य' होना चाहिए।

  • वे एक वैकल्पिक राज्य-छिपाने की व्यवस्था हैं, एक और अधिक स्पष्ट, अधिक पठनीय, अधिक पुन: प्रयोज्य और अधिक सामान्य तंत्र: विधियां।

मैं लैम्ब्डा मुक्त पायथन लिखने के लिए कड़ी मेहनत करता हूं, और दृष्टि पर भेड़ के बच्चे को हटा देता हूं। मुझे लगता है कि पाइथन बिना भेड़ के बच्चे की थोड़ी बेहतर भाषा होगी, लेकिन यह मेरी राय है।


lambda function कहने का सिर्फ एक शानदार तरीका है। इसके नाम के अलावा, इसमें कुछ भी अस्पष्ट, डरावना या गुप्त नहीं है। जब आप निम्न पंक्ति को पढ़ते हैं, तो अपने दिमाग में function करके lambda को प्रतिस्थापित करें:

>>> f = lambda x: x + 1
>>> f(3)
4

यह सिर्फ x एक समारोह को परिभाषित करता है। R जैसी कुछ अन्य भाषाएं, इसे स्पष्ट रूप से कहें:

> f = function(x) { x + 1 }
> f(3)
4

आप समझ सकते हैं? यह प्रोग्रामिंग में करने के लिए सबसे प्राकृतिक चीजों में से एक है।


मुझे संदेह है कि लैम्ब्डा चलेगा। आखिरकार इसे हटाने की कोशिश करने के बारे में गिडो की पोस्ट देखें। संघर्ष की रूपरेखा भी देखें।

आप पाइथन की कार्यात्मक विशेषताओं के पीछे सौदे के बारे में अधिक इतिहास के लिए इस पोस्ट को देख सकते हैं: http://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html

उत्सुकता से, नक्शा, फ़िल्टर, और उन कार्यों को कम करें जो मूल रूप से लैम्ब्डा और अन्य कार्यात्मक विशेषताओं के परिचय को प्रेरित करते हैं, को बड़ी मात्रा में सूची समझ और जनरेटर अभिव्यक्तियों से अलग किया गया है। वास्तव में, पाइथन 3.0 में बिल्टिन फ़ंक्शंस की सूची से कम फ़ंक्शन हटा दिया गया था। (हालांकि, लैम्ब्डा, मानचित्र या फ़िल्टर को हटाने के बारे में शिकायतों को भेजना जरूरी नहीं है: वे रह रहे हैं। :-)

मेरे अपने दो सेंट: स्पष्ट रूप से लैम्ब्डा इसके लायक है जहां तक ​​स्पष्टता जाती है। आम तौर पर एक और स्पष्ट समाधान होता है जिसमें लैम्ब्डा शामिल नहीं होता है।


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

for value in ["one","two","three"]:
    b = tk.Button(label=value, command=lambda arg=value: my_callback(arg))
    b.pack()

(नोट: हालांकि यह सवाल विशेष रूप से lambda बारे में पूछ रहा है, आप उसी प्रकार के परिणाम प्राप्त करने के लिए functools.partial का भी उपयोग कर सकते हैं)

विकल्प प्रत्येक बटन के लिए एक अलग कॉलबैक बनाना है जो डुप्लिकेट कोड का कारण बन सकता है।


मैं सिर्फ पाइथन शुरू कर रहा हूं और पहले लाम्बाडा में सिर चला गया- जिसने मुझे समझने में थोड़ी देर लगाई।

ध्यान दें कि यह किसी भी चीज की निंदा नहीं है। हर किसी के पास ऐसी चीजों का एक अलग सेट होता है जो आसानी से नहीं आते हैं।

क्या लैम्ब्डा उन 'रोचक' भाषा वस्तुओं में से एक है जो वास्तविक जीवन में भुला दिया जाना चाहिए?

नहीं।

मुझे यकीन है कि कुछ किनारे के मामले हैं जहां इसकी आवश्यकता हो सकती है, लेकिन इसकी अस्पष्टता दी गई है,

यह अस्पष्ट नहीं है। पिछले 2 टीमों ने मैंने काम किया है, हर कोई इस सुविधा का हर समय इस्तेमाल करता है।

भविष्य की रिलीज में इसे फिर से परिभाषित करने की संभावना (मेरी धारणा इसकी विभिन्न परिभाषाओं के आधार पर)

मैंने कुछ साल पहले बंद करने वाले अर्थशास्त्र को ठीक करने से परे, पायथन में इसे फिर से परिभाषित करने के लिए कोई गंभीर प्रस्ताव नहीं देखा है।

और कम कोडिंग स्पष्टता - इसे टाला जाना चाहिए?

यदि आप इसका उपयोग कर रहे हैं तो यह कम स्पष्ट नहीं है। इसके विपरीत, अधिक भाषा संरचना उपलब्ध होने से स्पष्टता बढ़ जाती है

यह मुझे सी प्रकारों के अतिप्रवाह (बफर ओवरफ्लो) की याद दिलाता है - अन्य चर मूल्यों को सेट करने के लिए शीर्ष चर और ओवरलोडिंग को इंगित करता है ... एक तकनीकी शोषण की तरह लेकिन रखरखाव कोडर दुःस्वप्न ..

लैम्ब्डा बफर ओवरफ्लो की तरह है? वाह। मैं कल्पना नहीं कर सकता कि आप लैम्ब्डा का उपयोग कैसे कर रहे हैं यदि आपको लगता है कि यह "रखरखाव दुःस्वप्न" है।


I can give you an example where I actually needed lambda serious. I'm making a graphical program, where the use right clicks on a file and assigns it one of three options. It turns out that in Tkinter (the GUI interfacing program I'm writing this in), when someone presses a button, it can't be assigned to a command that takes in arguments. So if I chose one of the options and wanted the result of my choice to be:

print 'hi there'

Then no big deal. But what if I need my choice to have a particular detail. For example, if I choose choice A, it calls a function that takes in some argument that is dependent on the choice A, B or C, TKinter could not support this. Lamda was the only option to get around this actually...







closures