[me]
> > If it works on Linux, Solaris, Irix and Windows, and is reasonably
> > clean, I'll take it. Please send it.
[Greg]
> Actually, my preference is to see a change to open() rather than a whole
> new module. For example, let's say that you open a file, specifying
> memory-mapping. Then you create a buffer against that file:
>
> f = open('foo','rm') # 'm' means mem-map
> b = buffer(f)
> print b[100:200]
Buh. Changes of this kind to builtins are painful, especially since
we expect that this feature may or may not be supported. And imagine
the poor reader who comes across this for the first time...
What's wrong with
import mmap
f = mmap.open('foo', 'r')
???
> I'd like to see mmap native in Python. I won't push, though, until I can
> run a test to see what kind of savings will occur when you mmap a .pyc
> file and open PyBuffer objects against the thing for the code bytes. My
> hypothesis is that you can reduce the working set of Python (i.e. amortize
> the cost of a .pyc's code over several processes by mmap'ing it); this
> depends on the proportion of code in the pyc relative to "other" stuff.
We've been through this before. I still doubt it will help much.
Anyway, it's a completely independent feature from making the mmap
module(any mmap module) available to users.
--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