From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WKLeNf/fzl66AgAA0tVLHw (envelope-from ) for ; Wed, 27 May 2020 21:47:43 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 0DmcMf/fzl7vJgAAbx9fmQ (envelope-from ) for ; Wed, 27 May 2020 21:47:43 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5D3C69401AE for ; Wed, 27 May 2020 21:47:43 +0000 (UTC) Received: from localhost ([::1]:43520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1je3tg-0005gS-QJ for larch@yhetil.org; Wed, 27 May 2020 17:47:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1je3sq-0005eQ-7k for emacs-orgmode@gnu.org; Wed, 27 May 2020 17:46:44 -0400 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]:40956) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1je3sp-0006jb-8y for emacs-orgmode@gnu.org; Wed, 27 May 2020 17:46:43 -0400 Received: by mail-pj1-x102e.google.com with SMTP id ci23so2127730pjb.5 for ; Wed, 27 May 2020 14:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=LHmmDvwI0ozTnPIkZmlxI64OU/f1fMZG0bavv6hBlRY=; b=D2IJzIvnPWWmGljQt5S2U8oMi88j5+11DjEXYpKHs99NcxGggGqTdLg7Eby1JIzaSb mj9kGWnuG3bv1yhcS6yO/NWERAh++lZJ33GW+JuXGgfZPBW3jS3fgBcyXHEb8952BBco x8O2nGuo52ZwM4z0spV/Yk9IMIqYXEZCkB5GKOaJZ7CuUeZ2X+RBnIl/oNhP8JYwAV2h Db0kG2ueJpITDMafJivKmYPVcVCW5H6rb6HMyw7XJ3AHmWbOTNc/ZeKIwBxeZ1m7m4lC 3YtzwUatjZwo3PO2o8FPnahUokYnjnjSsuIb0+g0So9qxPYudiYPJ2pu7A9W2u8KZ1wT iElw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=LHmmDvwI0ozTnPIkZmlxI64OU/f1fMZG0bavv6hBlRY=; b=bn67QowrPWqWVlFdB+aDeB9vGLjhmLM+9dWfgVXXEOMxu1IFSyJmTgphGZMvOvD9Hk Xe0TaOEOa0pFgFp61EbjwclA+yrrV7Tp0DwJlEM9kivx5gJ4KtPl444BODTBfGe17Yzb P3g/pA4AboIv/0SLtGcbTvVkT+8jqOb5l2N715xu3Asd92DpL+gDhFHgeKuVFw6Is5sa PxJfdm43QAz8FZW5MJFopEgObcLwgZmQiddmcVtx3l8IP0Q4jBPJu0Slzp2tXc/hR7+Q uDLL3UCFlhV7vDW4r7Z1qzocyK6DQyuMTUOORrbqhH8O0vdCzogZKJRM8tX+dxfe89uy 2Hnw== X-Gm-Message-State: AOAM533DNGAhvu36nhM/DHSGnb+KTT+8++A7jNEb0PlOcwsee1ID3BTT glfccrff5sCezF0Z100pJE0= X-Google-Smtp-Source: ABdhPJyprDMhty6lk/FI1TbXbJelc8K/JKvf53dwbOHJ2JTteUppMnqM/r2kbHi1lQfFhdag+vhhgw== X-Received: by 2002:a17:902:549:: with SMTP id 67mr386238plf.115.1590616001284; Wed, 27 May 2020 14:46:41 -0700 (PDT) Received: from localhost (199-83-220-90.PUBLIC.monkeybrains.net. [199.83.220.90]) by smtp.gmail.com with ESMTPSA id e5sm2728721pfe.121.2020.05.27.14.46.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2020 14:46:40 -0700 (PDT) From: Jack Kamm To: Matthew Lundin , =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= , emacs-orgmode@gnu.org Subject: Re: Bug: ob-python mangles multiline :var values [9.3.6 (release_9.3.6-397-ga089600)] In-Reply-To: <87h7w18ca1.fsf@fastmail.fm> References: <87sgico0ne.fsf@gmail.com> <87a71xtmh0.fsf@gmail.com> <87h7w18ca1.fsf@fastmail.fm> Date: Wed, 27 May 2020 14:46:39 -0700 Message-ID: <87zh9t9hkw.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::102e; envelope-from=jackkamm@gmail.com; helo=mail-pj1-x102e.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=D2IJzIvn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.21 X-TUID: enncoNpapkDT Hi Matt -- > A heads up... I believe this changes the scope of the :var variables, > since they previously were local to the main() function and now they are > declared globally. After this change, some of my existing python source > blocks (i.e., ones in which I attempt to assign a new value to a > variable defined by :var) now generate the following error: > > Traceback (most recent call last): > File "", line 223, in > File "", line 214, in main > UnboundLocalError: local variable 'members' referenced before assignment Thanks for noticing this and pointing it out. This was an oversight on my end (I don't really use ":var" or non-session blocks). Unfortunately, the fix for the original bug will have to be a bit more complicated to avoid this error. I'll put it on my todo list, but if anyone wants to have a crack at it, that would be very welcome. We should also add a unit test for this regression so it doesn't happen again. > I hesitate to call this a bug, since it would be fine to think of > everything within the source block as local and the header :var > declarations as global. I think it's fair to call this a bug. I think it would be inconvenient to be unable to assign to these variables. Also, I did not intend to break any existing code with this. > And I suppose it would be worthwhile to ask: Is this change consistent > with other org-babel modules? Is there a canonical way that org-babel > handles scope? IMO everything ought to be in the same scope, and the user shouldn't have to think about the scope of the main() function that ob-python wraps the body in. Especially since non-session blocks are evaluated independently of other blocks, we really shouldn't have to think about their scope. I'm not sure if the Org manual provides any guidance here, but from a quick check I didn't see anything about it. Ideally I think everything should just be in global scope; however ob-python needs to use a wrapper function for the "return" keyword.