Bug Changes

I've noticed the SF-FAQ still has the old "Use Jitterbug" thing about
bugs, even though we've moved to SourceForge bug manager. Attached is
a patch to correct everything. 

I haven't checked it in, because I'm not sure I my explanations are
clear at all. I'd be happy if someone went over it and saw if it's all
right.

--
Moshe Zadka <moshez <at> math.huji.ac.il> -- 95855124
http://advogato.org/person/moshez

Index: sf-faq.html
===================================================================
RCS file: /cvsroot/python/python/nondist/sf-html/sf-faq.html,v
retrieving revision 1.15
diff -c -r1.15 sf-faq.html
*** sf-faq.html	2000/08/25 07:55:48	1.15
--- sf-faq.html	2000/11/01 14:33:50
***************
*** 57,63 ****
  <h2><a href="#bugs">6. Bug Reporting</a></h2>
  <ol>
    <li><a href="#b1">Where can I submit/view bugs for Python?</a></li>
!   <li><a href="#b2">How do I use jitterbug?</a></li>
  </ol>
  
  <h2><a href="#appendix">A. Appendix</a></h2>
--- 57,63 ----

Re: Python Call Mechanism

Jeremy Hylton <jeremy <at> alum.mit.edu> writes:

> >>>>> "MAL" == M -A Lemburg <mal <at> lemburg.com> writes:
> 
>   MAL> Jeremy Hylton wrote:
>   >>
>   >> Update of /cvsroot/python/python/dist/src/Python In directory
>   >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
>   >>
>   >> Modified Files: ceval.c ...  N.B. The CALL_FUNCTION
>   >> implementation is getting really hairy; should review it to see
>   >> if it can be simplified.
> 
>   MAL> How about a complete redesign of the whole call mechanism ?!
>
[chomp]
> 
> I'd be interested in looking at it.

Random idea that occurred while answering a post on comp.lang.python:

How about dumping the CALL_FUNCTION* opcodes, and replacing them with
two non-argumented opcodes, called for the sake of argument NCALL_FUNC
and NCALL_FUNC_KW.

NCALL_FUNC would pop a function object and a tuple off the stack and
apply the function to the tuple.

NCALL_FUNC_KW would do the same, then pop a dictionary and then do
the moral equivalent of f(*args,**kw).

Re: Python Call Mechanism

My first impression is that this sounds like a nice simplifcation.

One question is how expensive this is for the common case.  Right now
arguments are pushed on the interpreter stack before CALL_FUNCTION is
executed, which is just a pointer assignment.  The pointers on the
stack are then assigned into the fast locals of the function after the
call.  Your scheme sounds like it would increase all function calls by
the cost of a tuple allocation.

It certainly wouldn't hurt to implement this, as it would provide some
practical implementation experience that would inform a PEP on the
subject.

On a related note, I have proposed a pep to add nested lexical scopes
for Python 2.1.  Barry's away for the moment, so it hasn't been
assigned a number yet.  It's just a proposal, not sure what Guido will
say in the end, but it also involves revising the function call
architecture.  I'll send a copy of the current draft (just notes)
under a separate subject.

Jeremy

statically nested scopes

Title: Statically Nested Scopes
Author: Jeremy Hylton <jeremy <at> digicool.com>
Status: Draft
Type: Standards Track
Created: 01-Nov-2000

Abstract

    This PEP proposes the additional of statically nested scoping
    (lexical scoping) for Python 2.1.  The current language definition
    defines exactly three namespaces that are used to resolve names --
    the local, global, and built-in namespaces.  The addition of
    nested scopes would allow resolution of unbound local names in
    enclosing functions' namespaces.

    One consequence of this change that will be most visible to Python
    programs is that lambda statements could reference variables in
    the namespaces where the lambda is defined.  Currently, a lambda
    statement uses default arguments to explicitly creating bindings
    in the lambda's namespace.

Notes

    This section describes several issues that will be fleshed out and
    addressed in the final draft of the PEP.  Until that draft is
    ready, please direct comments to the author.

    This change has been proposed many times in the past.  It has
    always been stymied by the possibility of creating cycles that
    could not be collected by Python's reference counting garbage

Re: Python Call Mechanism

