nevow/stackless bugs -- patch
I've been trying to run stan on stackless when I ran into a problem with render methods. Stackless uses "stackless.instancemethod" instead of "__builtin__.instancemethod", and "stackless.function" instead of "__builtin__.function". Attached is a svn diff patch of the changes I made to __init__.py in order for stan to support stackless properly. HTH, Peter Hunt
On Sep 30, 2004, at 3:45 PM, Peter Hunt wrote:
I've been trying to run stan on stackless when I ran into a problem with render methods. Stackless uses "stackless.instancemethod" instead of "__builtin__.instancemethod", and "stackless.function" instead of "__builtin__.function". Attached is a svn diff patch of the changes I made to __init__.py in order for stan to support stackless properly.
I think this is a serious problem with the lazy adapter registration. Even for things that aren't __builtin__ brokenness. For example, if I refactor and move some classes around, their module name will change. To maintain backwards compatibility, I keep the binding in the old module with a deprecation warning, which keeps everything happy, EXCEPT for the lazy adapter registration. Since it keys on the full object name, it breaks. But, as for this patch, committed. James
On Sep 30, 2004, at 7:04 PM, James Y Knight wrote:
On Sep 30, 2004, at 3:45 PM, Peter Hunt wrote:
I've been trying to run stan on stackless when I ran into a problem with render methods. Stackless uses "stackless.instancemethod" instead of "__builtin__.instancemethod", and "stackless.function" instead of "__builtin__.function". Attached is a svn diff patch of the changes I made to __init__.py in order for stan to support stackless properly.
I think this is a serious problem with the lazy adapter registration. Even for things that aren't __builtin__ brokenness. For example, if I refactor and move some classes around, their module name will change. To maintain backwards compatibility, I keep the binding in the old module with a deprecation warning, which keeps everything happy, EXCEPT for the lazy adapter registration. Since it keys on the full object name, it breaks.
But, as for this patch, committed.
It's also a problem when you have an adapter registration and then you delete the adapter. You have garbage in your registrations that you don't know about until later. To help prevent this situation from occurring, I wrote some tests which assert that all the registered adapters actually exist, so while you might not see it in production, you'll see it if you run the tests. I think writing a test that verifies your adapters are registered properly is the best solution. dp
On Sep 30, 2004, at 7:50 PM, Donovan Preston wrote:
I think writing a test that verifies your adapters are registered properly is the best solution.
I don't see how that addresses the inability to provide compatibility when refactoring modules and moving classes. James
participants (3)
-
Donovan Preston -
James Y Knight -
Peter Hunt