>> 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
> 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
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
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 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
> > 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 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
>
> > 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
> 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
ACTIVITY SUMMARY (2010-09-03 - 2010-09-10)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues stats:
open2554 (+46)
closed 19050 (+69)
total 21604 (+65)
Open issues with patches: 1
Hey #python-dev,
I'd like to ask your opinion on this change; I think it should be reverted
or at least made silent by default. Basically, it prints a warning like
gc: 2 uncollectable objects at shutdown:
Use gc.set_debug(gc.DEBUG_UNCOLLECTABLE) to list them.
at interpreter shut
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
On Fri, Sep 10, 2010 at 4:32 PM, Georg Brandl wrote:
> IMO this runs contrary to the decision we made when DeprecationWarnings were
> made silent by default: it spews messages not only at developers, but also at
> users, who don't need it and probably are going to be quite confused by it,
Agreed;
2010/9/10 Fred Drake :
> On Fri, Sep 10, 2010 at 4:32 PM, Georg Brandl wrote:
>> IMO this runs contrary to the decision we made when DeprecationWarnings were
>> made silent by default: it spews messages not only at developers, but also at
>> users, who don't need it and probably are going to be qu
Georg Brandl writes:
> it prints a warning (...) at interpreter shutdown if gc.garbage is nonempty.
>
> IMO this runs contrary to the decision we made when DeprecationWarnings were
> made silent by default
>
> Opinions?
Agreed, this should be reverted for the reasons you give but DO LEAVE THIS
On Fri, Sep 10, 2010 at 3:32 PM, Georg Brandl wrote:
> IMO this runs contrary to the decision we made when DeprecationWarnings
> were
> made silent by default: it spews messages not only at developers, but also
> at
> users, who don't need it and probably are going to be quite confused by it,
> a
I'd like to propose that the Python community standardize on a
"deferred" object for asynchronous return values, modeled after the
well-thought-out Twisted Deferred class.
With more and more Python libraries implementing asynchronicity (for
example Futures -- PEP 3148), it's crucial to have a
On Sep 10, 2010, at 5:10 PM, Amaury Forgeot d'Arc wrote:
> 2010/9/10 Fred Drake :
>> On Fri, Sep 10, 2010 at 4:32 PM, Georg Brandl wrote:
>>> IMO this runs contrary to the decision we made when DeprecationWarnings were
>>> made silent by default: it spews messages not only at developers, but als
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
Moving to python-ideas.
Have you seen http://www.python.org/dev/peps/pep-3148/ ? That seems
exactly what you want.
--Guido
On Fri, Sep 10, 2010 at 4:00 PM, James Yonan wrote:
> I'd like to propose that the Python community standardize on a "deferred"
> object for asynchronous return values, mod
On Sat, Sep 11, 2010 at 9:42 AM, Glyph Lefkowitz
wrote:
>
> On Sep 10, 2010, at 5:10 PM, Amaury Forgeot d'Arc wrote:
>
>> 2010/9/10 Fred Drake :
>>> On Fri, Sep 10, 2010 at 4:32 PM, Georg Brandl wrote:
IMO this runs contrary to the decision we made when DeprecationWarnings
were
ma
On Sat, Sep 11, 2010 at 7:39 AM, amaury.forgeotdarc
wrote:
> There is no need to bump the PYC magic number: the new opcode is used
> for code that did not compile before.
If the magic number doesn't change for 3.2, how will 3.1 know it can't
run pyc and pyo files containing these opcodes?
The ma
2010/9/10 Nick Coghlan :
> On Sat, Sep 11, 2010 at 7:39 AM, amaury.forgeotdarc
> wrote:
>> There is no need to bump the PYC magic number: the new opcode is used
>> for code that did not compile before.
>
> If the magic number doesn't change for 3.2, how will 3.1 know it can't
> run pyc and pyo fil
On Sat, Sep 11, 2010 at 10:33 AM, Benjamin Peterson wrote:
> 2010/9/10 Nick Coghlan :
>> On Sat, Sep 11, 2010 at 7:39 AM, amaury.forgeotdarc
>> wrote:
>>> There is no need to bump the PYC magic number: the new opcode is used
>>> for code that did not compile before.
>>
>> If the magic number does
24 matches
Mail list logo
