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