[IronPython] What's the situation on being able to accept patches?

[Dino Viehland]

I think it should look something like this:

          delegate object ParamsDelegate(params object[] args);
        [SpecialName]
        public static void PerformModuleReload(PythonContext/*!*/ context, IAttributesCollection/*!*/ dict) {
            object prev;
            if(context.BuiltinModuleInstance.TryGetName(SymbolTable.StringToId("compile"), out prev)) {
                        context.BuiltinModuleInstance.SetName(SymbolTable.StringToId("compile"), new ParamsDelegate(new CompilerHelper(prev, context).compile));
            }
        }

        class CompileHelper {
            private object _prev;
                private PythonContext _context;
                object compile(params object[] args) {
                        if(someCheck) {
                                return BuildYourAst();
                        }
                        return _context.Call(new CodeContext(new Scope(), _context), args);
            }
        }

That's a little more complicated than it needs to be but that's due to too many internal APIs.  For example there's no good way for you to make a builtin function so I'm just exposing a callable delegate directly instead.

I'm just going to expose the existing items we have on GeneratorExpression for the time being.  That'll unblock you and it keeps the change small for 2.0.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff
Sent: Monday, October 13, 2008 3:49 PM
To: Discussion of IronPython
Subject: Re: [IronPython] What's the situation on being able to accept patches?

On Mon, Oct 13, 2008 at 3:50 PM, Dino Viehland <dinov at microsoft.com> wrote:
> In the mean time I would assume you just need the FunctionDefinition and Expression exposed off of GeneratorExpression.  Is that right or is it something else?  I should be able to do that for RC1.
>

That's initially what I did, but exposing an optimization in a public interface did not sit well with me. I thought ideally it should offer the same public interface as a ListComprehension node, so I implemented that. Benefit is it provides a consistent interface to users of the IronPython ast (me included). I'm attaching the modified .cs file here, you can use it as a reference if you decide to take that approach.

> For compile I think you could back-patch the built-in modules.  You can add a [SpecialName] void PerformModuleReload(PythonContext, IAttributeCollection) method to your module to know when it gets imported/reloaded and you can then patch builtin.compile with a version of your own which calls the built-in version.

I like the sound of that. It could be possible for people to use _ast with an official IronPython 2.0 distribution. I've seen the PerformModuleReload around in the source code, but I'm not clear on how to replace the builtin compile from there. If you could give me a brief example I can fix my code to work that way.

Thanks,

-Dan