On Jun 17, 3:53 pm, "Rhodri James" <rho...@wildebst.demon.co.uk> wrote: > On Wed, 17 Jun 2009 16:06:22 +0100, Aaron Brady <castiro...@gmail.com> > wrote: > > > > > On Jun 16, 10:09 am, Mike Kazantsev <mk.frag...@gmail.com> wrote: > >> On Tue, 16 Jun 2009 06:57:13 -0700 (PDT) > > >> Aaron Brady <castiro...@gmail.com> wrote: > >> > Making the charitable interpretation that this was the extent of c-l- > >> > py's support and enthusiasm for my idea, I will now go into mourning. > >> > Death occurred at oh-eight-hundred. Rest in peace, support & > >> > enthusiasm. > > >> I've read this thread from the beginning, being tempted to insert > >> remarks about shelve module or ORMs like SQLAlchemy, but that'd be > >> meaningless without the problem description, which I haven't seen > >> anywhere. Is it some trick idea like "let's walk on our heads"? > > > More like bronze them, or hang them on a tackboard. You haven't > > convinced me that it's not a problem, or that it's an easy one. > > Unfortunately it's up to you to demonstrate that it is a problem, > whichever of the many possible 'it's you're talking about. So far, > the question "Why would I want to use this? What's the use case?" > has gone unanswered, and I'm sure I'm not the only baffled by it.
I can demonstrate it's a problem; many things are. The subject line says it all. SQL will persist (and share for IPC, after a fashion) sets of statically typed tuples. But we have need for sets of dynamically typed tuples, in volatile storage at the very least, or no one would like Python. Whether we have need for them in persistent storage remains to be seen. POSH Python Object SHaring has been at least one student's graduate thesis. It couldn't hurt to pursue it if one has time, as with many things. It's pretty likely my estimates of end user usefulness of 'KeepDB', say, derive sturdily and steadily from our estimated popularity of Python. So much for my motives, though not for my opportunities. My implementation has followed two separate paths: one using SQL for a back-end host; the other using hand-coded bytes on disk, complete with large file support using views, and on-disk (or in-buffer) memory management, which incidentally I spoke up about about a year ago. It was the topic of an honors lecture in the Data Structures course in my undergrad. For the record, I still can't beat a log-N balanced tree for finding free nodes, but I am operating on the assumption that the smallest sufficient region is the best to return from 'alloc'. You are not being any help, Rhodri, in your question. Its chief virtue is fidelity of programming, that is, what you write is most true to what you mean. If you have an object on disk, and want the third element of its 'coords' list attribute, it's a waste to do anything other than find its disk address, then the disk address of its 'coords' attribute, then the disk address of the third element of that, such as say, loading or worse, processing, the entire structure; even if, and in light of parallel considerations about economic market transparency and efficiency, that is to say, economy, maybe / especially/ if, you are having a lowly machine make do. You don't want to open every box in your basement to find your tennis racket; you want to open one box, find the racket in the index, then open all and only the boxes that 'nestedly' contain the racket. (Yes, that's / all/ and /only/, or 'if and only if'-- not to be confused with 'one and only'.) It's more economic. -- http://mail.python.org/mailman/listinfo/python-list