persistent composites

[Aaron Brady]

On Jun 14, 8:24 am, Steven D'Aprano
<st... at REMOVETHIS.cybersource.com.au> wrote:
> Aaron Brady wrote:
> > Some time ago, I recommended a pursuit of keeping 'persistent
> > composite' types on disk, to be read and updated at other times by
> > other processes.  Databases provide this functionality, with the
> > exception that field types in any given table are required to be
> > uniform.  Python has no such restriction.
> ...
> > I will be sure to kill any interest you might have by now, by
> > "revealing" a snippet of code.
>
> How about telling us what problem you're trying to solve? Giving us your
> implementation isn't useful if we don't even know what it's for. Persistent
> data on disk, okay, I get that -- but how is it different from (say) XML,
> or INI files, or pickles, or similar? Is the idea to have *live* data
> stored on disk, updated by multiple processes simultaneously? Don't assume
> that people will remember your recommendation from "some time ago".
>
> --
> Steven

It was no time at all in the Usenet world, I suppose.  There are lots
of strategies for storing data on a disk, and lots of strategies for
storing data in memory.  I was trying on disk what Python uses on
memory.

If you want to argue that Python isn't useful, you're in the wrong
place.  If you want to argue that Python's strategy is useful on
disks, you're talking to the right person.

I'll draw an analogy.  static data structures : sql & co. :: Python
data structures : this undertaking.  It has all the advantages over
SQL & XML structures that Python has over C structures: sort of a
'worst of neither' combination.  I haven't written a textbook on DSs,
though, so I don't quite know where to begin.  In my eyes, you're
practically asking, "What's your use case for Python?"  Either that,
or I don't know enough other languages.

I have nothing to use it for, but someone might, and it might be just
plumb interesting to fellow Pythoneers.  If I did, I'd have somewhere
to start.