Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Nick Coghlan
On Sat, Sep 11, 2010 at 6:46 AM, Georg Brandl wrote: > [me] >> Although it *is* somewhat handy for quick introspection at the >> interpreter prompt... maybe I should document it after all. Thoughts? > > IMO show_code() is not a good name, because the only thing it doesn't > do is to -- show the co

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Georg Brandl
Am 10.09.2010 14:41, schrieb Nick Coghlan: > On Fri, Sep 10, 2010 at 5:06 PM, Eli Bendersky wrote: >> Nick, did you know that dis.show_code is neither exported by default from >> the dis module, nor it's documented in its help() or .rst documentation? >> Neither is code_info(), which is used by sh

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Éric Araujo
> Yeah, I changed my mind and have now documented it properly. The 3.2 > versionadded tag on show_code is currently a little questionable > though. Guido actually checked in the original (undocumented) version > of show_code before 3.0 was released. The only thing new about it in > 3.2 is it being

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Eli Bendersky
> > > My intention in this post was to clarify whether I'm misunderstanding > > something or the term 'free' is indeed used for different things in > > different places. If this is the latter, IMHO it's an inconsistency, even > if > > a small one. When I read the code I saw 'free' I went to the do

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Guido van Rossum
On Fri, Sep 10, 2010 at 12:00 AM, Eli Bendersky wrote: >>> def some_func(myparam): >> >> >     def internalfunc(): >> >     return cc * myparam >> > >> > CPython infers that in 'internalfunc', while 'myparam' is free, 'cc' is >> >> What exactly do you mean by "infers" ? How do you know that it

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Eli Bendersky
> > I mostly use the dis module for quick-n-dirty exploration of the results > of > > compilation into bytecode, and I'm sure many people use for the same > effect. > > Thus show_code seems like a convenient shortcut, although not a necessary > > one. The string returned by code_info isn't interact

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Nick Coghlan
On Fri, Sep 10, 2010 at 11:23 PM, Eli Bendersky wrote: > When you say "is in the normal documentation", do you mean you added it > recently ? Although I see it here: > http://docs.python.org/dev/py3k/library/dis.html, it's neither in the docs > of 3.1.2 (http://docs.python.org/py3k/library/dis.htm

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Eli Bendersky
On Fri, Sep 10, 2010 at 15:41, Nick Coghlan wrote: > On Fri, Sep 10, 2010 at 5:06 PM, Eli Bendersky wrote: > > Nick, did you know that dis.show_code is neither exported by default from > > the dis module, nor it's documented in its help() or .rst documentation? > > Neither is code_info(), which

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Nick Coghlan
On Fri, Sep 10, 2010 at 5:06 PM, Eli Bendersky wrote: > Nick, did you know that dis.show_code is neither exported by default from > the dis module, nor it's documented in its help() or .rst documentation? > Neither is code_info(), which is used by show_code(). I wonder if this is > intentional. c

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Eli Bendersky
> There's a slight inconsistency. The names a code object explicitly > calls out as free variables (i.e. references to cells in outer scopes) > are only a subset of the full set of free variables (every referenced > name that isn't a local variable or an attribute). > > >>> from dis import show_cod

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-10 Thread Eli Bendersky
>> def some_func(myparam): > > def internalfunc(): > > return cc * myparam > > > > CPython infers that in 'internalfunc', while 'myparam' is free, 'cc' is > > What exactly do you mean by "infers" ? How do you know that it infers > that? How does it matter for your understanding of the

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-09 Thread Nick Coghlan
On Fri, Sep 10, 2010 at 2:43 AM, Eli Bendersky wrote: > def some_func(myparam): >     def internalfunc(): >     return cc * myparam > > CPython infers that in 'internalfunc', while 'myparam' is free, 'cc' is > global because 'cc' isn't bound in the enclosing scope, although according > to the

Re: [Python-Dev] terminology for "free variables" in Python

2010-09-09 Thread Guido van Rossum
On Thu, Sep 9, 2010 at 9:43 AM, Eli Bendersky wrote: > The execution model section of the Python reference manual defines free > variables as follows: > >     "If a variable is used in a code block but not defined there, it is > a free variable" > > This makes sense and fits the academic definitio

[Python-Dev] terminology for "free variables" in Python

2010-09-09 Thread Eli Bendersky
The execution model section of the Python reference manual defines free variables as follows: "If a variable is used in a code block but not defined there, it is a free variable" This makes sense and fits the academic definition. The documentation of the symtable module supports this definiti