[Python-Dev] IronPython specific code in inspect module

[David Stanek]

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.
>
> I wish we had more of a policy about this. There seems to be a long
> tradition of special casing other implementations in the stdlib. For
> example, see types.py and tests/test_support.py for remnants of Jython
> compatibility. However, I suspect this code has languished with out
> core-developers using the trunk stdlib with Jython. I suppose this is
> a good reason why we are going to split the stdlib out of the main
> repo.
>
> 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.
 2. Add executing this new configuration to the bootstrapping process.
 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