Re: [Python-Dev] IronPython specific code in inspect module
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
Re: [Python-Dev] IronPython specific code in inspect module
On Wed, May 20, 2009 at 7:13 AM, Doug Hellmann doug.hellm...@gmail.com wrote: On May 19, 2009, at 10:21 PM, David Stanek wrote: 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? Basically yes. What I proposed is more like a service locator with a pinch of DI. Where can I learn more about what Tarek is working on? Is there a branch somewhere? 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? By executing I mean figure out the mappings and necessarily create them. This enables errors to happen early if the dependencies are not met. This is really useful if the technique is used for more than just the platform specific code. 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. -- 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/archive%40mail-archive.com
Re: [Python-Dev] IronPython specific code in inspect module
On Wednesday 20 May 2009 13:54:56 David Stanek wrote: On Wed, May 20, 2009 at 7:13 AM, Doug Hellmann doug.hellm...@gmail.com wrote: On May 19, 2009, at 10:21 PM, David Stanek wrote: 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? Basically yes. What I proposed is more like a service locator with a pinch of DI. Where can I learn more about what Tarek is working on? Is there a branch somewhere? it is here: http://wiki.python.org/moin/Distutils/PluginSystem and there: http://pypi.python.org/pypi/extensions cheers, sebastien. -- # # Dr. Sebastien Binet # Laboratoire de l'Accelerateur Lineaire # Universite Paris-Sud XI # Batiment 200 # 91898 Orsay # ___ 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
[Python-Dev] IronPython specific code in inspect module
Hello all, The inspect module (inspect.get_argspec etc) work fine for Python functions and classes in IronPython, but they don't work on .NET types which don't have the Python function attributes like im_func etc. 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. All the best, Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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
Re: [Python-Dev] IronPython specific code in inspect module
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. 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 ___ 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
Re: [Python-Dev] IronPython specific code in inspect module
2009/5/19 Maciej Fijalkowski fij...@gmail.com: From my observation (mostly according to jython), such changes easily get out of sync. The net result is that you have one, outdated, version in stdlib and other implementation, like IronPython is maintaining it's own anyway. IMO it's easy enough to maintain clearly implementation-specific parts out of cpython's stdlib. Hopefully, it will be easier to visualize how this might work once the plan for hg migration is finalized. What I would rather like to see is that stdlib does not contain impl specific parts, even for cpython and cpython maintains it's own things outside of stdlib. This would be in line with what we discussed at pycon I think, please correct me if I'm wrong. I was not present, but that's my impression, too. -- Regards, Benjamin ___ 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
Re: [Python-Dev] IronPython specific code in inspect module
Michael Foord wrote: 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. What about instead defining __argspec__ for built-in functions/method objects and allowing all the implementations to implement it? We could all agree to return: [ (return_type, (arg_types,...)), (return_type, (arg_types,...)), ] Then inspect can check for that attribute and support introspection on built-ins. This would be an easy feature for us to implement and it may also be for Jython as well given that we both get the power of our platforms reflection capabilities. Any platform that implements it lights up w/o new platform specific code. And maybe this needs to go to python-ideas now :) ___ 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
Re: [Python-Dev] IronPython specific code in inspect module
Dino Viehland wrote: What about instead defining __argspec__ for built-in functions/method objects and allowing all the implementations to implement it? We could all agree to return: [ (return_type, (arg_types,...)), (return_type, (arg_types,...)), ] Then inspect can check for that attribute and support introspection on built-ins. This would be an easy feature for us to implement and it may also be for Jython as well given that we both get the power of our platforms reflection capabilities. Any platform that implements it lights up w/o new platform specific code. And maybe this needs to go to python-ideas now :) Curiously, inspect limitations on CPython (can't inspect functools.partial, has issues with some descriptors and decorators) got us chatting about PEP 362: Function Signature Object[0] on #python-dev today. PEP 362 was also brought up in a recent thread where the executive summary was 'it just needs someone to guide it through the last steps'[1], and it would make this kind of introspection nice and clean[2]. It makes even more sense now we have PEP 3107: Function Annotations[3] in place. Cheers, Daniel [0] http://www.python.org/dev/peps/pep-0362/ [1] http://mail.python.org/pipermail/python-dev/2009-April/088517.html [2] http://mail.python.org/pipermail/python-dev/2009-April/088597.html [3] http://www.python.org/dev/peps/pep-3107/#parameters ___ 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
