Mailman 3 September 2002 - Python-Dev

Re: ATTENTION! Releasing Python 2.2.2 in a few weeks
by Mats Wichmann 23 Sep '02

23 Sep '02

>Thanks. In addition, I was hoping to hear about your timeline (when >do you expect to release PyTie?) and a hint on the 3rd party packages >you're thinking of adding. Also a list of target platforms for which >PyTie must absolutely work. (Note e.g. that we just discovered a >problem with Solaris and the latest version of binutils (2.13), which >seems to be used by the latest GCC version (3.2 IIRC) but is also >separately downloadable. The bug is in binutils 2.13. Is this >*combination* (Solaris + binutils 2.13) a target platform? If so, you >might want to use a different approach than we plan to do for Python >2.3 and 2.2.2 (which is merely to bail out if a certain test dumps >core during configuration). gcc 3.2 requires binutils 2.12 or better; it doesn't have a specific requirement on 2.13. However the sunfreeware bundle may bump bintuils to 2.13 (I haven't checked what's going on there for a long time). Sadly, the 2.13 release message indicates the purpose is (only) to support a new platform and says nothing about clever little modifications behind the scenes, like changing default linker options so that relocation tables are built differently (sigh).

1 0

Re: [Python-Dev] Re: ATTENTION! Releasing Python 2.2.2 in a few weeks
by Laura Creighton 23 Sep '02

23 Sep '02

> > > > But given your current plan to release in a few weeks, I wonder if my > > task might be better changed from tracing all the changes from the > > last release to 2.2 maintenance, to starting from 2.2 maint and > > seeing if there is something we _don't_ want in, which needs removing. > > I still don't have a good enough perspective to judge this. > > I very much doubt that anything would have crept into 2.2 cvs that we > don't want. Or are you talking from the PBF POV and could they be > more conservative for Py-tie than we've been with 2.2.2? I sure don't think so. But it looks now to me as if the new plan of attack for making a PyTie release is to start with 2.2.2 and then see what absolutely needs to be added to that, as opposed to my old approach, which was to trace from 2.2.1 until 2.3 labelling things that _shouldn't_ be included. Does this make sense, or was my old plan of attack better? > Can you tell us more here about the Py-tie plans? I know nothing > about it except that it'll be based on Python 2.2; I think it would be > helpful for the developer community to know what the long-term Py-tie > plans are. If there is consensus that making Py-Tie out of 2.2.2 plus a list of things that have to be added/fixed, then the thing to do is to start the Snake Farm testing 2.2maints. Then we need to get a list of what software that isn't part of the standard library should be included in PyTie. Then we have to test that against the PyTie candidate. We're working on a way to add that to the snakefarm builds now. The long term plans are to fix serious bugs in the release if they should be discovered, not only in Python but in any third party modules. Also we are working on how to license the whole thing, given that every extra bit has its own particular license. Laura

2 1

Re: ATTENTION! Releasing Python 2.2.2 in a few weeks
by Laura Creighton 23 Sep '02

23 Sep '02

