On Jun 14, 8:24 am, Steven D'Aprano <st...@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. -- http://mail.python.org/mailman/listinfo/python-list
