[Python-Dev] 2.3b1 release

[Guido van Rossum]

> Jack Jansen <Jack.Jansen@oratrix.com> writes:
> 
> > On donderdag, apr 17, 2003, at 22:17 Europe/Amsterdam, Guido van
> > Rossum wrote:
> > 
> > 
> > >>> I'd like to do a 2.3b1 release someday.  Maybe at the end of next
> > >>> week, that would be Friday April 25.  If anyone has something that
> > >>> needs to be done before this release go out, please let me know!
> > >>
> > >> The getargs mods got checked in just this morning, even though I
> > >> explicitly and rather strongly asked that if these mods be made they
> > >> be checked in *long* before a release was due:-(
> > >
> > > Sorry, I forgot.  Did you make a note of that on the SF patch?
> > 
> > Yes, I'm pretty sure I did. Thomas also seems to refer to it...
> 
> He did, and I also mentioned it yesterday.
> OTOH, I had sitting a first version of the patch on SF for a rather long
> time (shortly after the alpha2 release), asking for feedback, but
> didn't get any.

That was my fault -- I was too busy. :-(

> > >> This means that all the Mac modules are now 100% dead. The same is
> > >> probably true for PyObjC. And PyObjC has the added problem that it
> > >> needs to be compatible with both 2.3b1 and 2.2 (notice that that is
> > >> "2.2", not "2.2.X": PyObjC has to work with /usr/bin/python that
> > >> Apple ships, which is 2.2 at the moment). I assume there are format
> > >> codes that will convert 16 bit and 32 bit integer quantities without
> > >> any checks on both 2.2 and 2.3, but I haven't investigated yet.
> > >
> > > Maybe we should retract the changes to existing format codes that make
> > > them more restrictive?  That should revive any code that's curerntly
> > > dead, right?
> > 
> > That would be much better. if "l" (lower case ell) would continue to
> > accept anything I wouldn't have to change anything.
> 
> Guido has also suggested to keep another code without changes, I cannot
> remember which one it was, but there is a comment on SF.

That was 'h'.

> I have the impression that the new test_getargs2.py test makes it easy
> to change the behaviour and verify it to anything we want.
> 
> In case it is too much trouble, why not backout all this again (although
> someone else would have to do it, I'm basically offline until tuesday), and
> check in after the b1 release.

I'll back out the change to 'h', which is the only incompatible change
I can see (unless you consider accepting *more* than before an error).
Thomas made no changes to 'l', so I'm not sure what that is about --
maybe the problem is with unsigned hex constants?

--Guido van Rossum (home page: http://www.python.org/~guido/)