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
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
> 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
>
> > 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
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
> > 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
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
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
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
> 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
>> 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
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
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
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
14 matches
Mail list logo