Mailing List Archive

>>>>> "AMK" == Andrew M Kuchling <akuchlin@mems-exchange.org> writes:

AMK> I suppose this leads to a more important question: at what
AMK> point should we start checking 1.6-only things into the CVS
AMK> tree? For example, once the current alphas of the re module
AMK> are up to it (they're not yet), when should they be checked
AMK> in?

Good question. I've had a bunch of people ask about the string
methods branch, which I'm assuming will be a 1.6 feature, and I'd like
to get that checked in at some point too. I think what's holding this
up is that Guido hasn't decided whether there will be a patch release
to 1.5.2 or not.

-Barry

[Andrew M. Kuchling]
> ...
> I suppose this leads to a more important question: at what point
> should we start checking 1.6-only things into the CVS tree? For
> example, once the current alphas of the re module are up to it
> (they're not yet), when should they be checked in?

I'd like to see a bugfix release of 1.5.2 put out first, then have at it.
There are several bugfixes that ought to go out ASAP. Thread tstate races,
the cpickle/cookie.py snafu, and playing nice with current Tcl/Tk pop to
mind immediately. I'm skeptical that anyone other than Guido could decide
what *needs* to go out, so it's a good thing he's got nothing to do <wink>.

one-boy's-opinion-ly y'rs - tim

[Tim laments]
> mind immediately. I'm skeptical that anyone other than Guido
> could decide
> what *needs* to go out, so it's a good thing he's got nothing
> to do <wink>.

He has been very quiet recently - where are you hiding Guido.

> one-boy's-opinion-ly y'rs - tim

Here is another. Lets take a different tack - what has been checked in
since 1.5.2 that should _not_ go out - ie, is too controversial?

If nothing else, makes a good starting point, and may help Guido out:

Below summary of the CVS diff I just did, and categorized by my opinion.
It turns out that most of the changes would appear candidates. While not
actually "bug-fixes", many have better documentation, removal of unused
imports etc, so would definately not hurt to get out. Looks like some build
issues have been fixed too.

Apart from possibly Tim's recent "UnboundLocalError" (which is the only
serious behaviour change) I can't see anything that should obviously be
ommitted.

Hopefully this is of interest...

[.Disclaimer - lots of files here - it is quite possible I missed
something...]

Mark.


UNCONTROVERSIAL:
----------------
RCS file: /projects/cvsroot/python/dist/src/README,v
RCS file: /projects/cvsroot/python/dist/src/Lib/cgi.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/ftplib.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/poplib.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/re.py,v
RCS file: /projects/cvsroot/python/dist/src/Tools/audiopy/README,v
Doc changes.

RCS file: /projects/cvsroot/python/dist/src/Lib/SimpleHTTPServer.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/cmd.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/htmllib.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/netrc.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/pipes.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/pty.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/shlex.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/urlparse.py,v
Remove unused imports

RCS file: /projects/cvsroot/python/dist/src/Lib/pdb.py,v
Remove unused globals

RCS file: /projects/cvsroot/python/dist/src/Lib/popen2.py,v
Change to cleanup

RCS file: /projects/cvsroot/python/dist/src/Lib/profile.py,v
Remove unused imports and changes to comments.

RCS file: /projects/cvsroot/python/dist/src/Lib/pyclbr.py,v
Better doc, and support for module level functions.

RCS file: /projects/cvsroot/python/dist/src/Lib/repr.py,v
self.maxlist changed to self.maxdict

RCS file: /projects/cvsroot/python/dist/src/Lib/rfc822.py,v
Doc changes, and better date handling.

RCS file: /projects/cvsroot/python/dist/src/configure,v
RCS file: /projects/cvsroot/python/dist/src/configure.in,v
Looks like FreeBSD build flag changes.

RCS file: /projects/cvsroot/python/dist/src/Demo/classes/bitvec.py,v
RCS file: /projects/cvsroot/python/dist/src/Python/pythonrun.c,v
Whitespace fixes.

RCS file: /projects/cvsroot/python/dist/src/Demo/scripts/makedir.py,v
Check we have passed a non empty string

RCS file: /projects/cvsroot/python/dist/src/Include/patchlevel.h,v
1.5.2+

RCS file: /projects/cvsroot/python/dist/src/Lib/BaseHTTPServer.py,v
Remove import rfc822 and more robust errors.

RCS file: /projects/cvsroot/python/dist/src/Lib/CGIHTTPServer.py,v
Support for HTTP_COOKIE

RCS file: /projects/cvsroot/python/dist/src/Lib/fpformat.py,v
NotANumber supports class exceptions.

RCS file: /projects/cvsroot/python/dist/src/Lib/macpath.py,v
Use constants from stat module

RCS file: /projects/cvsroot/python/dist/src/Lib/macurl2path.py,v
Minor changes to path parsing

RCS file: /projects/cvsroot/python/dist/src/Lib/mimetypes.py,v
Recognise '.js': 'application/x-javascript',

RCS file: /projects/cvsroot/python/dist/src/Lib/sunau.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/wave.py,v
Support for binary files.

RCS file: /projects/cvsroot/python/dist/src/Lib/whichdb.py,v
Reads file header to check for bsddb format.

RCS file: /projects/cvsroot/python/dist/src/Lib/xmllib.py,v
XML may be at the start of the string, instead of the whole string.

RCS file: /projects/cvsroot/python/dist/src/Lib/lib-tk/tkSimpleDialog.py,v
Destroy method added.

RCS file: /projects/cvsroot/python/dist/src/Modules/cPickle.c,v
As in the log :-)

