> Guido van Rossum writes: > >I don't know enough about this, but it seems that there might be two > >steps: *creating* a mmap object is necessarily platform-specific; but > >*using* a mmap object could be platform-neutral. > > > >What is the API for mmap objects? [AMK] > You create them; Unix wants a file descriptor, and Windows wants a > filename. Then they behave like buffer objects, like mutable strings. > > I like Fredrik's suggestion of an 'open(filename, mode, ...)' type of > interface. If someone can suggest a way to handle the extra flags > such as MAP_SHARED and the Windows tag argument, I'll happily > implement it. Maybe just keyword arguments that differ across > platforms? open(filename, mode, [tag = 'foo',] [flags = > mmapfile.MAP_SHARED]). We could preserve the ability to mmap() only a > file descriptor on Unix through a separate openfd() function. Yes, keyword args seem to be the way to go. To avoid an extra function you could add a fileno=... kwarg, in which case the filename is ignored or required to be "". > I'm > also strongly tempted to rename the module from mmapfile to just > 'mmap'. Sure. > I'd suggest waiting until the interface is finalized before adding the > module to the CVS tree -- which means after 1.6a1 -- but I can add the > module as it stands if you like. Guido, let me know if you want me to > do that. Might as well check it in -- the alpha is going to be rough and I expect another alpha to come out shortly to correct the biggest problems. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4