Re: Global Python interpreter?

[Sergio Mucino]

The thing is that the data I tend to keep at the global level I usually need it briefly, and I tend to change it quite often. I use it more for development, not for actual steady access, so having to go through files and load them into memory is just a bit more trouble for what I'll get from them. Say I'm developing certain tools and I need some functions I need to call as I develop stuff. But these functions are constantly fluctuating too. It's just very convenient to have them in memory and call them from whichever tool or even from the command line at any time I need them. It just allows for very fast iterations of my work. I have no problems managing my changes, and I tend to keep good track of what I'm doing. SI's current way of handling script scope doesn't really help, but that's just because of the way I'm used to working (just as long-time SI users have gotten used to how things work in SI, and probably feel a little weird when having to switch to a different environment). I'll deal with it somehow. Thanks for throwing all the suggestions in, though! It's great to know the options available. :-) On 21/10/2013 7:57 PM, Chris Chia wrote: I know this is a bit foolish suggestion which is to write your global data (in py format) to a temp file on disk. Then load that file as a py file. This is a quick workaround. Chris On 22 Oct, 2013, at 5:46 AM, Raffaele Fragapane <raffsxsil...@googlemail.com> wrote: To be perfectly honest I'm still on the fence about that behaviour. In some ways it's nice, and it's relatively easier to debug Maya live because of it than it is Softimage. On the other hand multiple runs and coarsely grained iterations tend to pollute the environment beyond belief, and God forbid you change your mind about a name, or commit a typo that you repeat further down the line or other similar mistakes, since you get those odd to debug situations but without the benefit of having everything plain to read, and your work is committed to some transient void somewhere. All in all it's occasionally convenient, but generally a horrible way to work. Ultimately I find that either way (Soft's or Maya) you have a trade off somewhere, in Soft you have to spend extra time on a framework for persistent items, in Maya on one to investigate and clean up the mess. Between the two I probably prefer Soft's by a small margin, while overly safe it's not as infuriating as Maya's constant, undoable, easily mis triggered nuking and committing of anything you happen to dump in a script editor tab. I'm not sure I'd consider it a nice to have feature to make Soft equally twitchy, especially since we have successfully hooked debuggers and all to it and it's easy to write a simple framework to work with for transient objects and experimentation (while Maya's infamous editor nuke is impossible to prevent). Try to invest a little bit of time in how you work through it, and you might find the same way of working will trickle to your Maya work as well after a while with its added safety and structure. On Tue, Oct 22, 2013 at 12:51 AM, Sergio Mucino <sergio.muc...@modusfx.com> wrote: Thanks Raffaele. Yes, in both applications I've used (Maya and Max) this is how it works. Any functions and variables I declare or define at the global scope remain in memory throughout the session. This makes it very easy to iterate over different version of tool development. It seems SI won't be as user-friendly in the same department (Modo used to be like that, but they just released a Python API with 7.1 that allows for a persistent interpreter, which solves the same problem). Given that this is one of those things I can't really work around, I'll just consider it as a little "would be really nice to address" note for the Softimage team. Thanks a lot for all the comments! <Sergio Mucino_Signature_email.gif> On 20/10/2013 5:44 PM, Raffaele Fragapane wrote: I might have been unclear, sorry. No, it won't work across tabs of course, but it gets closer to Maya's way of working within each tab (which I understand is where Sergio comes from), and it allows to expand or contract module functionality on the fly. For it to work across different interpreters yes, you need to extend it with some files, a directory parser, and a push to dir wrapper to extend the magic module. On Sat, Oct 19, 2013 at 2:46 AM, Luc-Eric Rousseau <luceri...@gmail.com> wrote: On Thu, Oct 17, 2013 at 6:22 PM, Raffaele Fragapane <raffsxsil...@googlemail.com> wrote: > If you want something to be available across the board you can simply write > it, register it as a module, and push it. No need for it to exist as a file. I've read the link, but I can't see how you could use this to push functions to a different instance of the python interpreter without using some file on disk (or copy/pasting the code between script editor tabs) -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!