[Python-Dev] IronPython specific code in inspect module (original) (raw)

Doug Hellmann doug.hellmann at gmail.com
Wed May 20 13:13:44 CEST 2009

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

More information about the Python-Dev mailing list