> I'd like to release something called Python 2.2.2 in a few weeks (say, > around Oct 8; I like Tuesday release dates). > > PythonLabs has no time to do a thorough search for all backport/bugfix > candidates in the trunk; if you want to help, the best thing you can > do is take your favorite set of modules or core files and > systematically backport anything that's clearly a bugfix and backports > easily. Or you could simply make sure that your favorite bugfix is > backported. Ah, before you start systemetically backporting, make sure you _announce_ that you are about to do this backporting. Otherwise you will find that your favourite modules are also somebody else's favourite modules and you have both wasted time and made the eventual merge job harder. This is particularily true of people who need to make a idiom change throughout the entire code base -- they will need to modify files which aren't of any particular interest to you. If somebody is in the middle of working on those files in particular when you come through with your idiom change it is very easy for them to overwrite your change, either because it happened in a different part of the file, one that does not have their attention, or because they did not notice that, in addition to the masive refactoring which they got right as part of a backport, they also have to change an idiom. This sort of thing drives release managers nuts. Note: 'I mentioned it on the wiki someplace' is not good enough. Busy people want to get their bugfixes out and in quickly, not participate in a community or create content. Thus the loose structure of a wiki, which is its strength in community building and in building broad-based participation becomes its downfall when you actually want to quickly know what you have to do, get in, and then get out. A page where one lists such things seems a fine compromise, as long as everybody is aware that some people won't be update, or update properly, anyway. I've been reading the 2.2 cvs over the last week, trying to ge my brain around which changes go with which bugs and which features. I have found some patches where what I think happened is that in addition to adding some feature, while somebody was there they decided to fix a little unrelated ugliness at the same time. Now the task is deciding if that ugliness is also a bug. > I know Laura Creighton volunteered to help on behalf of the PBF, but I > don't know how long she'll take, and she can surely use help. OTOH, > if nobody has time, I think it's fine to release what we have in CVS > on the 2.2 maintenance branch (the branch is named release22-maint). I certainly can use help. But given your current plan to release in a few weeks, I wonder if my task might be better changed from tracing all the changes from the last release to 2.2 maintenance, to starting from 2.2 maint and seeing if there is something we _don't_ want in, which needs removing. I still don't have a good enough perspective to judge this. > > Why release now? It's been a while! It'll be almost 6 months since > 2.2.1 was released. There have been a few important bugfixes (e.g. a > crash with ExtensionClasses on Solaris) that have bugged real-world > users. Ah, that doesn't exactly explain why now -- that is in a few weeks -- rather than in one months time, or even now, that is this morning. The only problem I see on my end is if I decide to procede starting with 2.2.2 as the base release for Python-in-a-Tie and then swarms of people show up saying, well, actually I was half way through something when 2.2.2 came out, so for PIT you have to either remove <all of this> stuff or add <all of that>. Is now a quiet time, or do people expect a lot of that to occur? There is nothing like announcing an impending release to get a lot of code out from the woodwork -- so I guess we will find out. > > Why release what we've got? Frankly, I expect that nobody has the > time to backport everything that could reasonably be backported, so if > we wait for that to happen, we'll never have another release. What > we've got is definitely a lot better than 2.2.1. > > What about Python-in-a-tie? Maybe Laura can shed light on the PBF's > schedule for that; I expect it'll be much longer in the making than > the planned 2.2.2 release. It has to be, by definition. We need the Python for people to test their extension modules against before we can package up the extension modules. > > What about Python 2.3? Alpha by the end of 2002 is the best I can > promise. > > What can you do? Here's a brief treatise on backporting bugs that I > sent to Laura earlier: > > Basically, someone does the tedious part of triage, which means > going over *every* 2.3 checkin message (with quick access to the > corresponding diffs) and sorting them into: > > - already applied > > - trivial reject (e.g. new feature or fix for a bug introduced in > 2.3) > > - trivial accept (pure bugfix that applies cleanly to 2.2) > > - messy (e.g. unclear whether it's a bugfix or a feature even > after staring at the source, bugfixes that affect binary > compatibility, bugfixes that can only be applied with much code > wrangling due to other changes in the code at the same place, > etc.) > > Feel free to compile a list of "messy" ones and send it to > python-dev. It doesn't have to be all at once -- for big messy > ones a separate python-dev discussion may be appropriate. > > I think it's best not use the SF trackers to suggest bugs to be > backported -- this would merely be confusing, and it's a pretty heavy > communication mechanism. If you want to help but don't have checkin > permission, find someone who does and work with them -- or we can give > you checkin permission (depending on your reputation). > > --Guido van Rossum (home page: http://www.python.org/~guido/) You also pointed me at Tools/scripts/logmerge.py , which I thought I would mention in case anybody reading here isn't familiar with it. It sorts the messages produced by cvs log by date and time, rather than by file. really useful. Thank you. Laura Creighton

2 1

Weekly Python Bug/Patch Summary
by Skip Montanaro 22 Sep '02

22 Sep '02

Bug/Patch Summary ----------------- 283 open / 2867 total bugs (no change) 106 open / 1698 total patches (-2) New Bugs -------- Mac IDE Browser / ListManager issue (2002-09-16) http://python.org/sf/610149 unicode alphanumeric regexp bug (2002-09-16) http://python.org/sf/610299 SO name is too short! Python 2.2.1 (2002-09-16) http://python.org/sf/610332 linuxaudiodev not documented (2002-09-17) http://python.org/sf/610401 mhlib does not obey MHCONTEXT env var (2002-09-17) http://python.org/sf/610556 Numpy doesn't build for Python.framework (2002-09-17) http://python.org/sf/610730 Lone surrogates cause bad .pyc files (2002-09-17) http://python.org/sf/610783 SMTP.login() uses invalid base64 enc. (2002-09-18) http://python.org/sf/611052 Cannot compile escaped unicode character (2002-09-20) http://python.org/sf/612074 2 bugs in turtle.py (2002-09-21) http://python.org/sf/612595 New Patches ----------- Updated .spec file for 2.2 series. (2002-09-18) http://python.org/sf/611191 select problems on Windows (2002-09-19) http://python.org/sf/611464 zipfile.py reads archives with comments (2002-09-19) http://python.org/sf/611760 quietly select between 'less' and 'more' (2002-09-20) http://python.org/sf/612111 "Bare" text tag_configure in Tkinter (2002-09-21) http://python.org/sf/612602 Allow more Unicode on sys.stdout (2002-09-21) http://python.org/sf/612627 Closed Bugs ----------- bugs in Tix.py ListNoteBook PanedWindow (2001-11-23) http://python.org/sf/484994 multifile different in 2.2 from 2.1.1 (2002-02-07) http://python.org/sf/514676 Sig11 in cPickle (stack overflow) (2002-07-01) http://python.org/sf/576084 Empty genindex.html pages (2002-07-26) http://python.org/sf/586926 defining away __attribute__ is not good (2002-09-08) http://python.org/sf/606493 Problems in IDLE Browsers & Viewers (2002-09-12) http://python.org/sf/608595 test_b1.py, disabling of list test (2002-09-13) http://python.org/sf/609041 cPickle.BadPickleGet is a string (2002-09-13) http://python.org/sf/609164 Closed Patches -------------- Reimplementation of multifile.py (2001-04-04) http://python.org/sf/413766 MSVC Preprocessor (2001-07-15) http://python.org/sf/441528 Setup and distutils changes. (2001-08-21) http://python.org/sf/454041 Extension to Calltips / Show attributes (2002-03-03) http://python.org/sf/525109 PEP 4 update: deprecations (2002-03-18) http://python.org/sf/531491 Support PyChecker in IDLE (2002-04-03) http://python.org/sf/539043 Mac OS X keydefs (2002-09-07) http://python.org/sf/606132 configure on Irix (sockets, posix) (2002-09-13) http://python.org/sf/608999

1 0

Python for OpenVMS
by Skip Montanaro 21 Sep '02

21 Sep '02

FYI, Jean-François Piéronne contacted me a few days with news that he has 2.1.3 running under OpenVMS (I updated question 7.4 of the FAQ to refer to his work). He now has the CVS tree and is working on a port of 2.3. Skip

1 0

Built-in functions, kw args
by Jp Calderone 21 Sep '02

21 Sep '02

>>> ''.split(maxsplit=10) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: split() takes no keyword arguments /usr/src/Python-2.2.1/Objects$ egrep "PyArg_ParseTuple[^A]" *.c | wc -l 73 /usr/src/Python-2.2.1/Objects$ egrep PyArg_ParseTupleAndKeywords *.c | wc -l 16 It looks like the usage of ParseTuple vs ParseTupleAndKeywords is just whatever the author felt like using at the time (to me, anyway). For the sake of consistency at least (and convenience to boot), might it be nice to use PyArg_ParseTupleAndKeywords in more places -- I hesitate to say everywhere, but at least in the places it makes sense? Is there a reason not to do this? Would a patch be accepted that made it so? Jp -- 1:00am up 123 days, 1:54, 3 users, load average: 0.47, 0.54, 0.53

3 2

ATTENTION! Releasing Python 2.2.2 in a few weeks
by Guido van Rossum 20 Sep '02

20 Sep '02

I'd like to release something called Python 2.2.2 in a few weeks (say, around Oct 8; I like Tuesday release dates). PythonLabs has no time to do a thorough search for all backport/bugfix candidates in the trunk; if you want to help, the best thing you can do is take your favorite set of modules or core files and systematically backport anything that's clearly a bugfix and backports easily. Or you could simply make sure that your favorite bugfix is backported. I know Laura Creighton volunteered to help on behalf of the PBF, but I don't know how long she'll take, and she can surely use help. OTOH, if nobody has time, I think it's fine to release what we have in CVS on the 2.2 maintenance branch (the branch is named release22-maint). Why release now? It's been a while! It'll be almost 6 months since 2.2.1 was released. There have been a few important bugfixes (e.g. a crash with ExtensionClasses on Solaris) that have bugged real-world users. Why release what we've got? Frankly, I expect that nobody has the time to backport everything that could reasonably be backported, so if we wait for that to happen, we'll never have another release. What we've got is definitely a lot better than 2.2.1. What about Python-in-a-tie? Maybe Laura can shed light on the PBF's schedule for that; I expect it'll be much longer in the making than the planned 2.2.2 release. What about Python 2.3? Alpha by the end of 2002 is the best I can promise. What can you do? Here's a brief treatise on backporting bugs that I sent to Laura earlier: Basically, someone does the tedious part of triage, which means going over *every* 2.3 checkin message (with quick access to the corresponding diffs) and sorting them into: - already applied - trivial reject (e.g. new feature or fix for a bug introduced in 2.3) - trivial accept (pure bugfix that applies cleanly to 2.2) - messy (e.g. unclear whether it's a bugfix or a feature even after staring at the source, bugfixes that affect binary compatibility, bugfixes that can only be applied with much code wrangling due to other changes in the code at the same place, etc.) Feel free to compile a list of "messy" ones and send it to python-dev. It doesn't have to be all at once -- for big messy ones a separate python-dev discussion may be appropriate. I think it's best not use the SF trackers to suggest bugs to be backported -- this would merely be confusing, and it's a pretty heavy communication mechanism. If you want to help but don't have checkin permission, find someone who does and work with them -- or we can give you checkin permission (depending on your reputation). --Guido van Rossum (home page: http://www.python.org/~guido/)

3 3

Re: Re: mysterious hangs in socket code
by Mats Wichmann 20 Sep '02

20 Sep '02

Martin: >I think that part is already settled: getaddrinfo, on Linux, is >thread-safe. The latest Posix/Single UNIX spec in fact require getaddrinfo (and getnameinfo) to be thread-safe. and Guido: >I tried to read the glibc getaddrinfo() source, but it looks like it >would be a term project... It could be that it's just doing a lot >more interaction with a DNS server. > >I believe that Jeremy suspects that the test program isn't just slow, >but that one slow thread actually blocks all other threads from making >progress. If that's the case (we don't know for sure), we're looking >for a bottleneck in the getaddrinfo() code that somehow holds a >resource needed by all threads calling getaddrinfo(). Gives me a headache, too, especially once it vectors off into the glibc nss code. These routines (__gethostbyname2_r is the likely suspect, __gethostbyaddr_r and __getservbyname_r might also get called) do have paths that could twiddle a glibc internal lock so it's not impossible there's an issue here, although at something less than a term-paper-depth look it doesn't SEEM like it should ever be able to block for very long.

