On May 19, 2009, at 10:21 PM, David Stanek wrote:
On Tue, May 19, 2009 at 9:26 PM, Benjamin Peterson <benja...@python.org
> wrote:
2009/5/19 Michael Foord <fuzzy...@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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/doug.hellmann%40gmail.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