Michael Hudson wrote:
> 
> Jeremy Hylton <jeremy <at> alum.mit.edu> writes:
> 
> > >>>>> "MAL" == M -A Lemburg <mal <at> lemburg.com> writes:
> >
> >   MAL> Jeremy Hylton wrote:
> >   >>
> >   >> Update of /cvsroot/python/python/dist/src/Python In directory
> >   >> slayer.i.sourceforge.net:/tmp/cvs-serv32349/Python
> >   >>
> >   >> Modified Files: ceval.c ...  N.B. The CALL_FUNCTION
> >   >> implementation is getting really hairy; should review it to see
> >   >> if it can be simplified.
> >
> >   MAL> How about a complete redesign of the whole call mechanism ?!
> >
> [chomp]
> >
> > I'd be interested in looking at it.
> 
> Random idea that occurred while answering a post on comp.lang.python:
> 
> How about dumping the CALL_FUNCTION* opcodes, and replacing them with
> two non-argumented opcodes, called for the sake of argument NCALL_FUNC
> and NCALL_FUNC_KW.
> 
> NCALL_FUNC would pop a function object and a tuple off the stack and
> apply the function to the tuple.
> 

Re: statically nested scopes

[pre-PEP]

This will break code... I'm not sure whether it's worth going
down this path just for the sake of being able to define
functions within functions.

Wouldn't it be a better idea to somehow add native acqusition
to Python's objects ?

We already have a slot which implements the "contains"
relationship. All we'd need is a way for a contained
object to register itself with the container in a 
way that doesn't produce cycles.

--

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/

Re: statically nested scopes

>>>>> "MAL" == M -A Lemburg <mal <at> lemburg.com> writes:

  MAL> [pre-PEP] This will break code... I'm not sure whether it's
  MAL> worth going down this path just for the sake of being able to
  MAL> define functions within functions.

How will this break code?  Any code written to use the scoping rules
will not work today.

Python already allows programs to define functions within functions.
That's not at issue.  The issue is how hard it is to use nested
functions, including lambdas.

  MAL> Wouldn't it be a better idea to somehow add native acqusition
  MAL> to Python's objects ?

No.

Seriously, I don't see how acquistion addresses the same issues at
all.  Feel free to explain what you mean.

  MAL> We already have a slot which implements the "contains"
  MAL> relationship. All we'd need is a way for a contained object to
  MAL> register itself with the container in a way that doesn't
  MAL> produce cycles.

The contains relationship has to do with container objects and their
contents.  A function's environment is not a container in the same
sense, so I don't see how this is related.

Re: statically nested scopes

Jeremy Hylton wrote:
> 
> >>>>> "MAL" == M -A Lemburg <mal <at> lemburg.com> writes:
> 
>   MAL> [pre-PEP] This will break code... I'm not sure whether it's
>   MAL> worth going down this path just for the sake of being able to
>   MAL> define functions within functions.
> 
> How will this break code?  Any code written to use the scoping rules
> will not work today.
> 
> Python already allows programs to define functions within functions.
> That's not at issue.  The issue is how hard it is to use nested
> functions, including lambdas.

The problem is that with nested scoping, a function defined
within another function will suddenly reference the variables
of the enclosing function as globals and not the module
globals... this could break code.

Another problem is that you can't reach out for the defining
module globals anymore (at least not in an easy way like today).

>   MAL> Wouldn't it be a better idea to somehow add native acqusition
>   MAL> to Python's objects ?
> 
> No.
> 
> Seriously, I don't see how acquistion addresses the same issues at
> all.  Feel free to explain what you mean.

Re: statically nested scopes

    MAL> [pre-PEP] This will break code...

    Jeremy> How will this break code?

Suppose you have

    x = 1
    def f1():
        x = 2
        def inner():
            print x
        inner()

Today, calling f1() prints "1".  After your proposed changes I suspect it
would print "2".

Skip

Re: statically nested scopes

>>>>> "MAL" == M -A Lemburg <mal <at> lemburg.com> writes:

  MAL> [pre-PEP] This will break code... I'm not sure whether it's
  MAL> worth going down this path just for the sake of being able to
  MAL> define functions within functions.
  >>
  >> How will this break code?  Any code written to use the scoping
  >> rules will not work today.
  >>
  >> Python already allows programs to define functions within
  >> functions.  That's not at issue.  The issue is how hard it is to
  >> use nested functions, including lambdas.

  MAL> The problem is that with nested scoping, a function defined
  MAL> within another function will suddenly reference the variables
  MAL> of the enclosing function as globals and not the module
  MAL> globals... this could break code.

That's right it could, in the unlikely case that someone has existing
code today using nested functions where an intermediate function
defines a local variable that shadows a variable defined in an
enclosing scope.  

It should be straightfoward to build a tool that would detect this
case.

It would be pretty poor programming style, so I think it would be fine
to break backwards compatibility here.

  MAL> Another problem is that you can't reach out for the defining