First alpha release of Python 1.6
I'm hoping to release a first, rough alpha of Python 1.6 by April 1st (no joke!). Not everything needs to be finished by then, but I hope to have the current versions of distutil, expat, and sre in there. Anything else that needs to go into 1.6 and isn't ready yet? (Small stuff doesn't matter, everything currently in the patches queue can probably go in if it isn't rejected by then.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Anything else that needs to go into 1.6 and isn't ready yet?
No one seems to have found time to figure out the mmap module support.
I wasn't even aware that that was a priority. If someone submits it, it will go in -- alpha 1 is not a total feature freeze, just a "testing the waters". --Guido van Rossum (home page: http://www.python.org/~guido/)
David Ascher writes:
Anything else that needs to go into 1.6 and isn't ready yet? No one seems to have found time to figure out the mmap module support.
The issue there is cross-platform compatibility; the Windows and Unix versions take completely different constructor arguments, so how should we paper over the differences? Unix arguments: (file descriptor, size, flags, protection) Win32 arguments:(filename, tagname, size) We could just say, "OK, the args are completely different between Win32 and Unix, despite it being the same function name". Maybe that's best, because there seems no way to reconcile those two different sets of arguments. -- A.M. Kuchling http://starship.python.net/crew/amk/ I'm here for the FBI, not the _Weekly World News_. -- Scully in X-FILES #1
Andrew M. Kuchling wrote:
The issue there is cross-platform compatibility; the Windows and Unix versions take completely different constructor arguments, so how should we paper over the differences?
Unix arguments: (file descriptor, size, flags, protection) Win32 arguments:(filename, tagname, size)
We could just say, "OK, the args are completely different between Win32 and Unix, despite it being the same function name". Maybe that's best, because there seems no way to reconcile those two different sets of arguments.
I don't get this. Why expose low-level implementation details to the user (flags, protection, tagname)? (And how come the Windows implementation doesn't support read-only vs. read/write flags?) Unless the current implementation uses something radically different from mmap/MapViewOfFile, wouldn't an interface like: (filename, mode="rb", size=entire file, offset=0) be sufficient? (where mode can be "wb" or "wb+" or "rb+", optionally without the "b") </F>
Fredrik Lundh writes:
(And how come the Windows implementation doesn't support read-only vs. read/write flags?)
Good point; that should be fixed.
(filename, mode="rb", size=entire file, offset=0) be sufficient? (where mode can be "wb" or "wb+" or "rb+", optionally without the "b")
Hmm... maybe we can dispose of the PROT_* argument that way on Unix. But how would you specify MAP_SHARED vs. MAP_PRIVATE, or MAP_ANONYMOUS? (MAP_FIXED seems useless to a Python programmer.) Another character in the mode argument, or a flags argument? Worse, as you pointed out in the same thread, MAP_ANONYMOUS on OSF/1 doesn't want to take a file descriptor at all. Also, the tag name on Windows seems important, from Gordon McMillan's explanation of it: http://www.python.org/pipermail/python-dev/1999-November/002808.html -- A.M. Kuchling http://starship.python.net/crew/amk/ You mustn't kill me. You don't love me. You d-don't even know me. -- The Furies kill Abel, in SANDMAN #66: "The Kindly Ones:10"
The issue there is cross-platform compatibility; the Windows and Unix versions take completely different constructor arguments, so how should we paper over the differences?
Unix arguments: (file descriptor, size, flags, protection) Win32 arguments:(filename, tagname, size)
We could just say, "OK, the args are completely different between Win32 and Unix, despite it being the same function name". Maybe that's best, because there seems no way to reconcile those two different sets of arguments.
I guess my approach would be to provide two platform-specific modules, and to figure out a high-level Python module which could provide a reasonable platform-independent interface on top of it. One problem with that approach is that I think that there is also great value in having a portable mmap interface in the C layer, where i see lots of possible uses in extension modules (much like the threads API). --david
The issue there is cross-platform compatibility; the Windows and Unix versions take completely different constructor arguments, so how should we paper over the differences?
Unix arguments: (file descriptor, size, flags, protection) Win32 arguments:(filename, tagname, size)
We could just say, "OK, the args are completely different between Win32 and Unix, despite it being the same function name". Maybe that's best, because there seems no way to reconcile those two different sets of arguments.
I guess my approach would be to provide two platform-specific modules, and to figure out a high-level Python module which could provide a reasonable platform-independent interface on top of it. One problem with that approach is that I think that there is also great value in having a portable mmap interface in the C layer, where i see lots of possible uses in extension modules (much like the threads API).
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? --Guido van Rossum (home page: http://www.python.org/~guido/)
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?
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. I'm also strongly tempted to rename the module from mmapfile to just 'mmap'. 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. -- A.M. Kuchling http://starship.python.net/crew/amk/ A Puck is harder by far to hurt than some little lord of malice from the lands of ice and snow. We Pucks are old and hard and wild... -- Robin Goodfellow, in SANDMAN #66: "The Kindly Ones:10"
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/)
Guido van Rossum writes:
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.
Done -- just doing my bit to ensure the first alpha is rough! :) My next task is to add the Expat module. My understanding is that it's OK to add Expat itself, too; where should I put all that code? Modules/expat/* ? -- A.M. Kuchling http://starship.python.net/crew/amk/ I'll bring the Kindly Ones down on his blasted head. -- Desire, in SANDMAN #31: "Three Septembers and a January"
Andrew M. Kuchling writes:
Done -- just doing my bit to ensure the first alpha is rough! :)
My next task is to add the Expat module. My understanding is that it's OK to add Expat itself, too; where should I put all that code? Modules/expat/* ?
Do you have documentation for this? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
Andrew M. Kuchling writes:
Somewhere at home, I think, but not here at work. I'll try to get it checked in before 1.6alpha1, but don't hold me to that.
The date isn't important; I'm not planning to match alpha/beta releases with Doc releases. I just want to be sure it gets in soon so that the debugging process can kick in for that as well. ;) Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
Done -- just doing my bit to ensure the first alpha is rough! :)
When the going gets rough, the rough get going :-)
My next task is to add the Expat module. My understanding is that it's OK to add Expat itself, too; where should I put all that code? Modules/expat/* ?
Whoa... Not sure. This will give issues with Patrice, at least (even if it is pure Open Source -- given the size). I'd prefer to add instructions to Setup.in about where to get it. --Guido van Rossum (home page: http://www.python.org/~guido/)
Whoa... Not sure. This will give issues with Patrice, at least (even if it is pure Open Source -- given the size).
For those outside CNRI -- Patrice is CNRI's tough IP lawyer. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, 30 Mar 2000, Guido van Rossum wrote:
Whoa... Not sure. This will give issues with Patrice, at least (even if it is pure Open Source -- given the size).
For those outside CNRI -- Patrice is CNRI's tough IP lawyer.
It was understandable from the context... Personally, I'd rather if it was folded in by value, and not by reference: one reason is versioning problems, and another is pure laziness on my part. what-do-you-have-when-you-got-a-lawyer-up-to-his-neck-in-the-sand-ly y'rs, Z. -- Moshe Zadka <mzadka@geocities.com>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com
Guido van Rossum writes:
My next task is to add the Expat module. My understanding is that it's OK to add Expat itself, too; where should I put all that code? Modules/expat/* ?
Whoa... Not sure. This will give issues with Patrice, at least (even if it is pure Open Source -- given the size). I'd prefer to add instructions to Setup.in about where to get it.
Fair enough; I'll just add the module itself, then, and we can always change it later. Should we consider replacing the makesetup/Setup.in mechanism with a setup.py script that uses the Distutils? You'd have to compile a minipython with just enough critical modules -- strop and posixmodule are probably the most important ones -- in order to run setup.py. It's something I'd like to look at for 1.6, because then you could be much smarter in automatically enabling modules. -- A.M. Kuchling http://starship.python.net/crew/amk/ This is the way of Haskell or Design by Contract of Eiffel. This one is like wearing a XV century armor, you walk very safely but in a very tiring way. -- Manuel Gutierrez Algaba, 26 Jan 2000
Fair enough; I'll just add the module itself, then, and we can always change it later.
OK.
Should we consider replacing the makesetup/Setup.in mechanism with a setup.py script that uses the Distutils? You'd have to compile a minipython with just enough critical modules -- strop and posixmodule are probably the most important ones -- in order to run setup.py. It's something I'd like to look at for 1.6, because then you could be much smarter in automatically enabling modules.
If you can come up with something that works well enough, that would be great. (Although I'm not sure where the distutils come in.) We still need to use configure/autoconf though. Hardcoding a small complement of modules is no problem. (Why do you think you need strop though? Remember we have string methods!) --Guido van Rossum (home page: http://www.python.org/~guido/)
On 30 March 2000, Andrew M. Kuchling said:
Should we consider replacing the makesetup/Setup.in mechanism with a setup.py script that uses the Distutils? You'd have to compile a minipython with just enough critical modules -- strop and posixmodule are probably the most important ones -- in order to run setup.py. It's something I'd like to look at for 1.6, because then you could be much smarter in automatically enabling modules.
Gee, I didn't think anyone was gonna open *that* can of worms for 1.6. Obviously, I'd love to see the Distutils used to build parts of the Python library. Some possible problems: * Distutils relies heavily on the sys, os, string, and re modules, so those would have to be built and included in the mythical mini-python (as would everything they rely on -- strop, pcre, ... ?) * Distutils currently assumes that it's working with an installed Python -- it doesn't know anything about working in the Python source tree. I think this could be fixed just be tweaking the distutils.sysconfig module, but there might be subtle assumptions elsewhere in the code. * I haven't written the mythical Autoconf-in-Python yet, so we'd still have to rely on either the configure script or user intervention to find out whether library X is installed, and where its header and library files live (for X in zlib, tcl, tk, ...). Of course, the configure script would still be needed to build the mini-python, so it's not going away any time soon. Greg
On Fri, 31 Mar 2000, Greg Ward wrote:
Gee, I didn't think anyone was gonna open *that* can of worms for 1.6.
Well, it's not like it's not a lot of work, but it could be done, with liberal interpretation of "mini": include in "mini" Python *all* modules which do not rely on libraries not distributed with the Python core -- zlib, expat and Tkinter go right out the window, but most everything else can stay. That way, Distutils can use all modules it currently uses <wink>. The other problem, file-location, is a problem I have talked about earlier: it *cannot* be assumed that the default place for putting new libraries is the same place the Python interpreter resides, for many reasons. Why not ask the user explicitly? -- Moshe Zadka <mzadka@geocities.com>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com
Greg> * Distutils relies heavily on the sys, os, string, and re Greg> modules, so those would have to be built and included in the Greg> mythical mini-python (as would everything they rely on -- Greg> strop, pcre, ... ?) With string methods in 1.6, reliance on the string and strop modules should be lessened or eliminated, right? re and os may need a tweak or two to use string methods themselves. The sys module is always available. Perhaps it would make sense to put sre(module)?.c into the Python directory where sysmodule.c lives. That way, a Distutils-capable mini-python could be built without messing around in the Modules directory at all... -- Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/
On 31 March 2000, Skip Montanaro said:
With string methods in 1.6, reliance on the string and strop modules should be lessened or eliminated, right? re and os may need a tweak or two to use string methods themselves. The sys module is always available. Perhaps it would make sense to put sre(module)?.c into the Python directory where sysmodule.c lives. That way, a Distutils-capable mini-python could be built without messing around in the Modules directory at all...
But I'm striving to maintain compatability with (at least) Python 1.5.2 in Distutils. That need will fade with time, but it's not going to disappear the moment Python 1.6 is released. (Guess I'll have to find somewhere else to play with string methods and extended call syntax). Greg
Guido van Rossum wrote: ...
Anything else that needs to go into 1.6 and isn't ready yet?
Stackless Python of course, but it *is* ready yet. Just kidding. I will provide a compressed unicode database in a few days. That will be a non-Python-specific module, and (Marc or I) will provide a Python specific wrapper. This will probably not get ready until April 1. ciao - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home
On 28 March 2000, Guido van Rossum said:
I'm hoping to release a first, rough alpha of Python 1.6 by April 1st (no joke!).
Not everything needs to be finished by then, but I hope to have the current versions of distutil, expat, and sre in there.
We just need to do a bit of CVS trickery to put Distutils under the Python tree. I'd *like* for Distutils to have its own CVS existence at least until 1.6 is released, but it's not essential. Two of the big Distutils to-do items that I enumerated at IPC8 have been knocked off: the "dist" command has been completely redone (and renamed "sdist", for "source distribution"), as has the "install" command. The really major to-do items left for Distutils are: * implement the "bdist" command with enough marbles to generate RPMs and some sort of Windows installer (Wise?); Solaris packages, Debian packages, and something for the Mac would be nice too. * documentation (started, but only just) And there are some almost-as-important items: * Mac OS support; this has been started, at least for the unfashionable and clunky sounding MPW compiler; CodeWarrior support (via AppleEvents, I think) would be nice * test suite -- at least the fundamental Distutils marbles should get a good exercise; it would also be nice to put together a bunch of toy module distributions and make sure that "build" and "install" on them do the right things... all automatically, of course! * reduce number of tracebacks: right now, certain errors in the setup script or on the command line can result in a traceback, when they should just result in SystemExit with "error in setup script: ..." or "error on command line: ..." * fold in Finn Bock's JPython compat. patch * fold in Michael Muller's "pkginfo" patch * finish and fold in my Python 1.5.1 compat. patch (only necessary as long as Distutils has a life of its own, outside Python) Well, I'd better get cracking ... Guido, we can do the CVS thing any time; I guess I'll mosey on downstairs. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
participants (9)
-
Andrew M. Kuchling -
Christian Tismer -
David Ascher -
Fred L. Drake, Jr. -
Fredrik Lundh -
Greg Ward -
Guido van Rossum -
Moshe Zadka -
Skip Montanaro