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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4