Jason E. Sibre wrote:

>>I wouldn't use this approach for any module declaring classes of any
>>objects that persisted beyond a single request. Then again, I probably
>>wouldn't use reload() in that case, either. ;-) But it seems to work
>>nicely for PTL modules and UI classes that define throwaway objects.
>>
> I ran smack into this problem... My design style (evidently) is different
> from yours, making the reloading of modules tricky, and not something that
> can just be tacked on as an afterthought.
>
> I tend to use Quixote to publish object namespaces, rather than module
> namespaces (with the exception of the root, which is a package).  As a
> result, I am almost always picky about what I import where; I use from x
> import y, z...  This makes reloading the module just about useless.

Yes, that's a tough one.

> Further, I generally have objects that survive the page request, so even if
> I reload the class def, my old copy of the class is still based on the old
> code, and will be until I recreate it.  I never do, in some instances.  I
> expect it to be created at app start up, and be available from then on.

I should point out that I do use long-lived objects for my data and
business logic, I just don't use them in the UI, (except sometimes in
_q_lookup() but those are throwaways).

Any chance you could introduce a bit more separation between your 'data
classes' and your 'presentation classes'? Whenever you want to publish a
data object, wrap it in an appropriate presentation object which does
the rendering? In that approach, the presentation classdefs could be
reloaded without modifying your persistent objects' definitions. Not
sure if it would work in your situation, but it's one way to get both
objects and reloadability.

(I wanted to write a Quixote app using this approach with Philip Eby's
PyProtocols package, which would go the extra step of automagically
adapting a data object into a presentation proxy (with a little
guidance, of course). Never got around to it, though, and not sure it's
a worthy approach...)


> The 'solution' I've used so far is to have a Restart link available in my
> apps that tells the app to exit.  FastCGI takes care of actually restarting
> it for me.  It's not perfect, which is why I was excited over your idea.
> (I'm persisting session info to disk, so it works out ok.)
>
> Unfortunaely, due to my approach, Neil's idea isn't immediately useful to
> me, either (I'd still have to recreate my objects).
>
> I think what it boils down to is that my design approach just isn't 'dynamic
> source code' friendly.

Hmmm... I think you're right.

I know that with old-style classes, you can update the __class__
attribute of an object to change its type; if you could reference all
your Widget instances, you could:

     NewWidgetClassDefinition = somehow_ckeck_for_updated(WidgetClass)

     for widget in all_widgets:
         widget.__class__ = NewWidgetClassDefinition

but that's delving deeper into reload-madness that I would personally
like to go. I think I'd convert to the "presentation wrapper" concept
long before I tried this!


>
> It has been educational working with this, and I may try some experiments
> with a more module-namespace approach in the future.  I just felt it was a
> mite cumbersome to map UI concepts directly to modules/packages, but very
> easy to map them to class instances.

I felt the same way, and only switched to the package/module approach
recently. I had stayed away from it, thinking it looked like a style for
old-timey Unix hackers who didn't trust those newfangled "object"
thingamajigs. But I have to admit, it's not nearly as bad as it first
seemed, and has become quite natural in a relatively short time.

>
> Jason

Best,

-- Graham