Re: [Python-ideas] [Python-Dev] Persistent Python - a la Smalltalk
On Sep 19, 2011, at 3:12 AM, Godson Gera wrote:
Yes, and I put it in in the hopes that they are discouraged :-). There's a staggering number of really good ideas out there for people to work on; why get stuck re-hashing the bad ones? Of course, maybe they've got a really fantastic idea about how a persistent python might work, but they'll have to face more obstacles than this one comment in order to get it done, so it shouldn't make that much of a difference. I think it's my responsibility, as someone who has tried this idea, to make sure that others attempting it know that it's problematic. As Clay Shirky put it: "... learning from experience is the worst possible way to learn something. Learning from experience is one up from remembering. That's not great. The best way to learn something is when someone else figures it out and tells you: 'Don't go in that swamp. There are alligators in there.'" So, trust me: there are alligators in that pickle. -glyph
On 9/19/2011 10:59 AM, Guido van Rossum wrote:
Now I want to try a spicy gator pickle... (that _is_ a great quote.) The only way I could see something like this working is on a closed system, s.t. there are no assumptions or interactions (files open/locked, external window managers/states, etc.) that cannot be fully accounted for by the values of the system itself. (You could theoretically attempt to record the information not available form interrogating the current state as such are declared, but there would be lots of room for errors, and, even then, no guarantees.) I don't think Python is the correct place to attempt such a thing. This sounds more like a VM- or OS-level affair, to me. I CAN see some value in adding functionality to ease interaction with such features, such as invoking or being aware when it's invoked. I guess I want to know what problem this is intended to solve. If it's purely theoretical, that's cool, but I'd like to know. If not, can you explain why it would help you? That would help me understand this idea better. -Nate
[Regarding a proposal to persist and resume the current application state] On Mon, Sep 19, 2011 at 7:52 PM, Spectral One <ghostwriter402@gmail.com> wrote:
The only way I could see something like this working is on a closed system,
Neither Lisp nor Smalltalk are entirely closed, but ... they are certainly more closed-world in practice than other languages are in practice.
That was in fact the case for everything I ever actually cared to persist. The primary use case was an extended interactive-shell exploration, rather than a server process. (A secondary use case was checkpointing, but that already took a bit of work to ensure your program would pause and give you a chance to take that checkpoint.) A third use case was faster testing of updated code, but I'm not certain that was a net gain against the possibility of having multiple versions of a function alive simultaneously.
Some information is already recorded for garbage collection, and for good error reports; it really doesn't take all that much more.
I don't think Python is the correct place to attempt such a thing. This sounds more like a VM- or OS-level affair, to me.
-jJ
On 9/19/2011 10:59 AM, Guido van Rossum wrote:
Now I want to try a spicy gator pickle... (that _is_ a great quote.) The only way I could see something like this working is on a closed system, s.t. there are no assumptions or interactions (files open/locked, external window managers/states, etc.) that cannot be fully accounted for by the values of the system itself. (You could theoretically attempt to record the information not available form interrogating the current state as such are declared, but there would be lots of room for errors, and, even then, no guarantees.) I don't think Python is the correct place to attempt such a thing. This sounds more like a VM- or OS-level affair, to me. I CAN see some value in adding functionality to ease interaction with such features, such as invoking or being aware when it's invoked. I guess I want to know what problem this is intended to solve. If it's purely theoretical, that's cool, but I'd like to know. If not, can you explain why it would help you? That would help me understand this idea better. -Nate
[Regarding a proposal to persist and resume the current application state] On Mon, Sep 19, 2011 at 7:52 PM, Spectral One <ghostwriter402@gmail.com> wrote:
The only way I could see something like this working is on a closed system,
Neither Lisp nor Smalltalk are entirely closed, but ... they are certainly more closed-world in practice than other languages are in practice.
That was in fact the case for everything I ever actually cared to persist. The primary use case was an extended interactive-shell exploration, rather than a server process. (A secondary use case was checkpointing, but that already took a bit of work to ensure your program would pause and give you a chance to take that checkpoint.) A third use case was faster testing of updated code, but I'm not certain that was a net gain against the possibility of having multiple versions of a function alive simultaneously.
Some information is already recorded for garbage collection, and for good error reports; it really doesn't take all that much more.
I don't think Python is the correct place to attempt such a thing. This sounds more like a VM- or OS-level affair, to me.
-jJ
participants (4)
-
Glyph Lefkowitz -
Guido van Rossum -
Jim Jewett -
Spectral One