Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Ari Freund Newsgroups: comp.lang.python Subject: Proposal: named return values through dict initialization and unpacking Date: Tue, 21 Jun 2016 10:34:20 +0300 Lines: 54 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: news.uni-berlin.de GKLQ0h9+U9nVU4L0ZVYGAALVImsqHMaCexc8tgMubNdQ== Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'assignment': 0.07; 'e.g.,': 0.07; 'important,': 0.07; 'dict': 0.09; 'disregard': 0.09; 'effect.': 0.09; 'output,': 0.09; 'output': 0.13; 'def': 0.13; "hasn't": 0.15; 'variables': 0.15; 'assignment.': 0.16; 'bugs,': 0.16; 'bugs.': 0.16; 'correctly,': 0.16; 'i.e.,': 0.16; 'lhs': 0.16; 'parts.': 0.16; 'received:io': 0.16; 'received:psf.io': 0.16; 'rejected.': 0.16; 'statement.': 0.16; 'subject:values': 0.16; 'unpacking.': 0.16; 'element': 0.18; 'variable': 0.18; 'arguments': 0.22; 'keys': 0.22; 'subject:skip:i 10': 0.22; 'suppose': 0.22; '(or': 0.23; 'appear': 0.26; 'error': 0.27; 'equivalent': 0.27; 'order.': 0.27; 'right.': 0.27; 'message-id:@mail.gmail.com': 0.27; 'idea': 0.28; 'values': 0.28; 'currently,': 0.29; 'dictionary': 0.29; 'pep': 0.29; 'yields': 0.29; 'code': 0.30; "i'd": 0.31; 'extend': 0.31; 'getting': 0.33; 'run': 0.33; 'useful': 0.33; 'problem': 0.33; 'combination': 0.33; 'values.': 0.33; 'add': 0.34; 'received:google.com': 0.35; 'could': 0.35; 'skip:* 20': 0.35; 'community': 0.36; 'but': 0.36; 'too': 0.36; 'there': 0.36; 'serve': 0.36; 'received:209.85': 0.36; 'keyword': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'two': 0.37; 'received:209.85.213': 0.37; 'received:209': 0.38; 'wrong': 0.38; 'to:addr:python.org': 0.40; 'care': 0.60; 'more': 0.63; 'believe': 0.66; 'here': 0.66; 'skip:\xc2 10': 0.67; 'risk': 0.68; 'dict()': 0.84; 'dict.': 0.84; 'worthy': 0.84; 'subject:Proposal': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=NjTjBHUFWLuxyVFi45aJKSmY/sLwWTzwCi4wAaqGGOA=; b=lWK2q87oCcwniq/flI0sGBx4EdqlhS2NxuF9OK2MV0L6wdc9tv/4GiB8bbXfHL0tNp 02CgruGWPt+Hc2DZWt/fh055pgWlemXttKMunwfh3HY38PAXbPsA00hQhs7oyiG+/Jxe u9fvhIBGi056L0koR6nhFyCTyzN/vLZMncKfqBTuefKBUlv3IC+lnUPRayzkf/00I88Z 588fFcaSZpQ+FYnct+oNrHS70SmMDOUxVXQtM5XHNahlgvdUqb+XJXPzFuQ9AiESnJjj UaJI4S/uzFXnOKelryPGOExs9vv4EfeF+SrUN9xiB8ARfu7o6w1BgUE9fAoQuSxb5ein 4iNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NjTjBHUFWLuxyVFi45aJKSmY/sLwWTzwCi4wAaqGGOA=; b=aFdPhSpQwDRAU9/H3EcenT9MCYX0aEr5M9minbFPoFqgUzr8XMpouloEVDRu2ZAnSp 3cdmiUv8GmIxDDO8YNHiG4lCKFuhf5TQQjUpHsMl5rZ+RpP6zSmjbwT3ILPoPnnZYY3O wcwPMyf4krWhJCbiAS7jb//zf7VaD+37nBZU4TeHIv2Z775hIhsYL4kRVSV81bL3+rpf jYghCPEvbPeA0SSxGgSNk/zrXEGMfLLLrh2lgakh04IiFW3vDJtL9XHFWVvpQlgdx1vu /XuBginV5xS3JIFlTwMwrII0sghXCXPWIMW2x9IO9e7iZW54aQybNhEEE6unR36D0Ou3 ojjw== X-Gm-Message-State: ALyK8tLRpag9d5luw/bgyO/XxQ79MzkiG6EwhdNdKVxKaLF5FdFea5D7dCkZ5GUMfHX/aK7i1kR7owPxsNkcyGB+ X-Received: by 10.31.227.196 with SMTP id a187mr9247415vkh.116.1466494480347; Tue, 21 Jun 2016 00:34:40 -0700 (PDT) X-Mailman-Approved-At: Tue, 21 Jun 2016 03:37:20 -0400 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: Xref: csiph.com comp.lang.python:110217 I'd like to run this idea by the community to see if it's PEP worthy and hasn't been already rejected. Background Just as keyword arguments enhance code readability and diminish the risk of bugs, so too would named return values. Currently, we can write val1, val2, val3 = myfunc() but we must take care to order the variables correctly, i.e., in the same order as the corresponding values in myfunc's return statement. Getting it wrong may result in difficult-to-detect bugs. This problem would be alleviated if we could name the return values and disregard their order. My proposal consists of two parts. 1. Add a new form of assignment by dictionary unpacking. Suppose d is a dict whose keys are the strings 'var1', 'var2', 'var3'. Then the assignment var1, var2, var3 = **d would set the variables to the corresponding values. Order would not be important, so var3, var1, var2 = **d would have the same effect. Also, not all keys would need to participate; for example, var2 = **d would work just fine. It would be an error for the same name to appear more than once on the LHS of the assignment. It would be an error for a name on the LHS to not be a valid variable name or for there not to be a corresponding key in the dict. It would (possibly) be an error if the dict contained keys that are not strings (or are strings that cannot serve as variable names). 2. Extend the dict() form of dictionary initialization to allow an element to be a variable name, e.g., dict(var1, var2, var3, var4=33) would be equivalent to dict(var1=var1, var2=var2, var3=var3, var4=33) I believe each of the above is useful in its own right. Additionally, their combination yields reasonably streamlined named return value functionality, as in def RunShellCmd(cmd): exit_code, output = commands.getstatusoutput(cmd) # Here we need to get the order right. return dict(exit_code, output) output, exit_code = **RunShellCmd("ls .") # Here we don't care about order.