RCS file: /projects/cvsroot/python/dist/src/Modules/cStringIO.c,v
No longer a Py_FatalError on module init failure.

RCS file: /projects/cvsroot/python/dist/src/Modules/fpectlmodule.c,v
Support for OSF in #ifdefs

RCS file: /projects/cvsroot/python/dist/src/Modules/makesetup,v
# to handle backslashes for sh's that don't automatically
# continue a read when the last char is a backslash

RCS file: /projects/cvsroot/python/dist/src/Modules/posixmodule.c,v
Better error handling

RCS file: /projects/cvsroot/python/dist/src/Modules/timemodule.c,v
#ifdef changes for __GNU_LIBRARY__/_GLIBC_

RCS file: /projects/cvsroot/python/dist/src/Python/errors.c,v
Better error messages on Win32

RCS file: /projects/cvsroot/python/dist/src/Python/getversion.c,v
Bigger buffer and strings.

RCS file: /projects/cvsroot/python/dist/src/Python/pystate.c,v
Threading bug

RCS file: /projects/cvsroot/python/dist/src/Objects/floatobject.c,v
Tim Peters writes:1. Fixes float divmod etc.

RCS file: /projects/cvsroot/python/dist/src/Objects/listobject.c,v
Doc changes, and When deallocating a list, DECREF the items from the end
back to the start.

RCS file: /projects/cvsroot/python/dist/src/Objects/stringobject.c,v
Bug for to do with width of a formatspecifier

RCS file: /projects/cvsroot/python/dist/src/Objects/tupleobject.c,v
Appropriate overflow checks so that things like sys.maxint*(1,)
can'tdump core.

RCS file: /projects/cvsroot/python/dist/src/Lib/tempfile.py,v
don't cache attributes of type int

RCS file: /projects/cvsroot/python/dist/src/Lib/urllib.py,v
Number of revisions.

RCS file: /projects/cvsroot/python/dist/src/Lib/aifc.py,v
Chunk moved to new module.

RCS file: /projects/cvsroot/python/dist/src/Lib/audiodev.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/dbhash.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/dis.py,v
Changes in comments.

RCS file: /projects/cvsroot/python/dist/src/Lib/cmpcache.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/cmp.py,v
New "shallow" arg.

RCS file: /projects/cvsroot/python/dist/src/Lib/dumbdbm.py,v
Coerce f.tell() to int.

RCS file: /projects/cvsroot/python/dist/src/Modules/main.c,v
Fix to tracebacks off by a line with -x

RCS file: /projects/cvsroot/python/dist/src/Lib/lib-tk/Tkinter.py,v
Number of changes you can review!

OTHERS:
--------

RCS file: /projects/cvsroot/python/dist/src/Lib/asynchat.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/asyncore.py,v
Latest versions from Sam???

RCS file: /projects/cvsroot/python/dist/src/Lib/smtplib.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/sched.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/ConfigParser.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/SocketServer.py,v
RCS file: /projects/cvsroot/python/dist/src/Lib/calendar.py,v Sorry - out
of time to detail

RCS file: /projects/cvsroot/python/dist/src/Python/bltinmodule.c,v
Unbound local, docstring, and better support for ExtensionClasses.

Freeze:
Few changes

IDLE:
Lotsa changes :-)

Number of .h files have #ifdef changes for CE I wont detail (but would be
great to get a few of these in - and I have more :-)

Tools directory:
Number of changes - outa time to detail

Mark Hammond writes:
> Apart from possibly Tim's recent "UnboundLocalError" (which is the only
> serious behaviour change) I can't see anything that should obviously be

Since UnboundLocalError is a subclass of NameError (what you got
before) normally, and they are the same string when -X is used, this
only represents a new name in the __builtin__ module for legacy code.
This should not be a problem; the only real difference is that, using
class exceptions for built-in exceptions, you get more useful
information in your tracebacks.


-Fred

--
Fred L. Drake, Jr. <fdrake@acm.org>
Corporation for National Research Initiatives

> > 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

Fred L. Drake, Jr. writes:
> Do you have documentation for this?

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.

--amk

> 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/)

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

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 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