[Python-Dev] IronPython specific code in inspect module

[Doug Hellmann]

On May 19, 2009, at 10:21 PM, David Stanek wrote:

> On Tue, May 19, 2009 at 9:26 PM, Benjamin Peterson <benjamin at python.org 
> > wrote:
>> 2009/5/19 Michael Foord <fuzzyman at voidspace.org.uk>:
>>> I have IronPython specific versions of several of these functions  
>>> which use
>>> .NET reflection and inspect could fallback to if sys.platform ==  
>>> 'cli'.
>>> Would it be ok for me to add these to the inspect module?  
>>> Obviously the
>>> tests would only run on IronPython... The behaviour for CPython  
>>> would be
>>> unaffected.

[...]

>> However that still leaves the question of how to handle putting code
>> like this in. Should we ask that all code be
>> implementation-independent as much as possible from the original
>> authors? Do all all changes against the stdlib have to be run against
>> several implementations? Should we sprinkle if switches all over the
>> codebase for different implementations, or should new support files  
>> be
>> added?
>>
>
> It seems that using a technique similar to dependency injection could
> provide some value. DI allows implementations conforming to some
> interface to be injected into a running application without the messy
> construction logic. The simple construction-by-hand pattern is to
> create the dependencies and pass them into the dependent objects.
> Frameworks build on top of this to allow the dependencies to be wired
> together without having any construction logic in code, like switch
> statements, to do the wiring.
>
> I think a similar pattern could be used in the standard library. When
> the interpreter goes through its normal bootstrapping process in can
> just execute a module provided by the vendor that specifies the
> platform specific implementations. Some defaults can be provided since
> Python already has a bunch of platform specific implementations.
>
> An over simplified design to make this happen may look like:
> 1. Create a simple configuration that allows a mapping of interfaces
> to implementations. This is where the vendor would say when using
> inspect you really should be using cli.inspect.

That sounds like a plugin and the "strategy" pattern.  Tarek is doing  
some work on providing a standard plugin mechanism as part of the work  
he's doing on distutils, isn't he?

> 2. Add executing this new configuration to the bootstrapping process.

Maybe I misunderstand, but wouldn't it make more sense to initialize  
the platform-specific parts of a module when it is imported rather  
than bring in everything at startup?

Are we only worried about interpreter-implementation-level  
dependencies, or should there be a way for all platform-specific  
features to be treated in the same way?   There are quite a few checks  
for Windows that could be moved into the platform-specific modules if  
there was an easy/standard way to do it.

Doug

> 3. Add generic hooks into the library where needed to load the
> dependency instead of platform specific if statements.
> 4. Rip out the platform specific code that is hidden in the if
> statements and use that as the basis for the sane injected defaults.
> 5. Document the interfaces for each component that can be changed by
> the vendor.
>
> -- 
> David
> blog: http://www.traceback.org
> twitter: http://twitter.com/dstanek
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/doug.hellmann%40gmail.com