4 3

Installation fails under Solaris 2.7 or 2.8 with binutils 2.13
by Andrew Koenig 20 Sep '02

20 Sep '02

Nick Clifton at Red Hat has been kind enough to figure out for me why I had been unable to install Python on Solaris 2.7 or 2.8 when using binutils 2.13. The problem turns out to be a change in default options with 2.13 that affects dynamic linking. I'm mentioning the problem here in the hope that someone will pick up the patch I've put in with the bug report on Sourceforge (http://sf.net/tracker/?func=detail&aid=596422&group_id=5470&atid=105470) and include it as part of the next Python release.

1 0

Puzzling behavior when subclassing from float
by Charles G Waldman 20 Sep '02

20 Sep '02

Aplogies in advance if this is the wrong forum for this question. I'm trying to understand some puzzling behavior related to subclassing from built-in types. I'm running Python 2.2.1 If I subclass from "dict", it seems that the base class constructor is not being called, which is just as I would expect: class D(dict): def __init__(self, spam, eggs): print "spam=",spam, "eggs=", eggs >>> d = D(1,2) spam= 1 eggs= 2 >>> print d {} But if I subclass from "float", some magic is happening, which I don't quite understand - it seems that the base class constructor *is* called: class F(float): def __init__(self, spam, eggs): print "spam=",spam, "eggs=", eggs >>> f = F(1,2) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: float() takes at most 1 argument (2 given) If I modify the constructor to only take a single argument, I get the following: class F(float): def __init__(self, spam): print "spam=",spam >>> f = F(3.14) spam= 3.14 >>> print f 3.14 >>> print f*2 6.28 How is the value "3.14" getting associated with f? Apparently the base class constructor is called. How come this is happening?

2 1