From drifty@alum.berkeley.edu Tue Jul 1 00:53:33 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Mon, 30 Jun 2003 16:53:33 -0700 Subject: [Python-Dev] release candidate rules and timeit API question Message-ID: <3F00CD7D.2090807@ocf.berkeley.edu> OK, now that I have Internet again I can try to get some Python work done and commit what work I was able to do while I was disconnected. But I noticed that we are now working on a release candidate. Are the commit rules any different than for a beta? I specifically want to commit a patch to make using _strptime for time.strptime permanent by ditching the #ifdef code and flesh out the docs. My timeit API question has to do with timeit.default_timer . The docs don't mention it but I think it might be nice to expose it. The specific I would like to have it available for guaranteed use is that both 'threading' and Queue have code that sleep on an ever-increasing interval. They both use time.time for their time measurements which is fine on UNIX but sucks on Windows when you consider the max time both chunks of code wait is .05 secs which is below the accuracy threshold for Windows (according to Tim's intro in the Cookbook; thank god for books when tech goes kapoot). I would like to edit the code so that it uses what timeit.default_timer is set to. Anyone (especially Guido since he is timeit's original author) have a problem with documenting timeit.default_timer? -Brett From skip@pobox.com Tue Jul 1 01:48:19 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 30 Jun 2003 19:48:19 -0500 Subject: [Python-Dev] release candidate rules and timeit API question In-Reply-To: <3F00CD7D.2090807@ocf.berkeley.edu> References: <3F00CD7D.2090807@ocf.berkeley.edu> Message-ID: <16128.55891.812371.667312@montanaro.dyndns.org> Brett> But I noticed that we are now working on a release candidate. Brett> Are the commit rules any different than for a beta? Essentially, bug fixes only unless approved by Guido I think. Skip From tim.one@comcast.net Tue Jul 1 02:29:30 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 30 Jun 2003 21:29:30 -0400 Subject: [Python-Dev] release candidate rules and timeit API question In-Reply-To: <3F00CD7D.2090807@ocf.berkeley.edu> Message-ID: [Brett] > ... > My timeit API question has to do with timeit.default_timer . The docs > don't mention it but I think it might be nice to expose it. The > specific I would like to have it available for guaranteed use is that > both 'threading' and Queue have code that sleep on an ever-increasing > interval. They both use time.time for their time measurements which > is fine on UNIX but sucks on Windows when you consider the max time > both chunks of code wait is .05 secs which is below the accuracy > threshold for Windows (according to Tim's intro in the Cookbook; > thank god for books when tech goes kapoot). I would like to edit the > code so that it uses what timeit.default_timer is set to. Anyone > (especially Guido since he is timeit's original author) have a > problem with documenting timeit.default_timer? The sleep loop in threading.py is fine as-is: time.time != time.sleep, and there's no problem on Windows sleeping for small bits of time. The coarse granularity of time.time() on Windows only comes into play if the total timeout specified is < about 0.055 seconds, but that's a very small total timeout value (more typical is a total timeout of a full second or more). Queue uses the same polling loop code, and it's also fine there. It's not so fine that this delicate code is duplicated, so I'd rather see an internal refactoring to use a common backoff-polling class. From Wiktor Sadowski" Python module calls PyObject_GenericGetAttr/PyObject_GenericSetAttr pair to do attribute lookup. (moduleobject.c,object.c) IMO it adds unnecessary overhead, and could be replaced with a bit simplified functions. [1] To get an object's dictionary _PyObject_GetDictPtr function is used (inlined in PyObject_GenericGetAttr). But in module case we can get the dictionary without any call: PyObject *dict = ((PyModuleObject *)obj)->md_dict; [2] If module(tp)->tp_dict == NULL PyType_Ready is called in PyObject_GenericGetAttr. Well , I am not sure if all this stuff added to module type with PyType_Ready is really necessary but instead of calling _PyType_Lookup machinery a simple: if (strcmp(PyString_AS_STRING(name/*attr*/),"__dict__")==0) (+ PyErr_SetString(PyExc_TypeError, "readonly attribute") for setattr function) could be used to access readonly module "__dict__" attribute. The solution I am proposing is probably less elegant than PyObject_GenericGetAttr/PyObject_GenericSetAttr but if it could speed up Python a bit ? If someone would like to test such modified modules, binaries for Windows of my small C extension - modeler.pyd are available at: http://www.wiktorsadowski.com/Python Importing modeler will replace module tp_getattro/ tp_setattro with new functions, and will enable faster access to modules' attributes. (if no other modeler features are used) Regards Wiktor Sadowski ___________________________________________________________________ A new getattr for module tp_getattro could look like this: (the settattr could be simplified as well) PyObject * PyObject_ModuleGetAttr(PyObject *obj, PyObject *name) { PyObject *res = NULL; PyTypeObject *tp = obj->ob_type; PyObject *dict = ((PyModuleObject *)obj)->md_dict; /*string check stuff - no changes*/ if (dict == NULL) { /* it shouldn't happen! */ ((PyModuleObject *)obj)->md_dict=Py_DictNew();/*?*/ } if (strcmp(PyString_AS_STRING(name),"__dict__")==0){ Py_INCREF(dict); return dict; } res = PyDict_GetItem(dict, name); if (res != NULL) { Py_INCREF(res); Py_XDECREF(name); return res; } PyErr_Format(PyExc_AttributeError, "'%.50s' object has no attribute '%.400s'", tp->tp_name, PyString_AS_STRING(name)); } From skip@pobox.com Tue Jul 1 03:23:43 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 30 Jun 2003 21:23:43 -0500 Subject: [Python-Dev] release candidate rules and timeit API question In-Reply-To: References: <3F00CD7D.2090807@ocf.berkeley.edu> Message-ID: <16128.61615.288663.112831@montanaro.dyndns.org> Tim> It's not so fine that this delicate code is duplicated, so I'd Tim> rather see an internal refactoring to use a common backoff-polling Tim> class. I recently copied it to my own code as well. I'd like to see it whacked into something reusable. This seems to work: import time class Timeout(Exception): pass def await_condition(predicate, timeout): delay = 0.0005 endtime = time.time() + timeout while True: if predicate(): return remaining = endtime - time.time() if remaining <= 0: # time's up, predicate always failed raise Timeout delay = min(delay * 2, remaining, .05) time.sleep(delay) # reduce CPU usage by using a sleep Skip From python@rcn.com Tue Jul 1 03:44:56 2003 From: python@rcn.com (Raymond Hettinger) Date: Mon, 30 Jun 2003 22:44:56 -0400 Subject: [Python-Dev] release candidate rules and timeit API question References: <3F00CD7D.2090807@ocf.berkeley.edu> Message-ID: <005901c33f7a$c220df00$8c29cb97@oemcomputer> From: "Brett C." Hey, check out the new, cool email address ;-) > But I noticed that we are now working on a release candidate. Are the > commit rules any different than for a beta? I specifically want to > commit a patch to make using _strptime for time.strptime permanent by > ditching the #ifdef code and flesh out the docs. Docs and bugfixes, yes. Anything else, ask GvR if you think it is essential. Raymond Hettinger From drifty@alum.berkeley.edu Tue Jul 1 04:00:09 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Mon, 30 Jun 2003 20:00:09 -0700 Subject: [Python-Dev] cookie support for FancyURLopener? In-Reply-To: References: Message-ID: <3F00F939.8010801@ocf.berkeley.edu> randy.gamage@modicon.com wrote: > Hello, > I have never contributed to the python source, but I am considering adding > cookie support to the FancyURLopener library, especially in the case of a > redirect, in which a cookie is issued with the 302 message, and this cookie > is required to access the new page. > > I thought I would check if this is in progress, or if there are objections > to this idea, before spending any time on it. > Best way to check to see if something is under development is to check SourceForge and see if a patch is up there. And as for objections I doubt there are any if this is how it is supposed to work. -Brett From Raymond Hettinger" Gerrit Holl proposed to remove string exceptions from the tutorial. If you guys okay with it, I'll make the change. Raymond Hettinger From fdrake@acm.org Tue Jul 1 06:40:41 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 1 Jul 2003 01:40:41 -0400 Subject: [Python-Dev] String exceptions in the Tutorial In-Reply-To: <009701c33f92$5a9cb3a0$125ffea9@oemcomputer> References: <009701c33f92$5a9cb3a0$125ffea9@oemcomputer> Message-ID: <16129.7897.959710.959965@grendel.zope.com> Raymond Hettinger writes: > Gerrit Holl proposed to remove string exceptions from the tutorial. > If you guys okay with it, I'll make the change. I'm certainly okay with this! The sooner those are removed, the better. I'd even suggest that the 2.2.x version of the tutorial be updated as well. I'll backport your changes myself if that helps! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From python@rcn.com Tue Jul 1 07:18:24 2003 From: python@rcn.com (Raymond Hettinger) Date: Tue, 1 Jul 2003 02:18:24 -0400 Subject: [Python-Dev] String exceptions in the Tutorial References: <009701c33f92$5a9cb3a0$125ffea9@oemcomputer> <16129.7897.959710.959965@grendel.zope.com> Message-ID: <00b901c33f98$946f3200$125ffea9@oemcomputer> > > Gerrit Holl proposed to remove string exceptions from the tutorial. > > If you guys okay with it, I'll make the change. > > I'm certainly okay with this! The sooner those are removed, the > better. I'd even suggest that the 2.2.x version of the tutorial be > updated as well. I'll backport your changes myself if that helps! Probably no need to backport. Most of it was already done. Gerrit's patch eliminated a copy of tiny remnants. Raymond From drifty@alum.berkeley.edu Tue Jul 1 08:50:55 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 01 Jul 2003 00:50:55 -0700 Subject: [Python-Dev] python-dev Summary for 2003-06-01 through 2003-06-30 Message-ID: <3F013D5F.6030607@ocf.berkeley.edu> Since I decided to just plough through my backlog of emails I figured I=20 might as well do the summary at the same time. Since I managed to=20 actually finish it today I thought I would just send it out now instead=20 of making you guys wait until I got the links put into the summary.=20 This means I have no clue if this will go through reST without errors. The biggest thing about this summary short of the new format for the=20 Quickies is what I discuss in the Summary Announcements: I am formally=20 announcing that I am willing to stop doing the summaries start in=20 September. If no one comes forward to pick up where I left off then I=20 will continue to do a crippled version of the summaries. Personally,=20 though, I would rather like to see some new person who wants to learn=20 about python-dev and hacking on Python come forward and take over. Fail=20 that then just someone take over who is willing to do a good job since I=20 can do a crappy job myself regardless of how much free time I have when=20 I start school. =3D) --------------- python-dev Summary for 2003-06-01 through 2003-06-30 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from June=20 1, 2003 through June 30, 2003. It is intended to inform the wider=20 Python community of on-going developments on the list and to have an=20 archived summary of each thread started on the list. To comment on=20 anything mentioned here, just post to python-list@python.org or=20 `comp.lang.python`_ with a subject line mentioning what you are=20 discussing. All python-dev members are interested in seeing ideas=20 discussed by the community, so don't hesitate to take a stance on=20 something. And if all of this really interests you then get involved=20 and join `python-dev`_! This is the eighteenth/nineteenth summary written by Brett Cannon (has=20 his own room with a door for the first time in his life). All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which=20 can be found at http://docutils.sf.net/rst.html . Any unfamiliar=20 punctuation is probably markup for reST_ (otherwise it is probably=20 regular expression syntax or a typo =3D); you can safely ignore it,=20 although I suggest learning reST; its simple and is accepted for `PEP=20 markup`__. Also, because of the wonders of programs that like to=20 reformat text, I cannot guarantee you will be able to run the text=20 version of this summary through Docutils_ as-is unless it is from the=20 original text file. __ http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found=20 at http://www.python.org/dev/doc/devel/ and should be used when wanting=20 to look up any documentation on something mentioned here. Python PEPs=20 (Python Enhancement Proposals) are located at=20 http://www.python.org/peps/ . To view files in the Python CVS online,=20 go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . .. _python-dev: http://www.python.org/dev/ .. _python-dev mailing list:=20 http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=3Dcomp.lang.pytho= n .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: .. _last summary:=20 http://www.python.org/dev/summary/2003-05-16_2003-05-31.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Summary Announcements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I lost Internet on the morning of June 18 and did not regain it until=20 June 29. Since it was so close to the end of the month I decided to=20 just combine the next summary into this month-long summary. During my Internet blackout that reminded me of the days back when I=20 spent my days playing video games and watching television, my future=20 life as a graduate student began to form. Since I am going to have the=20 joy of taking three upper-division undergraduate courses this upcoming=20 fall semester I don't think I am going to have the time to do the=20 summaries when school starts. At minimum I suspect I will have to cut back on the depth of them since=20 I refuse to put the summaries before hacking on the core (hacking is=20 more fun and I would like to think I can contribute more to Python that=20 way). If you want this job I will be willing to give it up starting in=20 September (I want a full year's worth of summaries behind me before I am=20 willing to pass the torch). But if no one takes it I can probably=20 continue to do them in a rather informal way by summarizing only big=20 threads that I find interesting until someone steps forward to do a=20 good, thorough job. If you *really* want to do the summaries and are interested in taking=20 over starting in September, give me an email at brett@python.org . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D `Descriptor write-up [Draft: Please comment]`__ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D __ Related threads: - `Descriptor write-up [second draft]`__ __ Raymond Hettinger has written an paper on descriptors covering what they=20 are to how to write your own. Since not only are properties class=20 methods, static methods, and 'super' object descriptors (more on the=20 last one later on in this summary) but descriptors are used throughout=20 Python now to create bound objects for functions, methods, etc. It would behoove all serious Python programmers to read=20 http://users.rcn.com/python/download/Descriptor.htm . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D `Where to put the interrupt module?`__ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D __ Not earth-shattering, but to make sure that people know when new things=20 are added to the stdlib I figured I should make this thread have a=20 full-blown summary. Thanks to the development work on IDLEfork_, a new function in the=20 thread module called interrupt_main has been added. It raises=20 KeyboardInterrupt in the main thread of a program. The reason the=20 exception is KeyboardInterrupt and not some new exception is because=20 KeyboardInterrupt is the only asynchronous error in Python. There was discussion of making it much more general, but for now it is=20 going to be kept simple since having a more general version, at this=20 moment, does not seem to be needed. .. _IDLEfork: http://idlefork.sf.net/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D `Can't compile _tkinter.c with Redhat 9`__ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D __ `Red Hat`_, apparently, modified their distribution of Tcl_ so as to=20 support `UCS-4`_ text encoding so that their distribution of Python 2.2=20 could be compiled with UCS-4 support. Problem is that this does not=20 allow Python to compile with UCS-2 support; you **have** to compile with=20 UCS-4 support and not UCS-2 under Red Hat 9 with their custom version of=20 Tcl. Thanks to Martin v. L=F6wis, 2.3 has been modified so that Python compile= d=20 in either UCS-4 or UCS-2 will work with standard Tcl which is UCS-2=20 natively. .. _Red Hat: .. _UCS-4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D `PEP-317`__ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D __ Splintered threads: - `Exception masking/chaining`__ __ A discussion of PEP 317 broke out on python-dev. You can read the PEP=20 for details but it advocated removing string exceptions (they are going=20 to be gone in Python 3) and implicit exception instantiation (that is=20 not changing). The PEP was eventually rejected and has the details of=20 why it was rejected in the end. Part of this discussion forked off to discuss exception masking. The=20 idea came up that it might be nice for an exception to keep a reference=20 to a previous exception that was still uncaught at that point. An=20 example is an exception in the function passed to map; the function gets=20 returned without knowing that it was in map. Masking it wouldn't work=20 though since you then wouldn't know about the error in the function=20 itself. But if there was a way to raise an exception from map that=20 reference the original exception from the function then no information=20 would be lost. Chaining the exceptions together would most likely just=20 be sticking the previous exception in an attribute of the new one. This=20 was all originally discussed `in January=20 `__= =20 and `February=20 > 9 & 1 is 1 (which is the=20 Py_TPFLAGS_HEAPTYPE in C) *and* its metaclass is or a subclass of type. This then spawned a discussion about protocols and interfaces (which was=20 discussed once way back when under the title `type categories`_) since=20 protocols could supposedly allow one to define a protocol for what makes=20 up a 'super' instance. None of this will get into the language (if it=20 ever gets in) until Guido can really think it through and that will be a=20 while. .. _type categories: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D `Details on Python shutting down`__ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D __ What happens while Python is shutting down? Well, it calls Py_Finalize=20 in Python/pythonrun.c . This means that signals are turned off,=20 gc.collect is called, calls PyImport_Cleanup in Python/import.c, and=20 then calls. gc.collect one more time. PyImport_Cleanup is where modules are torn down. __main__ is deleted,=20 then everything but sys and __builtin__, and then sys and __builtin__=20 (in that order). Now "deletion" as mentioned he is setting the module=20 to None in sys.modules, setting all names starting with a single=20 underscore to None in the module, and then all others sans __builtins__ . This is why when you define a __del__ method you need to make sure that=20 all things referenced in it are local; global names in the module will=20 have been set to None by the time the code is called if the object is=20 collected during shutdown and raise an exception. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D `Re: [Python-checkins] python/dist/src/Objectslistobject.c,2.15`__ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D __ list.index now has optional start and end arguments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D `RELEASED: Python 2.3b2`__ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D __ Related threads: - `2.3b2 this weekend`__ - `Python 2.3b2 branch tag created`__ __ __ Title says it all. Big thing with this beta release is the new version=20 of IDLE. As with all betas, please download it and give it a whirl to=20 try to shake out any bugs that need fixing *ASAP*; we are going to aim=20 for an August 1 release date for final thanks to Apple planning to=20 incorporate Python 2.3 into Panther_. .. _Panther: http://www.apple.com/macosx/panther/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D `Re: Activating `-i' from inside a script?`__ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D __ Related threads: - `Delayed `-i'! :-)`__ __ Thanks to Skip Montanaro and someone curious at comp.lang.python_ you=20 can now set the PYTHONINSPECT environment variable to something and then=20 be started into an interactive interpreter if an exception propagates=20 all the way to the end of a program without being caught. =3D=3D=3D=3D=3D=3D=3D=3D Quickies =3D=3D=3D=3D=3D=3D=3D=3D Weekly Python Bug/Patch Summary ------------------------------- - `2003-06-01`__ - `2003-06-08`__ - `2003-06-15`__ - `2003-06-22`__ - `2003-06-29`__ __ __ __ __ __ Do Not Post Bugs to python-dev ------------------------------ Related threads: - `Doc issue http://python.org/doc/2.2/api/iterator.html`__ - `"%%s %s"%"hi"%ho" works here and not there`__ - `IDLE bug?`__ - `Bug with ExtensionClass and __coerce__`__ __ __ __ A good rule-of-thumb to follow is to not post bugs to python-dev. There=20 are exceptions, of course, but that exception pretty much only applies=20 to the Python core developers. Do Not Ask for Help on python-dev --------------------------------- Related threads: - `Python Mega Widgets doubt`__ __ If you need help with Python, post to comp.lang.python_ (which can be=20 reached through python-list@python.org). `BaseHTTPServer parsing`__ --------------------------- __ Code marked as internal to a module in the stdlib means you should not=20 directly reference it in your code lest you are willing to deal with=20 possible future breakage when a refactoring of that module is done. `popen2.py strangeness`__ ------------------------- __ A race condition in popen2 was found and fixed in 2.3 but was not solved=20 in time for 2.2.3 . It has been marked for backporting for 2.2.4 . `timsort?`__ ------------ __ The new sorting algorithm for lists (known affectionately as "timsort"=20 since Tim Peters wrote that tricky piece of code) is a 2.3 feature. But=20 if you would like it for older versions of Python you can get it from=20 http://py-stablesort.sourceforge.net/ . `Mundane dict __setitem__...`__ ------------------------------- __ The hash value for an object in a dictionary is not guaranteed to be=20 done based on identity; having two names set to equal tuples and used as=20 keys will overwrite each other. `Meaning of trailing comma?`__ ------------------------------ __ Improper for python-dev, but Michael Chermside was nice enough to answer=20 the question nonetheless. `test_strptime failed`__ ------------------------ __ A failing test was reported. Follow-up on the thread is still pending. `IDLEfork Re-integration into Python`__ --------------------------------------- __ The new version of IDLE (being developed by the `IDLEfork`_ team) is=20 going to be kept in Lib/idlelib/ . `On Syntax Extensibility (again)`__ ----------------------------------- __ Samuele Pedroni's thoughts on blocks (like thunks) in Python. This goes=20 way back to the `2003-02-01 summary`_ and the `thunks=20 `__=20 summary. .. _2003-02-01 summary:=20 http://www.python.org/dev/summary/2003-02-01_2003-0215.html `The Python interpreter is not fully thread-safe.`__ ---------------------------------------------------- __ It is going to be added to the documentation for threading in the Python=20 core that it does not support free threading. For those of you who=20 aren't familiar with what free threading is (it apparently comes from=20 the Windows programming world), it means that something can be called at=20 any time from any thread. In other words it is thread-safe without=20 requiring any special API. `urllib2 proxy support broken?`__ --------------------------------- __ This was initially covered in the `last summary`_. The broken proxy support in urllib2 has been fixed. `Re: [Python-checkins] python/dist/src/Lib pprint.py`__... ----------------------------------------------------------- __ A patch applied to pprint to try to notice if a type's __repr__ had=20 changed was backed out. `mimetypes.guess_all_extensions()`__ ------------------------------------ __ Now returns the empty list when there are no matching extensions. `[OT] Thank you, python-dev`__ ------------------------------ __ An email from me to python-dev thanking the list for everything they=20 have done since it helped get me into grad school. `Re: [DB-SIG] API suggestion: expose 'quote' method`__ ------------------------------------------------------ __ Email about adding an optional quote function to the Python `DB-API`_ spe= c. .. _DB-API: `Updated 2.3 Release Schedule`__ -------------------------------- __ Don't expect 2.3 final to be released until some time after OSCON (it=20 ends on July 11). `cPickle coredump with 2.3/cvs`__ --------------------------------- __ Someone was having core dump on them thanks to cPickle, but with no one=20 else able to reproduce the problem so it's up to the OP to help solve=20 this one. `Patch to remove eval from csv sniffer`__ ----------------------------------------- __ A patch for the new csv package was questioned since 2.3 is in beta.=20 Guido gave the clear, though, since the chances of people's code being=20 dependent on the package were negligible. `Proposal to drop f_tstate`__ ----------------------------- __ A misunderstanding on the use of the f_tstate value in frames in C code. `Caching of builtins and globals in action`__ --------------------------------------------- __ Samuele Pedroni playing with caching accesses to globals and built-ins. `Two useful patches involving tracebacks`__ ------------------------------------------- __ After discussing a useful patch, the idea of refactoring the cgitb and=20 traceback module for 2.4 came up and seemed to be agreed upon to be a=20 good idea. `PEP-311 operational?`__ ------------------------ __ Someone asking if PEP 311 has been applied. `Can we switch different "byte code interpreters"?`__ ----------------------------------------------------- __ Answer: no. Lesson learned: when you want to start a new thread do not piggyback on=20 an existing one unless it is somehow related. `Sporadic test failures in Lib/test/test_mimetools.py`__ -------------------------------------------------------- __ When writing tests that base results on the time difference between time=20 measurements you *must* make sure that the difference is big enough to=20 be noticed by a platforms time.time function (Windows only measures 10=20 times a second). `porting problems`__ -------------------- __ Someone has gotten Python to run on an XBox and GameCube. =3D) `Python language standard; LSB`__ --------------------------------- __ Python has no "standard"; CPython is as close as you are going to get. `VC 7.1 compiler for key developers - last call!`__ --------------------------------------------------- __ Guido asked for people who wanted a free copy of VC 7.1 to speak up. `PEP280 and my experiment`__ ---------------------------- __ Taking cues from PEP 280, Samuele Pedroni experimented with caching=20 access to builtins and globals and got about a 15% increase. `On the possibility of "optimizing" range() calls in for-loops`__ ----------------------------------------------------------------- __ The idea of optimizing the bytecode for calls to range in 'for' loops is=20 still being thrown around. Alex Martelli, though, pointed out that if=20 you just need to do something a set number of times nothing beats=20 itertools.repeat . `Changes to IDLE`__ ------------------- __ All new bugs and patches in regards to IDLE should go into the Python=20 tracker. `zipfile.py (SF #755031)`__ --------------------------- __ A bug with zipfile was found and subsequently patched. `New PEP: 319`__ ---------------- __ A new PEP on adding a keyword for synchronizing code has been put online. `Py2.3 Todo List`__ ------------------- __ Related threads: - `More work on SRE`__ __ Essentially a discussion as to whether to apply Gustavo Niemeyer's patch=20 to remove the recursion limit from the re module and to add=20 sys.(get|set)defaultsourceencoding functions. The former is in (with=20 help of a coverage tool that comes with gcc and is talked about at=20 https://moin.conectiva.com.br/GustavoNiemeyer/2003-06-19 ) and the=20 latter is to be hashed out at EuroPython_. .. _EuroPython: `Handler.setLevel()`__ ---------------------- __ Misunderstanding over how the method worked. `No Net at home`__ ------------------ __ I lost Internet, as you probably know from the `Summary Announcements`_=20 section, on June 18 and didn't get it back until June 29. `SF CVS hosed?`__ ----------------- __ Usual issues with cvs. Some talk about Subversion_. .. _Subversion: `curses module has_key emulation`__ ----------------------------------- __ Problem with curses was found and a proposed patch at=20 http://www.python.org/sf/759208 has been created. `A vote against dict(keyword=3Dvalue) sugar`__... ----------------------------------------------- __ What the subject says. `Python on dual-processor Macs?`__ ---------------------------------- __ Greg Ewing was worried about a bug he heard about on dual-processor=20 Macs. Jack Jansen said it was solved, though. `Patch 595601`__ ----------------- __ A race condition with files and closing/reading is being worked on at=20 http://www.python.org/sf/595601 . `cookie support for FancyURLopener?`__ -------------------------------------- __ Someone asking if a certain feature was under development. `proposed Tkinter change; any likelihood of acceptance?`__ ---------------------------------------------------------- __ Not for 2.3.0, but maybe for 2.4 or 2.3.1 . `Python hash function`__ ------------------------ __ Damien Morton continues to try to speed up Python, this time by trying=20 to speed up the hashing of strings. `Py2.1`__ --------- __ Backporting a fix all the way to Python 2.1 is only needed if it is=20 really critical. `deprecate dbm module & add bsddb185 module for 2.2`__ ------------------------------------------------------ __ "No" and probably "if you put the effort into it yourself". `OSCON Lightning Talk Proposals still being accepted`__ ------------------------------------------------------- __ If you want to give a lightning talk at OSCON_, read this email. .. _OSCON: `[development doc updates]`__ ----------------------------- __ Just what it says. `Yet more SRE`__ ---------------- __ Gustavo Niemeyer fiddles with the re module some more. `Python 2.3b1, distutils and PEP 263`__ --------------------------------------- __ Bug in Distutils is squashed involving the shebang line. `test_copy_reg failing in 2.3 CVS`__ ------------------------------------ __ Dealt with by a comment. `socket timeouts and httplib`__ ------------------------------- __ Dealt with by adding a specific exception for timeouts. `Embedding Python, threading and scalability`__ ----------------------------------------------- __ David Abrahams redirecting a question to python-dev. `[ANN] SciPy '03 -- The 2nd Annual Python for Scientific Computing=20 Workshop`__ -------------------------------------------------------------------------= ----- __ Title says it all. `Proposed DNS query library`__ ------------------------------ __ Take a look at dnspython_ if you need DNS stuff. .. _dnspython: http://www.dnspython.org `Problems in stdlib before 2.3b2`__ ----------------------------------- __ They are being/have been dealt with. `Running tests on freebsd5`__ ----------------------------- __ ...had two failures. They are being worked on. `threads duplicated on fork() prevent child from terminating properly`__ ------------------------------------------------------------------------ __ Person was told to file a bug report. `Meaty debugging mystery`__ --------------------------- __ ... which Martin v. L=F6wis figured out the basic cause although how it i= s=20 happening is still unknown. `2.3b2 known bugs?`__ --------------------- __ The bugs listed previously at http://www.python.org/2.3/bugs.html have=20 been fixed but two new ones take their place. `Problem with 2.3b2 tarfile?`__ ------------------------------- __ Solaris tar was choking on a *really* long pathname in the stdlib. The=20 pathname will most likely end up being changed to be under 100=20 characters so as to meet the POSIX tarfile format specification. `release candidate rules and timeit API question`__ --------------------------------------------------- __ For a release candidate you shouldn't even add new tests if you can help = it. `A bit faster access to module attributes`__ -------------------------------------------- __ Some suggestions on how to get what the subject says. `String exceptions in the Tutorial`__ ------------------------------------- __ ... are pretty much removed now. From harri.pasanen@trema.com Tue Jul 1 09:08:08 2003 From: harri.pasanen@trema.com (Harri Pasanen) Date: Tue, 1 Jul 2003 10:08:08 +0200 Subject: [Python-Dev] Re: Problem with 2.3b2 tarfile? In-Reply-To: References: <16128.30529.80713.425528@montanaro.dyndns.org> <20030630201510.GB14975@unpythonic.net> Message-ID: <200307011008.08038.harri.pasanen@trema.com> On Monday 30 June 2003 23:19, Fran=E7ois Pinard wrote: > [Jeff Epler] > > > the 100-char limit is traditional? > > Traditional. POSIX extends the limit somewhat, but the rules are > very strange. There are two separated fields in the header, and > whenever the second field is non-empty, a slash is to be _implied_ > between both, so you cannot cut the path string anywhere. > On HP-UX 11.x you hit the same problem than on Solaris, with a bit=20 different error message: bash-2.05a$ /usr/bin/tar xf Python-2.3b2.tar tar: ././@LongLink - cannot create tar: ././@LongLink - cannot create =2E.. I've run into the same problem with our in-house software - my=20 solution was to use HP-UX 11.x tar to create the archive, both GNU=20 tar and posix tar will correctly unpack it. Harri From guido@python.org Tue Jul 1 12:05:43 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 01 Jul 2003 07:05:43 -0400 Subject: [Python-Dev] release candidate rules and timeit API question In-Reply-To: Your message of "Mon, 30 Jun 2003 21:29:30 EDT." References: Message-ID: <200307011105.h61B5hZ13444@pcp02138704pcs.reston01.va.comcast.net> > [Brett] > > ... > > My timeit API question has to do with timeit.default_timer . The docs > > don't mention it but I think it might be nice to expose it. The > > specific I would like to have it available for guaranteed use is that > > both 'threading' and Queue have code that sleep on an ever-increasing > > interval. They both use time.time for their time measurements which > > is fine on UNIX but sucks on Windows when you consider the max time > > both chunks of code wait is .05 secs which is below the accuracy > > threshold for Windows (according to Tim's intro in the Cookbook; > > thank god for books when tech goes kapoot). I would like to edit the > > code so that it uses what timeit.default_timer is set to. Anyone > > (especially Guido since he is timeit's original author) have a > > problem with documenting timeit.default_timer? [Tim] > The sleep loop in threading.py is fine as-is: time.time != time.sleep, and > there's no problem on Windows sleeping for small bits of time. The coarse > granularity of time.time() on Windows only comes into play if the total > timeout specified is < about 0.055 seconds, but that's a very small total > timeout value (more typical is a total timeout of a full second or more). > Queue uses the same polling loop code, and it's also fine there. It's not > so fine that this delicate code is duplicated, so I'd rather see an internal > refactoring to use a common backoff-polling class. Agreed, and I'd rather not expose this from the timeit module (which would be a rather strange place to import this timer from). --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Jul 1 12:10:28 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 01 Jul 2003 07:10:28 -0400 Subject: [Python-Dev] A bit faster access to module attributes In-Reply-To: Your message of "Tue, 01 Jul 2003 03:40:23 +0200." <00ae01c33f71$bf122e80$0201010a@wiktor> References: <00ae01c33f71$bf122e80$0201010a@wiktor> Message-ID: <200307011110.h61BASq13475@pcp02138704pcs.reston01.va.comcast.net> > Python module calls PyObject_GenericGetAttr/PyObject_GenericSetAttr pair > to do attribute lookup. (moduleobject.c,object.c) This was introduced at the time when modules were made subclassable; before then, it looked pretty much like what you propose. > IMO it adds unnecessary overhead, and could be replaced with a bit > simplified functions. Have you found any situation where this particular operation was time-critical? I believe (without thinking it through in detail) that the generic getattr/setattr routines are required in order to support subclassing of modules, which people use. So I think your suggestion cannot work, and I also think it is unnecessary, so I don't believe it is worth the bother. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Jul 1 12:12:11 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 01 Jul 2003 07:12:11 -0400 Subject: [Python-Dev] release candidate rules and timeit API question In-Reply-To: Your message of "Mon, 30 Jun 2003 21:23:43 CDT." <16128.61615.288663.112831@montanaro.dyndns.org> References: <3F00CD7D.2090807@ocf.berkeley.edu> <16128.61615.288663.112831@montanaro.dyndns.org> Message-ID: <200307011112.h61BCBK13492@pcp02138704pcs.reston01.va.comcast.net> > Tim> It's not so fine that this delicate code is duplicated, so I'd > Tim> rather see an internal refactoring to use a common backoff-polling > Tim> class. > > I recently copied it to my own code as well. I'd like to see it whacked > into something reusable. This seems to work: > > import time > class Timeout(Exception): pass > > def await_condition(predicate, timeout): > delay = 0.0005 > endtime = time.time() + timeout > while True: > if predicate(): > return > remaining = endtime - time.time() > if remaining <= 0: # time's up, predicate always failed > raise Timeout > delay = min(delay * 2, remaining, .05) > time.sleep(delay) # reduce CPU usage by using a sleep > > Skip I wonder if the right refactoring wouldn't be to add an acquire with timeout method to the built-in lock type? --Guido van Rossum (home page: http://www.python.org/~guido/) From MAILER-DAEMON@antivirus2.its.rochester.edu Tue Jul 1 14:18:45 2003 From: MAILER-DAEMON@antivirus2.its.rochester.edu (Mail Delivery Subsystem) Date: Tue, 1 Jul 2003 09:18:45 -0400 (EDT) Subject: [Python-Dev] Returned mail: see transcript for details Message-ID: <200307011318.h61DIjav000067@antivirus2.its.rochester.edu> The original message was received at Tue, 1 Jul 2003 09:18:41 -0400 (EDT) from localhost [127.0.0.1] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 ... User unknown) ----- Transcript of session follows ----- ... while talking to mail.rochester.edu.: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) ----- Original message follows ----- Return-Path: Received: from antivirus2.its.rochester.edu (localhost [127.0.0.1]) by antivirus2.its.rochester.edu (8.12.9/8.12.4) with ESMTP id h61DIeav000057 for ; Tue, 1 Jul 2003 09:18:41 -0400 (EDT) Received: from SHAOQING ([61.171.144.200]) by antivirus2.its.rochester.edu (8.12.9/8.12.4) with SMTP id h61DITsM000009 for ; Tue, 1 Jul 2003 09:18:34 -0400 (EDT) Message-Id: <200307011318.h61DITsM000009@antivirus2.its.rochester.edu> From: To: Subject: Re: Application Date: Tue, 1 Jul 2003 21:12:48 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_2B96DA43" This is a multipart message in MIME format --CSmtpMsgPart123X456_000_2B96DA43 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message Found virus WORM_SOBIG.E in file details.pif (in your_details.zip) The uncleanable file your_details.zip is moved to /etc/iscan/virus/virIYAguaaJN. --------------------------------------------------------- --CSmtpMsgPart123X456_000_2B96DA43 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached zip file for details. --CSmtpMsgPart123X456_000_2B96DA43 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message your_details.zip is removed from here because it contains a virus. --------------------------------------------------------- --CSmtpMsgPart123X456_000_2B96DA43-- From mwh@python.net Tue Jul 1 14:21:02 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 01 Jul 2003 14:21:02 +0100 Subject: [Python-Dev] python-dev Summary for 2003-06-01 through 2003-06-30 In-Reply-To: <3F013D5F.6030607@ocf.berkeley.edu> ("Brett C."'s message of "Tue, 01 Jul 2003 00:50:55 -0700") References: <3F013D5F.6030607@ocf.berkeley.edu> Message-ID: <2mbrwes7r5.fsf@starship.python.net> "Brett C." writes: > (I want a full year's worth of summaries behind me before I am > willing to pass the torch). That's twice what I managed! Well done! > ====================================== > `Where to put the interrupt module?`__ > ====================================== [...] > There was discussion of making it much more general, but for now it is > going to be kept simple since having a more general version, at this > moment, does not seem to be needed. This is out of date, as of EuroPython. Cheers, M. -- Some people say that a monkey would bang out the complete works of Shakespeare on a typewriter give an unlimited amount of time. In the meantime, what they would probably produce is a valid sendmail configuration file. -- Nicholas Petreley From fdrake@acm.org Tue Jul 1 14:57:55 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 1 Jul 2003 09:57:55 -0400 Subject: [Python-Dev] String exceptions in the Tutorial In-Reply-To: <00b901c33f98$946f3200$125ffea9@oemcomputer> References: <009701c33f92$5a9cb3a0$125ffea9@oemcomputer> <16129.7897.959710.959965@grendel.zope.com> <00b901c33f98$946f3200$125ffea9@oemcomputer> Message-ID: <16129.37731.996868.926868@grendel.zope.com> Raymond Hettinger writes: > Probably no need to backport. Most of it was already done. > Gerrit's patch eliminated a copy of tiny remnants. Ok, I'll leave it alone then. Thanks! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From Jack.Jansen@cwi.nl Tue Jul 1 15:13:38 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 1 Jul 2003 16:13:38 +0200 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: <200306302155.h5ULtiB27403@odiug.zope.com> Message-ID: <35CD4434-ABCE-11D7-BB47-0030655234CE@cwi.nl> Sorry for the late reply; very busy. On Monday, Jun 30, 2003, at 23:55 Europe/Amsterdam, Guido van Rossum wrote: >> Next check was on the length of things as John had suggested. The >> longest >> component is only 110 characters: >> >> >> ./Mac/OSXResources/app/Resources/English.lproj/Documentation/ >> macpython_ide_tutorial/entering_in_new_window.gif > > This is the culprit. In a "classic" tar file, a filename can be only > 100 characters. (See Lib/tarfile.py. :-) If this is the only culprit it is easy to fix. But we should think of a more general fix for the future. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From sjoerd@acm.org Tue Jul 1 15:45:23 2003 From: sjoerd@acm.org (Sjoerd Mullender) Date: Tue, 01 Jul 2003 16:45:23 +0200 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: <35CD4434-ABCE-11D7-BB47-0030655234CE@cwi.nl> References: <35CD4434-ABCE-11D7-BB47-0030655234CE@cwi.nl> Message-ID: <20030701144524.A90D074D1A@indus.ins.cwi.nl> On Tue, Jul 1 2003 Jack Jansen wrote: > Sorry for the late reply; very busy. > > On Monday, Jun 30, 2003, at 23:55 Europe/Amsterdam, Guido van Rossum > wrote: > > >> Next check was on the length of things as John had suggested. The > >> longest > >> component is only 110 characters: > >> > >> > >> ./Mac/OSXResources/app/Resources/English.lproj/Documentation/ > >> macpython_ide_tutorial/entering_in_new_window.gif > > > > This is the culprit. In a "classic" tar file, a filename can be only > > 100 characters. (See Lib/tarfile.py. :-) > > If this is the only culprit it is easy to fix. While you're at it, can you also fix something else that's been bugging me since I first started using CVS on Windows: Whenever I do a "cvs update" (-dP implied) I get warnings about the "Mac/IDE scripts" directory (this is using Cygwin): $ cd "Mac/IDE scripts"; cvs update ? Hold option to open a script ? Insert file name ? Insert folder name ? Search Python Documentation ? Hack/Remove .pyc files ? Hack/Toolbox Assistant cvs server: Updating . cvs server: Updating Hack cvs server: Updating Widget demos The problem is, Windows doesn't allow multiple periods in file names, and all these file names should end in "...". Not using -d is not a reasonable option. -- Sjoerd Mullender From sismex01@hebmex.com Tue Jul 1 16:02:25 2003 From: sismex01@hebmex.com (sismex01@hebmex.com) Date: Tue, 1 Jul 2003 10:02:25 -0500 Subject: [Python-Dev] Problem with 2.3b2 tarfile? Message-ID: > From: Sjoerd Mullender [mailto:sjoerd@acm.org] > Sent: Martes, 01 de Julio de 2003 09:45 a.m. > > [...snippage...] > > The problem is, Windows doesn't allow multiple periods in file names, > and all these file names should end in "...". > [Opens CMD.EXE window in Win XP] Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\gcordova>dir Volume in drive C has no label. Volume Serial Number is 3029-180A Directory of C:\Documents and Settings\gcordova 11/06/2003 05:43 p.m. . 11/06/2003 05:43 p.m. .. 11/06/2003 05:09 p.m. Start Menu 11/06/2003 05:43 p.m. My Documents 11/06/2003 05:43 p.m. Favorites 11/06/2003 05:09 p.m. Desktop 11/06/2003 06:22 p.m. WINDOWS 24/06/2003 11:27 a.m. 29 pyna.bat 1 File(s) 29 bytes 7 Dir(s) 2,869,043,200 bytes free C:\Documents and Settings\gcordova>ren pyna.bat python.native.bat C:\Documents and Settings\gcordova>dir Volume in drive C has no label. Volume Serial Number is 3029-180A Directory of C:\Documents and Settings\gcordova 11/06/2003 05:43 p.m. . 11/06/2003 05:43 p.m. .. 11/06/2003 05:09 p.m. Start Menu 11/06/2003 05:43 p.m. My Documents 11/06/2003 05:43 p.m. Favorites 11/06/2003 05:09 p.m. Desktop 11/06/2003 06:22 p.m. WINDOWS 24/06/2003 11:27 a.m. 29 python.native.bat 1 File(s) 29 bytes 7 Dir(s) 2,869,043,200 bytes free C:\Documents and Settings\gcordova> [WinNT and it's descendants have no problem using multiple dots in a filename. What version are you having trouble with?] > > Not using -d is not a reasonable option. > > -- Sjoerd Mullender > -gustavo -- Advertencia:La informacion contenida en este mensaje es confidencial y restringida, por lo tanto esta destinada unicamente para el uso de la persona arriba indicada, se le notifica que esta prohibida la difusion de este mensaje. Si ha recibido este mensaje por error, o si hay problemas en la transmision, favor de comunicarse con el remitente. Gracias. From skip@pobox.com Tue Jul 1 14:19:23 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 1 Jul 2003 08:19:23 -0500 Subject: [Python-Dev] release candidate rules and timeit API question In-Reply-To: <200307011112.h61BCBK13492@pcp02138704pcs.reston01.va.comcast.net> References: <3F00CD7D.2090807@ocf.berkeley.edu> <16128.61615.288663.112831@montanaro.dyndns.org> <200307011112.h61BCBK13492@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <16129.35419.572491.717012@montanaro.dyndns.org> Skip> import time Skip> class Timeout(Exception): pass Skip> Skip> def await_condition(predicate, timeout): Skip> delay = 0.0005 Skip> endtime = time.time() + timeout Skip> while True: Skip> if predicate(): Skip> return Skip> remaining = endtime - time.time() Skip> if remaining <= 0: # time's up, predicate always failed Skip> raise Timeout Skip> delay = min(delay * 2, remaining, .05) Skip> time.sleep(delay) # reduce CPU usage by using a sleep Skip> Guido> I wonder if the right refactoring wouldn't be to add an acquire Guido> with timeout method to the built-in lock type? In my case I use await_condition() to gracefully empty a Queue of database connection objects at termination time. def check_conn_pool(self): try: conn = self.conn_pool.get(block=0) except Queue.Empty: pass else: conn.close() self._leftovers.append(conn) return len(self._leftovers) == self.poolsize ... def empty_conn_pool(self, poolname, maxwait): self._leftovers = [] try: await_condition(self.check_conn_pool, maxwait) except Timeout: print "could only find", len(self._leftovers), print "connections for", poolname It's a bit clunky, but I wouldn't be able to use an acquire() with a timeout directly. I'd need a Queue.get with a timeout as well. Besides, wouldn't there be places where this progressive backoff would be useful in non-threaded contexts? Skip From theller@python.net Tue Jul 1 16:13:36 2003 From: theller@python.net (Thomas Heller) Date: Tue, 01 Jul 2003 17:13:36 +0200 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: (sismex's message of "Tue, 1 Jul 2003 10:02:25 -0500") References: Message-ID: <4r26nuu7.fsf@python.net> sismex01@hebmex.com writes: > C:\Documents and Settings\gcordova>ren pyna.bat python.native.bat And now try 'ren python.native.bat pnb...' It seems filenames cannot end with dots. Thomas From sismex01@hebmex.com Tue Jul 1 16:15:38 2003 From: sismex01@hebmex.com (sismex01@hebmex.com) Date: Tue, 1 Jul 2003 10:15:38 -0500 Subject: [Python-Dev] Problem with 2.3b2 tarfile? Message-ID: > From: Thomas Heller [mailto:theller@python.net] > Sent: Martes, 01 de Julio de 2003 10:14 a.m. > > sismex01@hebmex.com writes: > > > C:\Documents and Settings\gcordova>ren pyna.bat python.native.bat > > And now try 'ren python.native.bat pnb...' > > It seems filenames cannot end with dots. > > Thomas > I stand corrected. -gustavo -- Advertencia:La informacion contenida en este mensaje es confidencial y restringida, por lo tanto esta destinada unicamente para el uso de la persona arriba indicada, se le notifica que esta prohibida la difusion de este mensaje. Si ha recibido este mensaje por error, o si hay problemas en la transmision, favor de comunicarse con el remitente. Gracias. From tim.one@comcast.net Tue Jul 1 16:15:35 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 1 Jul 2003 11:15:35 -0400 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: Message-ID: [sismex01@hebmex.com] > ... > [WinNT and it's descendants have no problem using > multiple dots in a filename. What version are you > having trouble with?] Note Sjoerd's and all these file names should end in "..." It's trailing periods. Here on Win2K (cmd.exe): C:\Code>echo fine > abc...def C:\Code>dir/b ab* abc...def C:\Code>echo oops > abc...... C:\Code>dir/b ab* abc abc...def C:\Code>dir/b abc.* abc abc...def C:\Code>dir/b abc..* abc...def C:\Code> This isn't unique to cmdline redirection; e.g., passing 'abc......' as a file name to open() also strips the trailing periods in the filename actually created. From guido@python.org Tue Jul 1 16:49:04 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 01 Jul 2003 11:49:04 -0400 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: Your message of "Tue, 01 Jul 2003 10:02:25 CDT." References: Message-ID: <200307011549.h61Fn4X29202@odiug.zope.com> [Sjoerd] > > The problem is, Windows doesn't allow multiple periods in file names, > > and all these file names should end in "...". [sismex01] > [WinNT and it's descendants have no problem using > multiple dots in a filename. What version are you > having trouble with?] Sjoerd meant: Windows deletes trailing periods in file names. This is a real problem. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Tue Jul 1 16:50:49 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 01 Jul 2003 11:50:49 -0400 Subject: [Python-Dev] release candidate rules and timeit API question In-Reply-To: Your message of "Tue, 01 Jul 2003 08:19:23 CDT." <16129.35419.572491.717012@montanaro.dyndns.org> References: <3F00CD7D.2090807@ocf.berkeley.edu> <16128.61615.288663.112831@montanaro.dyndns.org> <200307011112.h61BCBK13492@pcp02138704pcs.reston01.va.comcast.net> <16129.35419.572491.717012@montanaro.dyndns.org> Message-ID: <200307011550.h61Fon929214@odiug.zope.com> > Guido> I wonder if the right refactoring wouldn't be to add an acquire > Guido> with timeout method to the built-in lock type? [Sjoerd] > In my case I use await_condition() to gracefully empty a Queue of database > connection objects at termination time. [...] > It's a bit clunky, but I wouldn't be able to use an acquire() with a > timeout directly. I'd need a Queue.get with a timeout as well. Yes, but that API change would be useful anyway. > Besides, wouldn't there be places where this progressive backoff > would be useful in non-threaded contexts? Unclear, but it's unclear to me if it really is more readable with a helper function to express the condition passed in rather than just written out explicitly (everyone writes these a little different, and that's just fine with me). --Guido van Rossum (home page: http://www.python.org/~guido/) From mwh@python.net Tue Jul 1 16:31:32 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 01 Jul 2003 16:31:32 +0100 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: ("Tim Peters"'s message of "Tue, 1 Jul 2003 11:15:35 -0400") References: Message-ID: <2my8ziqn57.fsf@starship.python.net> "Tim Peters" writes: > [sismex01@hebmex.com] >> ... >> [WinNT and it's descendants have no problem using >> multiple dots in a filename. What version are you >> having trouble with?] > > Note Sjoerd's > > and all these file names should end in "..." > > It's trailing periods. Here on Win2K (cmd.exe): I know, let's end the filenames with U+2026, HORIZONTAL ELLIPSIS. This will surely create no interoperability problems at all. unhelpfully-ly y'rs, m. -- please realize that the Common Lisp community is more than 40 years old. collectively, the community has already been where every clueless newbie will be going for the next three years. so relax, please. -- Erik Naggum, comp.lang.lisp From Wiktor Sadowski" >>Have you found any situation where this particular operation was >>time-critical? Each time a module's attribute is accessed with: from module import attr or module.attr a routine assigned to module tp->getattro is called (through PyObject_GetAttr, object.c,eval.c). Is it time-critical? As for small Python applications, no. However it probably could help in case of monsters like wxPython or Zope. (improving the applications startup performance as well). >>I believe (without thinking it through in detail) that the generic >>getattr/setattr routines are required in order to support subclassing >>of modules, which people use. Adding tp->tp_dict check->PyType_Ready-call to suggested new getattr/setattr routines wouldn't hurt much so subclassing could/will work, while "regular" modules could still benefit from suggested changes. >>So I think your suggestion cannot work, and I also think it is >>unnecessary, so I don't believe it is worth the bother. It works (tested). I wouldn't bother you otherwise. Well, all this is doable from a C extension module, so yes, modifying moduleobject.c is unnecessary. Sorry for taking your time. Regards, Wiktor http://www.wiktorsadowski.com/Python From guido@python.org Tue Jul 1 17:27:46 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 01 Jul 2003 12:27:46 -0400 Subject: [Python-Dev] A bit faster access to module attributes In-Reply-To: Your message of "Tue, 01 Jul 2003 18:25:51 +0200." <00be01c33fed$73880940$0201010a@wiktor> References: <00be01c33fed$73880940$0201010a@wiktor> Message-ID: <200307011627.h61GRk529722@odiug.zope.com> > >>Have you found any situation where this particular operation was > >>time-critical? > > Each time a module's attribute is accessed with: > from module import attr or module.attr > a routine assigned to module tp->getattro is called (through > PyObject_GetAttr, object.c,eval.c). > > Is it time-critical? As for small Python applications, no. > However it probably could help in case of monsters like wxPython or Zope. > (improving the applications startup performance as well). Doesn't strik me as time-critical. > >>I believe (without thinking it through in detail) that the generic > >>getattr/setattr routines are required in order to support subclassing > >>of modules, which people use. > > Adding tp->tp_dict check->PyType_Ready-call to suggested new > getattr/setattr routines wouldn't hurt much so subclassing could/will work, > while "regular" modules could still benefit from suggested changes. > > >>So I think your suggestion cannot work, and I also think it is > >>unnecessary, so I don't believe it is worth the bother. > > It works (tested). I wouldn't bother you otherwise. > Well, all this is doable from a C extension module, > so yes, modifying moduleobject.c is unnecessary. > Sorry for taking your time. --Guido van Rossum (home page: http://www.python.org/~guido/) From niemeyer@conectiva.com Tue Jul 1 20:48:41 2003 From: niemeyer@conectiva.com (Gustavo Niemeyer) Date: Tue, 1 Jul 2003 16:48:41 -0300 Subject: [Python-Dev] python-dev Summary for 2003-06-01 through 2003-06-30 In-Reply-To: <3F013D5F.6030607@ocf.berkeley.edu> References: <3F013D5F.6030607@ocf.berkeley.edu> Message-ID: <20030701194841.GB3485@ibook> Hello Brett! > Related threads: > - `More work on SRE`__ > > __ > > Essentially a discussion as to whether to apply Gustavo Niemeyer's patch > to remove the recursion limit from the re module and to add > sys.(get|set)defaultsourceencoding functions. The former is in (with > help of a coverage tool that comes with gcc and is talked about at > https://moin.conectiva.com.br/GustavoNiemeyer/2003-06-19 ) and the > latter is to be hashed out at EuroPython_. Notice that while the test changes were included, the SRE recursion patch won't be applied until 2.3 is out, as discussed recently. Thanks for the great work! -- Gustavo Niemeyer http://niemeyer.net From just@letterror.com Tue Jul 1 21:12:24 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 1 Jul 2003 22:12:24 +0200 Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib threading.py,1.37,1.38 In-Reply-To: Message-ID: tim_one@users.sourceforge.net wrote: > Modified Files: > threading.py > Log Message: > Make the classes exposed by threading.py new-style classes. This is > mostly for convenience and to aid debugging. Isn't this asking for trouble, now that the (hopefully) last beta is out? Or is there already a 2.3-final branch? Just From tim.one@comcast.net Tue Jul 1 21:19:38 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 1 Jul 2003 16:19:38 -0400 Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib threading.py,1.37,1.38 In-Reply-To: Message-ID: [Just] >> Modified Files: >> threading.py >> Log Message: >> Make the classes exposed by threading.py new-style classes. This is >> mostly for convenience and to aid debugging. > Isn't this asking for trouble, now that the (hopefully) last beta is > out? Or is there already a 2.3-final branch? Possibly a little, and no. Your brother OK'ed it in advance. From Jack.Jansen@cwi.nl Tue Jul 1 21:34:15 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 1 Jul 2003 22:34:15 +0200 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: <2my8ziqn57.fsf@starship.python.net> References: <2my8ziqn57.fsf@starship.python.net> Message-ID: <61F3070B-AC03-11D7-8DAC-000A27B19B96@cwi.nl> On dinsdag, 1 juli 2003, at 17:31PM, Michael Hudson wrote: > I know, let's end the filenames with U+2026, HORIZONTAL ELLIPSIS. > This will surely create no interoperability problems at all. ROTFL. Let me tell you a bit of history. These filenames are actually the strings that will be used in menu entries. Originally, some of them ended in ellipses (okay, not unicode ellipses, but either MacRoman or Latin-1 ellipses, I can't remember). Then people complained. Then we changed them to "...". Now other people complain. It seems you can't win em all... Sjoerd: why don't you submit a bug report? Please assign it to Just:-) From aahz@pythoncraft.com Tue Jul 1 23:44:14 2003 From: aahz@pythoncraft.com (Aahz) Date: Tue, 1 Jul 2003 18:44:14 -0400 Subject: [Python-Dev] python-dev Summary for 2003-06-01 through 2003-06-30 In-Reply-To: <2mbrwes7r5.fsf@starship.python.net> References: <3F013D5F.6030607@ocf.berkeley.edu> <2mbrwes7r5.fsf@starship.python.net> Message-ID: <20030701224414.GA15964@panix.com> On Tue, Jul 01, 2003, Michael Hudson wrote: > "Brett C." writes: >> >> ====================================== >> `Where to put the interrupt module?`__ >> ====================================== > [...] >> There was discussion of making it much more general, but for now it is >> going to be kept simple since having a more general version, at this >> moment, does not seem to be needed. > > This is out of date, as of EuroPython. Oh? Mind clueing in those of us who weren't there? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. From guido@python.org Wed Jul 2 01:58:30 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 01 Jul 2003 20:58:30 -0400 Subject: [Python-Dev] python-dev Summary for 2003-06-01 through 2003-06-30 In-Reply-To: Your message of "Tue, 01 Jul 2003 18:44:14 EDT." <20030701224414.GA15964@panix.com> References: <3F013D5F.6030607@ocf.berkeley.edu> <2mbrwes7r5.fsf@starship.python.net> <20030701224414.GA15964@panix.com> Message-ID: <200307020058.h620wUW14588@pcp02138704pcs.reston01.va.comcast.net> > > "Brett C." writes: > >> > >> ====================================== > >> `Where to put the interrupt module?`__ > >> ====================================== > > [...] > >> There was discussion of making it much more general, but for now it is > >> going to be kept simple since having a more general version, at this > >> moment, does not seem to be needed. > On Tue, Jul 01, 2003, Michael Hudson wrote: > > This is out of date, as of EuroPython. > > Oh? Mind clueing in those of us who weren't there? > -- > Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ He's referring to the new PyThreadState_SetAsyncExc() API. --Guido van Rossum (home page: http://www.python.org/~guido/) From sjoerd@acm.org Wed Jul 2 08:56:51 2003 From: sjoerd@acm.org (Sjoerd Mullender) Date: Wed, 02 Jul 2003 09:56:51 +0200 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: <61F3070B-AC03-11D7-8DAC-000A27B19B96@cwi.nl> References: <2my8ziqn57.fsf@starship.python.net> <61F3070B-AC03-11D7-8DAC-000A27B19B96@cwi.nl> Message-ID: <20030702075651.7800074D1A@indus.ins.cwi.nl> On Tue, Jul 1 2003 Jack Jansen wrote: > Sjoerd: why don't you submit a bug report? Please assign it to Just:-) Done. -- Sjoerd Mullender From mwh@python.net Wed Jul 2 11:40:14 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 02 Jul 2003 11:40:14 +0100 Subject: [Python-Dev] Problem with 2.3b2 tarfile? In-Reply-To: <61F3070B-AC03-11D7-8DAC-000A27B19B96@cwi.nl> (Jack Jansen's message of "Tue, 1 Jul 2003 22:34:15 +0200") References: <2my8ziqn57.fsf@starship.python.net> <61F3070B-AC03-11D7-8DAC-000A27B19B96@cwi.nl> Message-ID: <2mhe65qkj5.fsf@starship.python.net> Jack Jansen writes: > On dinsdag, 1 juli 2003, at 17:31PM, Michael Hudson wrote: > >> I know, let's end the filenames with U+2026, HORIZONTAL ELLIPSIS. >> This will surely create no interoperability problems at all. > > ROTFL. > > Let me tell you a bit of history. These filenames are actually > the strings that will be used in menu entries. Originally, some > of them ended in ellipses (okay, not unicode ellipses, but either > MacRoman or Latin-1 ellipses, I can't remember). Then people > complained. Then we changed them to "...". Now other people > complain. I didn't *know* this was the history, but I certainly suspected that this was the case (and MacRoman ellipsis *is* U+2026, I don't think there is an ellipsis in Latin-1). > It seems you can't win em all... Surprise! Cheers, M. -- Need to Know is usually an interesting UK digest of things that happened last week or might happen next week. [...] This week, nothing happened, and we don't care. -- NTK Now, 2000-12-29, http://www.ntk.net/ From Onno.Ebbinge@logicacmg.com Wed Jul 2 13:31:40 2003 From: Onno.Ebbinge@logicacmg.com (Ebbinge, Onno) Date: Wed, 2 Jul 2003 13:31:40 +0100 Subject: [Python-Dev] New include statement Message-ID: <718B456A2A03D511A83000D0B7828FA4ABB670@nlxgrn1.nl.logica.com> Wouldn't it be very useful if it would be possible to include C header files so that you could easily access to the local shared libraries (e.g., a .so or .dll)? A simple example: >>> include >>> secs = time.time(None) >>> tm = time.localtime(secs) >>> print 'The time is (ANSI format): %d-%d-%d %d:%d:%d\n' % ( ... tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, ... tm.tm_min, tm.tm_sec) The time is (ANSI format): 2003-7-2 13:52:31 Ok, the standard C time.h is totally not interesting in Python because it has it's own time module, but able to access other (os specific!) shared libraries is very useful! Access to ufs/ufs/quota.h on my FreeBSD box would be very simple this way (instead of wrapping/compiling/etc the whole thing). The new include statement should wrap #define's, struct's, function declarations and such found in the header files in a module object. This would be a _very_ general way to access shared libraries and OS API's. I even think it would dramatically simplify the standard or third party modules for python. But... is this possible? Would it have the big advantages I think it would have? Please CC me in your reply because I'm not on the python-dev list. Sincerely, Onno Ebbinge This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. From jepler@unpythonic.net Wed Jul 2 13:38:04 2003 From: jepler@unpythonic.net (Jeff Epler) Date: Wed, 2 Jul 2003 07:38:04 -0500 Subject: [Python-Dev] New include statement In-Reply-To: <718B456A2A03D511A83000D0B7828FA4ABB670@nlxgrn1.nl.logica.com> References: <718B456A2A03D511A83000D0B7828FA4ABB670@nlxgrn1.nl.logica.com> Message-ID: <20030702123800.GA12217@unpythonic.net> OH MY GOD YOU ARE SO BRILLIANT HOW COME NOBODY THOUGHT OF THIS BEFORE NOW?????!?!!!!///11`/1#~ NO CARRIER From aahz@pythoncraft.com Wed Jul 2 13:50:18 2003 From: aahz@pythoncraft.com (Aahz) Date: Wed, 2 Jul 2003 08:50:18 -0400 Subject: [Python-Dev] New include statement In-Reply-To: <20030702123800.GA12217@unpythonic.net> References: <718B456A2A03D511A83000D0B7828FA4ABB670@nlxgrn1.nl.logica.com> <20030702123800.GA12217@unpythonic.net> Message-ID: <20030702125018.GA10326@panix.com> On Wed, Jul 02, 2003, Jeff Epler wrote: > > OH MY GOD YOU ARE SO BRILLIANT > HOW COME NOBODY THOUGHT OF THIS > BEFORE NOW?????!?!!!!///11`/1#~ > NO CARRIER While that's amusing, let's please keep the tone of python-dev on a professional level. Onno, python-dev is not the place to bring up ideas like this if you're not already familiar with working on the Python project. Please use comp.lang.python instead. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. From anthony@interlink.com.au Wed Jul 2 13:58:23 2003 From: anthony@interlink.com.au (Anthony Baxter) Date: Wed, 02 Jul 2003 22:58:23 +1000 Subject: [Python-Dev] alternate pserver access for python CVS? Message-ID: <200307021258.h62CwNAh012208@localhost.localdomain> SF's pserver CVS is so unreliable of late as to make it almost useless. I wonder if we could do something with taking the nightly tarball of the CVSROOT and installing it on creosote, then making pserver (readonly) access for people who aren't on the list of SF developers for python? Anthony -- Anthony Baxter It's never too late to have a happy childhood. From guido@python.org Wed Jul 2 14:14:34 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 02 Jul 2003 09:14:34 -0400 Subject: [Python-Dev] New include statement In-Reply-To: Your message of "Wed, 02 Jul 2003 07:38:04 CDT." <20030702123800.GA12217@unpythonic.net> References: <718B456A2A03D511A83000D0B7828FA4ABB670@nlxgrn1.nl.logica.com> <20030702123800.GA12217@unpythonic.net> Message-ID: <200307021314.h62DEYF16272@pcp02138704pcs.reston01.va.comcast.net> > OH MY GOD YOU ARE SO BRILLIANT > HOW COME NOBODY THOUGHT OF THIS > BEFORE NOW?????!?!!!!///11`/1#~ > NO CARRIER The idea may have been poorly thought out, but I don't think sarcasm was the right response. Let's make it into a positive learning experience for the kid, okay? Tell him about Swig, and explain the problems with mapping C data types to Python data types. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Jul 2 14:20:40 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 02 Jul 2003 09:20:40 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: Your message of "Wed, 02 Jul 2003 22:58:23 +1000." <200307021258.h62CwNAh012208@localhost.localdomain> References: <200307021258.h62CwNAh012208@localhost.localdomain> Message-ID: <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> > SF's pserver CVS is so unreliable of late as to make it almost useless. > I wonder if we could do something with taking the nightly tarball of the > CVSROOT and installing it on creosote, then making pserver (readonly) > access for people who aren't on the list of SF developers for python? MvL already did something like that. Check the archives. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Wed Jul 2 17:57:03 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 02 Jul 2003 12:57:03 -0400 Subject: [Python-Dev] OSCON lightning talks -- submit yours now! Message-ID: <200307021657.h62Gv3J17192@pcp02138704pcs.reston01.va.comcast.net> We still have a few lightning talk slots open for the Python conference at OSCON (the O'Reilly Open Source Conference, July 7-11 in Portland, Oregon -- http://conferences.oreillynet.com/os2003/ ). A lightning talk is a presentation of no more than 5 minutes (we'll have a gong!) on any subject that you think might interest Python users or developers. The Python lightning talks session is Thursday afternoon (July 10) from 4:30 till 6 pm. To submit your proposal, send email to David Ascher with "lightning" in the subject. He'll be accepting proposals until late in the game (even in person at the conference), but slots will be assigned first-come first-serve, so don't wait too long! If you've never heard of lightning talks, you can find out more information at: http://perl.plover.com/lt/osc2003/lightning-talks.html But ignore the submission informations on that site, just send email to David as explained above. See you in Portland, Guido and David --Guido van Rossum (home page: http://www.python.org/~guido/) From skip@pobox.com Wed Jul 2 21:26:59 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 2 Jul 2003 15:26:59 -0500 Subject: [Python-Dev] va_list redefinition warning Message-ID: <16131.16403.796203.515529@montanaro.dyndns.org> SF is completely down at the moment, otherwise I'd file a bug report. Building 2.3b2 on a Solaris 8 system using gcc 2.95.3 I see many warnings about a redefinition of the va_list macro. Here's one example: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Modules/main.o Modules/main.c In file included from Include/stringobject.h:10, from Include/Python.h:83, from Modules/main.c:3: /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/include/stdarg.h:170: warning: redefinition of `va_list' /usr/include/stdio.h:120: warning: `va_list' previously declared here Is this a problem which the Python installation can solve or do I just need to live with the warnings? The comments in the two header files suggest that stdio.h is the culprit (sort of). In /usr/include/stdio.h I see /* * XPG4 requires that va_list be defined in "as described in * ". ANSI-C and POSIX require that the namespace of * not be polluted with this name. */ In .../stdarg.h I see /* We deliberately do not define va_list when called from stdio.h, because ANSI C says that stdio.h is not supposed to define va_list. stdio.h needs to have access to that data type, but must not use that name. It should use the name __gnuc_va_list, which is safe because it is reserved for the implementation. */ Skip From aleaxit@yahoo.com Wed Jul 2 21:29:29 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Wed, 2 Jul 2003 13:29:29 -0700 (PDT) Subject: [Python-Dev] sys.setcheckinterval doc problems Message-ID: <20030702202929.96112.qmail@web40506.mail.yahoo.com> My only net access at the moment is through a browser, so I can't easily prepare a patch, but I noticed that, while the default check interval in 2.3 is now 100 bytecode instructions, it's still documented as 10 in api/init.tex, lib/libsys.tex and Misc/cheatsheet . As I was checking that, I was struck by the fact that having "write-only" settings is quite an anomaly -- e.g. it makes writing a function that sets the check interval to 0 temporarily, fiddles around a bit, then sets it back to the previous value, a bit of trouble. Now that the check interval is a global variable, is there any problem with making it readable (presumably with a new sys.getcheckinterval() function) as well as writable? [I was of course messing around with the new PyThreadState_SetAsyncExc call, which btw seems to be working just fine, and playing with the check interval as part of that...] Alex From skip@pobox.com Wed Jul 2 22:35:04 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 2 Jul 2003 16:35:04 -0500 Subject: [Python-Dev] sys.setcheckinterval doc problems In-Reply-To: <20030702202929.96112.qmail@web40506.mail.yahoo.com> References: <20030702202929.96112.qmail@web40506.mail.yahoo.com> Message-ID: <16131.20488.25025.765118@montanaro.dyndns.org> Alex> ... I noticed that, while the default check interval in 2.3 is now Alex> 100 bytecode instructions, it's still documented as 10 in Alex> api/init.tex, lib/libsys.tex and Misc/cheatsheet. I'm on it. Thanks for the report, Alex. Skip From postmaster@jackdaw.ecs.soton.ac.uk Thu Jul 3 03:00:56 2003 From: postmaster@jackdaw.ecs.soton.ac.uk (MailScanner) Date: Thu, 3 Jul 2003 03:00:56 +0100 (BST) Subject: [Python-Dev] Warning: E-mail viruses detected Message-ID: <200307030200.DAA03874@jackdaw.ecs.soton.ac.uk> Our virus detector has just been triggered by a message you sent:- To: njl98r@ecs.soton.ac.uk Subject: Re: Movie Date: Thu Jul 3 03:00:55 2003 Any infected parts of the message (your_details.zi) have not been delivered. This message is simply to warn you that your computer system may have a virus present and should be checked. The virus detector said this about the message: Report: your_details.zi was infected by W32/Sobig-E -- MailScanner Email Virus Scanner www.mailscanner.info Mailscanner thanks transtec Computers for their support From mepython@yahoo.com Thu Jul 3 18:01:28 2003 From: mepython@yahoo.com (Samir Patel) Date: Thu, 3 Jul 2003 10:01:28 -0700 (PDT) Subject: [Python-Dev] Questions about python2.3 logging facility Message-ID: <20030703170128.8188.qmail@web41502.mail.yahoo.com> First of all, hats of on logging module in python 2.3. Very elegant... I have 2 questions regarding Handler class in logging: 1. SocketHandler: Can I send plain string instead of pickle binary. This will allow me to send a TCP log message to program written in other programming lang. 2. SMTPHandler: Is there any way to send an email where server requires authentication through logconfig.ini file. I send an email message to myself through logging and SMTPHandler and it works perfect, but if I want to send an email to external email address, I can't do it because replying is not allow. I can do it this in a python program by using ehlo and docmd of smtplib object, but how can I do same thing in loggers' config.ini file. Thanks in advance __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From jack@performancedrivers.com Thu Jul 3 17:58:48 2003 From: jack@performancedrivers.com (Jack Diederich) Date: Thu, 3 Jul 2003 12:58:48 -0400 Subject: [Python-Dev] [fwd] SourceForge status Message-ID: <20030703125848.B1022@localhost.localdomain> as posted to the Bittorrent list, short summary is SF CVS will be hosed until at least August. We've been experiencing pain due to the suboptimal status of CVS on SourceForge recently. Information about it can be found here - https://sourceforge.net/docman/display_doc.php?docid=17790&group_id=1 I've discussed the situation with Jacob Moorman at SourceForge, and it appears that the problems will be fixed in a short enough time frame that it would be more of a pain to move to another CVS than it's worth (although not by a wide margin). -Bram From barry@python.org Thu Jul 3 18:13:21 2003 From: barry@python.org (Barry Warsaw) Date: 03 Jul 2003 13:13:21 -0400 Subject: [Python-Dev] [fwd] SourceForge status In-Reply-To: <20030703125848.B1022@localhost.localdomain> References: <20030703125848.B1022@localhost.localdomain> Message-ID: <1057252401.15443.27.camel@yyz> On Thu, 2003-07-03 at 12:58, Jack Diederich wrote: > as posted to the Bittorrent list, short summary is SF CVS will be hosed until > at least August. Note that apparently this just affects pserver access. cvs-over-ssh isn't affected, which is good because otherwise our Python 2.3 release schedule would be completely shot. -Barry From Bill G" This is a multi-part message in MIME format. ------=_NextPart_873_1F7A_2A83C2CC.CA933C77 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_873_1F7A_2A83C2CC.CA933C77 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22>
This is a must if you have digital cable ... learn mor= e
 
 
If you don't want any more emails= from us, go here
 ------=_NextPart_873_1F7A_2A83C2CC.CA933C77-- From postmaster-smtp-am@msxssc.shell.com Fri Jul 4 09:24:58 2003 From: postmaster-smtp-am@msxssc.shell.com (postmaster-smtp-am@msxssc.shell.com) Date: Fri, 4 Jul 2003 03:24:58 -0500 Subject: [Python-Dev] Delivery Report (failure) for RM186061@shellus.com Message-ID: --BS7cdMeLSCI1n9XBbAdsZVLm9ALsTfII Content-type: text/plain; charset="us-ascii" This report relates to your message: Subject: Re: Application, Message-ID: <200307040818.DAA19383@mailgate1.shellus.com>, To: of Fri, 4 Jul 2003 03:15:21 -0500 Your message was not delivered to RM186061@shellus.com for the following reason: A problem with the message content was found Infected with the W32/Sobig.e@MM virus !!! The header of the original message is at the end --BS7cdMeLSCI1n9XBbAdsZVLm9ALsTfII Content-type: message/delivery-status Reporting-MTA: dns; icsscmh4 Arrival-Date: Fri, 4 Jul 2003 03:24:46 -0500 Final-Recipient: rfc822;RM186061@shellus.com Action: failed Status: 5.6.0 (Infected with the W32/Sobig.e@MM virus !!!) --BS7cdMeLSCI1n9XBbAdsZVLm9ALsTfII Content-type: text/RFC822-Headers Received: from mailgate1.shellus.com (actually dmz116.shell.com) by icsscmh4.shell.com (external) with ESMTP; Fri, 4 Jul 2003 03:24:45 -0500 Received: from MAX (www.gamedesire.com [80.48.20.34]) by mailgate1.shellus.com (8.9.3p2/8.9.3) with ESMTP id DAA19383 for ; Fri, 4 Jul 2003 03:18:15 -0500 (CDT) From: python-dev@python.org Message-Id: <200307040818.DAA19383@mailgate1.shellus.com> To: Subject: Re: Application Date: Fri, 4 Jul 2003 10:15:21 +0200 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0061AE4F" --BS7cdMeLSCI1n9XBbAdsZVLm9ALsTfII-- From cavok@filibusta.crema.unimi.it Fri Jul 4 12:48:38 2003 From: cavok@filibusta.crema.unimi.it (Domenico Andreoli) Date: Fri, 4 Jul 2003 13:48:38 +0200 Subject: [Python-Dev] donating python-crack module Message-ID: <20030704114838.GA18542@filibusta.crema.unimi.it> --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi all, i made the python-crack module, which offers bindings to cracklib2, the famous password cracking library (http://www.crypticide.org/users/alecm/). it works nicely and is fully documented. it is rather little and does not require frequent updates. it works on Python 2.1, 2.2 and 2.3. it is available at http://www.nongnu.org/python-crack/. i'd like to donate it to the Python project, but after a quick search on the python site i didn't find any useful information. please, could you point me in the right direction? best regards domenico andreoli -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/BWmWBneQM6IOvFARAtCUAKCRHZX6urPn7Qt029+tEeeucDzREQCfTKFW Go0UaPHq0yAz3pG0blXHpXo= =gM+q -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From guido@python.org Fri Jul 4 13:45:53 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 04 Jul 2003 08:45:53 -0400 Subject: [Python-Dev] donating python-crack module In-Reply-To: Your message of "Fri, 04 Jul 2003 13:48:38 +0200." <20030704114838.GA18542@filibusta.crema.unimi.it> References: <20030704114838.GA18542@filibusta.crema.unimi.it> Message-ID: <200307041245.h64CjrT21762@pcp02138704pcs.reston01.va.comcast.net> > hi all, > > i made the python-crack module, which offers bindings to cracklib2, the > famous password cracking library (http://www.crypticide.org/users/alecm/). > > it works nicely and is fully documented. it is rather little and does > not require frequent updates. it works on Python 2.1, 2.2 and 2.3. > it is available at http://www.nongnu.org/python-crack/. > > i'd like to donate it to the Python project, but after a quick search > on the python site i didn't find any useful information. > > please, could you point me in the right direction? > > best regards > domenico andreoli > > -----[ Domenico Andreoli, aka cavok > --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc Cracklib seems a useful tool, but IMO it's too specific for inclusion in the standard library. If you're thinking about a copyright assignment to the PSF, I'm not sure what that would buy you (or the PSF). You can just make it available from SourceForge and put an open source license on it. Not the Python license, please -- pick the BSD or MIT license or something else that's sweet, simple and GPL-compatible without being viral (i.e. *don't* use the GPL). Then everyone can enjoy your code. --Guido van Rossum (home page: http://www.python.org/~guido/) From cavok@filibusta.crema.unimi.it Fri Jul 4 14:37:24 2003 From: cavok@filibusta.crema.unimi.it (Domenico Andreoli) Date: Fri, 4 Jul 2003 15:37:24 +0200 Subject: [Python-Dev] donating python-crack module In-Reply-To: <200307041245.h64CjrT21762@pcp02138704pcs.reston01.va.comcast.net> References: <20030704114838.GA18542@filibusta.crema.unimi.it> <200307041245.h64CjrT21762@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <20030704133724.GA13684@filibusta.crema.unimi.it> On Fri, Jul 04, 2003 at 08:45:53AM -0400, Guido van Rossum wrote: > Cracklib seems a useful tool, but IMO it's too specific for inclusion > in the standard library. > ok, this is not a problem > If you're thinking about a copyright assignment to the PSF, I'm not > sure what that would buy you (or the PSF). You can just make it > available from SourceForge and put an open source license on it. Not > the Python license, please -- pick the BSD or MIT license or something > else that's sweet, simple and GPL-compatible without being viral > (i.e. *don't* use the GPL). Then everyone can enjoy your code. > it is already available on savannah, licensed under GPL. what's wrong with GPL? the story about not being usable with non-GPL software? thanks for you response, BDFL :) cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 From aahz@pythoncraft.com Fri Jul 4 15:05:56 2003 From: aahz@pythoncraft.com (Aahz) Date: Fri, 4 Jul 2003 10:05:56 -0400 Subject: [Python-Dev] donating python-crack module In-Reply-To: <20030704133724.GA13684@filibusta.crema.unimi.it> References: <20030704114838.GA18542@filibusta.crema.unimi.it> <200307041245.h64CjrT21762@pcp02138704pcs.reston01.va.comcast.net> <20030704133724.GA13684@filibusta.crema.unimi.it> Message-ID: <20030704140556.GA17052@panix.com> On Fri, Jul 04, 2003, Domenico Andreoli wrote: > > it is already available on savannah, licensed under GPL. what's wrong > with GPL? the story about not being usable with non-GPL software? Exactly. Many people use Python as an embedded language for commercial applications (Paint Shop Pro now probably being the most mainstream example), and they won't be able to use your library if you GPL it. For further discussion of this topic, please go to comp.lang.python. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. From guido@python.org Fri Jul 4 15:28:49 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 04 Jul 2003 10:28:49 -0400 Subject: [Python-Dev] donating python-crack module In-Reply-To: Your message of "Fri, 04 Jul 2003 15:37:24 +0200." <20030704133724.GA13684@filibusta.crema.unimi.it> References: <20030704114838.GA18542@filibusta.crema.unimi.it> <200307041245.h64CjrT21762@pcp02138704pcs.reston01.va.comcast.net> <20030704133724.GA13684@filibusta.crema.unimi.it> Message-ID: <200307041428.h64ESnZ21916@pcp02138704pcs.reston01.va.comcast.net> > it is already available on savannah, licensed under GPL. what's wrong > with GPL? the story about not being usable with non-GPL software? Many businesses prefer not to use GPL software, and I believe that if Python itself had been GPL'ed it would not have become the success it is now. None of the major OS languages (Perl, Python, Tcl) are GPL. But it's up to you, and I know there are dissenting opinions, and I don't want this debate here turning into a flamewar, so I'll leave the choice of license up to you, the author. --Guido van Rossum (home page: http://www.python.org/~guido/) From amaury.forgeotdarc@ubitrade.com Fri Jul 4 16:04:10 2003 From: amaury.forgeotdarc@ubitrade.com (amaury.forgeotdarc@ubitrade.com) Date: Fri, 4 Jul 2003 17:04:10 +0200 Subject: [Python-Dev] Invalid memory read in PyObject_Free Message-ID: Hello, I have a problem with Python 2.3b2 and its new object allocator; it appears when running Python under Purify, and can lead to unpredictable behaviour in the general case. When starting Python_d.exe (2.3b2, Windows 200, MsDev 6, debug build from the PCBuild directory) there are more than 50 messages like "Invalid pointer read", "Unitialized memory read","Free memory read"... even before the interactive prompt appears! Python 2.2 has not this problem. It is the first time that I open Python source code, but here is what I found: All errors are in PyObject_Free and Py_Object_Realloc (in obmalloc.c), while calling the macro ADDRESS_IN_RANGE(p, pool->arenaindex) This seems to occur every time the pointer was allocated outside the memory pool, which happens for non-small requests (>256 bytes). And here is my humble opinion about the cause : if the pointer was malloc'ed outside a pool, then the POOL_ADDR(p) expression is not a valid address in the general case and pool->arenaindex will return unpredictable results ! The ADDRESS_IN_RANGE logic is obviously broken. To detect whether an address belongs to a pool, we could compare all the arenas[i] addresses, but I cannot find a (correct) faster way to do this. Is this a real problem? Should it be corrected? I could have Purify ignore the warning, but it is awful. I remember a bug on SourceForge about a crash on an obscure platform, is it related? -- Amaury Forgeot d'Arc From mwh@python.net Fri Jul 4 16:30:27 2003 From: mwh@python.net (Michael Hudson) Date: Fri, 04 Jul 2003 16:30:27 +0100 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: (amaury.forgeotdarc@ubitrade.com's message of "Fri, 4 Jul 2003 17:04:10 +0200") References: Message-ID: <2madbupawc.fsf@starship.python.net> amaury.forgeotdarc@ubitrade.com writes: > Hello, > > I have a problem with Python 2.3b2 and its new object allocator; > it appears when running Python under Purify, and can lead > to unpredictable behaviour in the general case. This is not new; people have observed the same behaviour under valgrind. > All errors are in PyObject_Free and Py_Object_Realloc (in obmalloc.c), > while calling the macro > ADDRESS_IN_RANGE(p, pool->arenaindex) > > This seems to occur every time the pointer was allocated outside > the memory pool, which happens for non-small requests (>256 bytes). In obmalloc.c there is some code that does not strictly conform to ANSI C. However, I do not believe there have been reports of machines in the wild where this is a problem, and on such platforms there is an easy solution: turn off pymalloc. Cheers, M. -- at any rate, I'm satisfied that not only do they know which end of the pointy thing to hold, but where to poke it for maximum effect. -- Eric The Read, asr, on google.com From antonio.beamud@linkend.com Fri Jul 4 16:56:33 2003 From: antonio.beamud@linkend.com (Antonio Beamud Montero) Date: 04 Jul 2003 17:56:33 +0200 Subject: [Python-Dev] Detect a memory leak Message-ID: <1057334193.756.17.camel@canibal> Hi all: I have a problem with memory leaks and I don't know how to solve it. My app runs like a daemon, and do a intensive xmlrpc use. The problem is than is memory grows and grows and I can't see where the problem is. Al the objects in work space maintains the ref counting in the same values all the time. Can anybody tell me a way to debug this situation? The python version is the SuSE 8.0 version (2.2) compiled with GCC 2.95.3. I'm now testing my soft in Debian Sid... and by now all seems to go ok... Thanks and Greetings -- Antonio Beamud Montero From guido@python.org Fri Jul 4 17:25:21 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 04 Jul 2003 12:25:21 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: Your message of "Fri, 04 Jul 2003 17:04:10 +0200." References: Message-ID: <200307041625.h64GPLc22000@pcp02138704pcs.reston01.va.comcast.net> > Is this a real problem? No, it is caused by the way purify checks things. > Should it be corrected? No. > I could have Purify ignore the warning, but it is awful. If you want to run with purify, that's your best option. > I remember a bug on SourceForge about a crash on an obscure platform, > is it related? No. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@python.org Fri Jul 4 17:27:58 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 04 Jul 2003 12:27:58 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: Your message of "Fri, 04 Jul 2003 16:30:27 BST." <2madbupawc.fsf@starship.python.net> References: <2madbupawc.fsf@starship.python.net> Message-ID: <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> > In obmalloc.c there is some code that does not strictly conform to > ANSI C. True. If we wanted to strictly conform to ANSI C, we couldn't do many things we do. > However, I do not believe there have been reports of machines > in the wild where this is a problem, and on such platforms there is an > easy solution: turn off pymalloc. I think there is talk though to make it impossible to turn off pymalloc in the future (you can still turn it off in Python 2.3). I haven't heard of platforms where turning off pymalloc is required -- unless we hear about those, I expect that for 2.4, pymalloc may no longer be optional. (The reason: maintaining two versions of the same code is a pain, and usually the version that's not selected by default is severely broken after a few releases.) --Guido van Rossum (home page: http://www.python.org/~guido/) From mwh@python.net Fri Jul 4 17:38:36 2003 From: mwh@python.net (Michael Hudson) Date: Fri, 04 Jul 2003 17:38:36 +0100 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> (Guido van Rossum's message of "Fri, 04 Jul 2003 12:27:58 -0400") References: <2madbupawc.fsf@starship.python.net> <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <2m4r22p7qr.fsf@starship.python.net> Guido van Rossum writes: >> In obmalloc.c there is some code that does not strictly conform to >> ANSI C. > > True. If we wanted to strictly conform to ANSI C, we couldn't do many > things we do. Sure, but this one is a little bit more eccentric than the others... >> However, I do not believe there have been reports of machines >> in the wild where this is a problem, and on such platforms there is an >> easy solution: turn off pymalloc. > > I think there is talk though to make it impossible to turn off > pymalloc in the future (you can still turn it off in Python 2.3). > > I haven't heard of platforms where turning off pymalloc is required -- > unless we hear about those, I expect that for 2.4, pymalloc may no > longer be optional. (The reason: maintaining two versions of the same > code is a pain, and usually the version that's not selected by default > is severely broken after a few releases.) Is this a real problem with pymalloc? #ifndef PYMALLOC #define PyObject_Alloc malloc #else ... #endif isn't likely to bitrot that fast. But, whatever, it's no big deal to me. Cheers, M. -- People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system. -- Linus Torvalds From guido@python.org Fri Jul 4 17:43:48 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 04 Jul 2003 12:43:48 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: Your message of "Fri, 04 Jul 2003 17:38:36 BST." <2m4r22p7qr.fsf@starship.python.net> References: <2madbupawc.fsf@starship.python.net> <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> <2m4r22p7qr.fsf@starship.python.net> Message-ID: <200307041643.h64GhmM22077@pcp02138704pcs.reston01.va.comcast.net> > >> In obmalloc.c there is some code that does not strictly conform to > >> ANSI C. > > > > True. If we wanted to strictly conform to ANSI C, we couldn't do many > > things we do. > > Sure, but this one is a little bit more eccentric than the others... Hm... Do you have a suggestion for making the code more ANSI conformant? Surely checking whether an address is within a certain range shouldn't require accessing any out-of-bounds memory? Or am I mistaken about how the offending piece of code works? > > I haven't heard of platforms where turning off pymalloc is required -- > > unless we hear about those, I expect that for 2.4, pymalloc may no > > longer be optional. (The reason: maintaining two versions of the same > > code is a pain, and usually the version that's not selected by default > > is severely broken after a few releases.) > > Is this a real problem with pymalloc? > > #ifndef PYMALLOC > #define PyObject_Alloc malloc > #else > ... > #endif > > isn't likely to bitrot that fast. But, whatever, it's no big deal to > me. If that's all, it probably isn't a big deal. :-) [Doing anything to avoid having to look at the actual code...] --Guido van Rossum (home page: http://www.python.org/~guido/) From mwh@python.net Fri Jul 4 17:51:15 2003 From: mwh@python.net (Michael Hudson) Date: Fri, 04 Jul 2003 17:51:15 +0100 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: <200307041643.h64GhmM22077@pcp02138704pcs.reston01.va.comcast.net> (Guido van Rossum's message of "Fri, 04 Jul 2003 12:43:48 -0400") References: <2madbupawc.fsf@starship.python.net> <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> <2m4r22p7qr.fsf@starship.python.net> <200307041643.h64GhmM22077@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <2my8zensl8.fsf@starship.python.net> Guido van Rossum writes: >> >> In obmalloc.c there is some code that does not strictly conform to >> >> ANSI C. >> > >> > True. If we wanted to strictly conform to ANSI C, we couldn't do many >> > things we do. >> >> Sure, but this one is a little bit more eccentric than the others... > > Hm... Do you have a suggestion for making the code more ANSI > conformant? Surely checking whether an address is within a certain > range shouldn't require accessing any out-of-bounds memory? Or am I > mistaken about how the offending piece of code works? I don't think it's avoidable, or at least Tim doesn't: http://mail.python.org/pipermail/python-dev/2002-July/027114.html >> Is this a real problem with pymalloc? >> >> #ifndef PYMALLOC >> #define PyObject_Alloc malloc >> #else >> ... >> #endif >> >> isn't likely to bitrot that fast. But, whatever, it's no big deal to >> me. > > If that's all, it probably isn't a big deal. :-) > > [Doing anything to avoid having to look at the actual code...] Well, I haven't gone that far either :-) Cheers, M. -- After a heavy night I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc From aahz@pythoncraft.com Fri Jul 4 18:07:09 2003 From: aahz@pythoncraft.com (Aahz) Date: Fri, 4 Jul 2003 13:07:09 -0400 Subject: [Python-Dev] Bad idea: dict(kwargs) Message-ID: <20030704170709.GA25870@panix.com> In http://mail.python.org/pipermail/python-dev/2003-June/036502.html Bengt Richter made a strong argument that dict(kwargs) causes problems for subclasses of dict. There was no response. After thinking about it, I'm forced to agree that this is poor design. Guido, please Pronounce on this officially. I realize that it's a bit late to remove, but you've always expressed distaste for adding features that are easily expressed with a one-liner: def kw_dict(**kwargs): return kwargs -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. From guido@python.org Fri Jul 4 18:39:18 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 04 Jul 2003 13:39:18 -0400 Subject: [Python-Dev] Re: Bad idea: dict(kwargs) In-Reply-To: Your message of "Fri, 04 Jul 2003 13:07:09 EDT." <20030704170709.GA25870@panix.com> References: <20030704170709.GA25870@panix.com> Message-ID: <200307041739.h64HdIX22279@pcp02138704pcs.reston01.va.comcast.net> > In http://mail.python.org/pipermail/python-dev/2003-June/036502.html > Bengt Richter made a strong argument that dict(kwargs) causes problems > for subclasses of dict. There was no response. After thinking about > it, I'm forced to agree that this is poor design. > > Guido, please Pronounce on this officially. I realize that it's a bit > late to remove, but you've always expressed distaste for adding features > that are easily expressed with a one-liner: > > def kw_dict(**kwargs): > return kwargs Rejected. I have already responded to this, but apparently only in private; at the end Bengt agreed with me that there was no need to change the API, and that his reasoning was flawed. (The point is that subclass constructors, unlike regular methods, can have a different signature than the base class constructor.) --Guido van Rossum (home page: http://www.python.org/~guido/) From aahz@pythoncraft.com Fri Jul 4 18:41:53 2003 From: aahz@pythoncraft.com (Aahz) Date: Fri, 4 Jul 2003 13:41:53 -0400 Subject: [Python-Dev] Detect a memory leak In-Reply-To: <1057334193.756.17.camel@canibal> References: <1057334193.756.17.camel@canibal> Message-ID: <20030704174153.GA14353@panix.com> On Fri, Jul 04, 2003, Antonio Beamud Montero wrote: > > I have a problem with memory leaks and I don't know how to solve it. > My app runs like a daemon, and do a intensive xmlrpc use. The problem is > than is memory grows and grows and I can't see where the problem is. > Al the objects in work space maintains the ref counting in the same > values all the time. > Can anybody tell me a way to debug this situation? > > The python version is the SuSE 8.0 version (2.2) compiled with GCC > 2.95.3. It's quite likely the problem is fragmenting memory. Try testing with Python 2.3b2, which uses PyMalloc instead. For further discussion of this issue, please go to comp.lang.python; this is off-topic for this list. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. From tim.one@comcast.net Fri Jul 4 20:53:44 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 4 Jul 2003 15:53:44 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> Message-ID: [Guido] > I think there is talk though to make it impossible to turn off > pymalloc in the future (you can still turn it off in Python 2.3). I haven't heard such talk before. There was talk of making it impossible to compile without cyclic gc, and-- indeed --that was done for 2.3. > I haven't heard of platforms where turning off pymalloc is required -- > unless we hear about those, I expect that for 2.4, pymalloc may no > longer be optional. (The reason: maintaining two versions of the same > code is a pain, and usually the version that's not selected by default > is severely broken after a few releases.) We never build without WITH_PYMALLOC defined anymore, so under the "if it's not tested, it's broken" theory, it's already broken <0.5 wink>. OTOH, there are really only two substantive WITH_PYMALLOC #ifdefs in the codebase, and one of them just surrounds the bulk of the code in obmalloc.c. So as untested features go, I bet this one is less problematic than WITHOUT_COMPLEX (which is tested in many more places!). From guido@python.org Fri Jul 4 21:01:02 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 04 Jul 2003 16:01:02 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: Your message of "Fri, 04 Jul 2003 15:53:44 EDT." References: Message-ID: <200307042001.h64K12e22878@pcp02138704pcs.reston01.va.comcast.net> > [Guido] > > I think there is talk though to make it impossible to turn off > > pymalloc in the future (you can still turn it off in Python 2.3). > > I haven't heard such talk before. There was talk of making it impossible to > compile without cyclic gc, and-- indeed --that was done for 2.3. Oops, I think I may have been confused by that one. > > I haven't heard of platforms where turning off pymalloc is required -- > > unless we hear about those, I expect that for 2.4, pymalloc may no > > longer be optional. (The reason: maintaining two versions of the same > > code is a pain, and usually the version that's not selected by default > > is severely broken after a few releases.) > > We never build without WITH_PYMALLOC defined anymore, so under the "if it's > not tested, it's broken" theory, it's already broken <0.5 wink>. OTOH, > there are really only two substantive WITH_PYMALLOC #ifdefs in the codebase, > and one of them just surrounds the bulk of the code in obmalloc.c. So as > untested features go, I bet this one is less problematic than > WITHOUT_COMPLEX (which is tested in many more places!). OK. --Guido van Rossum (home page: http://www.python.org/~guido/) From tim.one@comcast.net Fri Jul 4 21:25:10 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 4 Jul 2003 16:25:10 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: <200307041643.h64GhmM22077@pcp02138704pcs.reston01.va.comcast.net> Message-ID: [Guido] > Hm... Do you have a suggestion for making the code more ANSI > conformant? Note that it's not possible to write a useful and portable memory allocator in 100% standard ANSI C. This was true even under K&R C's fuzzy rules interpreted in favor of cowboys (see K&R's discussion of malloc in "The C Programming Language"). pymalloc's abuses are mild, as such things go. > Surely checking whether an address is within a certain range shouldn't > require accessing any out-of-bounds memory? "range" doesn't apply, but "ranges" does, as each pymalloc arena is a distinct chunk of memory. The brilliance of the current scheme (whose core trick is due to David Abrahams) is that it delivers a correct result quickly, in constant time, with few branches, in time independent of how many arenas pymalloc has allocated. > Or am I mistaken about how the offending piece of code works? pymalloc assumes that it can (a) losslessly cast a valid address to *some* unsigned integral type; and, (b) also obtain a valid address (in the sense that dereferencing won't blow up) by clearing some number of the low-order bits. Standard C doesn't guarantee that either can be done. There's also a vague assumption that the HW is byte-addressed, although that one has more to do with memory efficiency than with correctness. Vladimir's original code made the same assumptions, but didn't guarantee to deliver a correct result in all cases (and I posted all-Python code at the time that could fool it, triggering problems from overwriting byte code to segfaults). An intermediate version of the code delivered correct results and avoided assumption #b, at the cost of doing a binary search over a sorted list of arena base addresses. It was much slower than the current code, and didn't avoid assumption #a (that lossless casting to some unsigned integral type is possible). Other intermediate versions avoiding #b used binary search with a search finger, and a splay tree, to try to speed searches. They were also much slower -- and much more complicated. We get huge value out of pymalloc on the major HW architectures still surviving, and that's worth enduring some pain. From martin@v.loewis.de Sat Jul 5 09:25:23 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 05 Jul 2003 10:25:23 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> Message-ID: Guido van Rossum writes: > MvL already did something like that. Check the archives. I'm happy to repeat that. A nightly (GMT) tarball of HEAD is at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python.tgz I can't tell for sure what the maximum time lag of this is, as I don't know when SF rolls their CVS snapshots (on which this is based). If anybody can tell me, I'll happily adjust my crontab. Regards, Martin From Jack.Jansen@cwi.nl Sat Jul 5 12:08:50 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sat, 5 Jul 2003 13:08:50 +0200 Subject: [Python-Dev] MacPython 2.3b2 binary installer for MacOSX Message-ID: <0E61B00B-AED9-11D7-961F-000A27B19B96@cwi.nl> a binary installer for MacPython 2.3b2 is available through , or (for the impatient) directly at . This installer gives you a framework-based Python, which has all the normal unix-python functionality, lots of extension modules to interface to technology such as Carbon, Quicktime and AppleScript, plus the IDE, the Package Manager, the ability to create small semi-standalone applications and more. Please try it, and send feedback either straight to me or (preferably) to pythonmac-sig@python.org. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From mal@lemburg.com Sat Jul 5 12:25:09 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 05 Jul 2003 13:25:09 +0200 Subject: [Python-Dev] New include statement In-Reply-To: <718B456A2A03D511A83000D0B7828FA4ABB670@nlxgrn1.nl.logica.com> References: <718B456A2A03D511A83000D0B7828FA4ABB670@nlxgrn1.nl.logica.com> Message-ID: <3F06B595.20703@lemburg.com> Ebbinge, Onno wrote: > Wouldn't it be very useful if it would be possible to include C header > files so that you could easily access to the local shared libraries > (e.g., a .so or .dll)? A simple example: > > >>>>include >>>>secs = time.time(None) >>>>tm = time.localtime(secs) >>>>print 'The time is (ANSI format): %d-%d-%d %d:%d:%d\n' % ( > > ... tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, > ... tm.tm_min, tm.tm_sec) > The time is (ANSI format): 2003-7-2 13:52:31 > > Ok, the standard C time.h is totally not interesting in > Python because it has it's own time module, but able to access > other (os specific!) shared libraries is very useful! Access > to ufs/ufs/quota.h on my FreeBSD box would be very simple > this way (instead of wrapping/compiling/etc the whole thing). > > The new include statement should wrap #define's, struct's, function > declarations and such found in the header files in a module object. > This would be a _very_ general way to access shared libraries and OS > API's. I even think it would dramatically simplify the standard or > third party modules for python. > > But... is this possible? Would it have the big advantages I think > it would have? I think the closest you can get to this is by using Thomas Heller's ctypes extension: http://starship.python.net/crew/theller/ctypes/ Not sure whether it works on FreeBSD. The web page says that it need libffi. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 05 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1 From mal@lemburg.com Sat Jul 5 12:27:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 05 Jul 2003 13:27:02 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <3F06B606.6020801@lemburg.com> Guido van Rossum wrote: >>SF's pserver CVS is so unreliable of late as to make it almost useless. >>I wonder if we could do something with taking the nightly tarball of the >>CVSROOT and installing it on creosote, then making pserver (readonly) >>access for people who aren't on the list of SF developers for python? > > MvL already did something like that. Check the archives. Just a thought, not sure whether it's even possible (being no CVS expert): wouldn't it be possible to setup a caching CVS proxy on a more reliable machine, e.g. the python.org one ? -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 05 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1 From martin@v.loewis.de Sat Jul 5 12:38:54 2003 From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 05 Jul 2003 13:38:54 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <3F06B606.6020801@lemburg.com> References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> <3F06B606.6020801@lemburg.com> Message-ID: <3F06B8CE.5070303@v.loewis.de> M.-A. Lemburg wrote: > Just a thought, not sure whether it's even possible (being no CVS > expert): wouldn't it be possible to setup a caching CVS proxy on > a more reliable machine, e.g. the python.org one ? Not trivially. To set up a CVS *mirror*, you need to get access to the repository files - you can't download the entire repository over the CVS protocol (atleast not trivially). To set-up a CVS *proxy*, one would either need to use pserver or ssh forwarding. However, there is no point in doing so: the proxy would have to forward each request, anyway, as it couldn't know whether the repository has changed behind it. In either case, some developer probably would need to deposit the SF password or SSH private key on python.org, which is also undesirable. Regards, Martin From guido@python.org Sat Jul 5 14:41:21 2003 From: guido@python.org (Guido van Rossum) Date: Sat, 05 Jul 2003 09:41:21 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: Your message of "Sat, 05 Jul 2003 13:27:02 +0200." <3F06B606.6020801@lemburg.com> References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> <3F06B606.6020801@lemburg.com> Message-ID: <200307051341.h65DfL424101@pcp02138704pcs.reston01.va.comcast.net> > Just a thought, not sure whether it's even possible (being no CVS > expert): wouldn't it be possible to setup a caching CVS proxy on > a more reliable machine, e.g. the python.org one ? Im no CVS expert either, but I doubt that's at all possible without access to the back-end store used for the repository. --Guido van Rossum (home page: http://www.python.org/~guido/) From aahz@pythoncraft.com Sat Jul 5 14:52:24 2003 From: aahz@pythoncraft.com (Aahz) Date: Sat, 5 Jul 2003 09:52:24 -0400 Subject: [Python-Dev] Daily CVS snapshot (was Re: alternate pserver access for python CVS?) In-Reply-To: References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <20030705135224.GA15944@panix.com> On Sat, Jul 05, 2003, Martin v. L=F6wis wrote: >=20 > I'm happy to repeat that. A nightly (GMT) tarball of HEAD is at >=20 > http://www.dcl.hpi.uni-potsdam.de/home/loewis/python.tgz How would you feel about posting this link on http://www.python.org/dev/tools.html or even http://www.python.org/dev/ Hmmmm..... Looking at the latter page, I find a link "Daily snapshots of the Python source tree", which points at http://cvs.perl.org/snapshots/python/ Should we keep both links active? --=20 Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.= com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. =20 From martin@v.loewis.de Sat Jul 5 15:55:38 2003 From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 05 Jul 2003 16:55:38 +0200 Subject: [Python-Dev] Daily CVS snapshot (was Re: alternate pserver access for python CVS?) In-Reply-To: <20030705135224.GA15944@panix.com> References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> <20030705135224.GA15944@panix.com> Message-ID: <3F06E6EA.2030101@v.loewis.de> Aahz wrote: > How would you feel about posting this link on > http://www.python.org/dev/tools.html > or even > http://www.python.org/dev/ > > Hmmmm..... Looking at the latter page, I find a link "Daily snapshots > of the Python source tree", which points at > http://cvs.perl.org/snapshots/python/ > > Should we keep both links active? Does anybody know how the cvs.perl.org snapshot is generated? In any case, Matthias asked me to produce a tarball of the 2.2 branch as well, and I'll add one for the 2.3 branch when that is created, too, so I'm ready to continue the service for some time (until local disk space limitations force me to shut it down). I'll add a number of links to the web page when I'm done. Regards, Martin From aahz@pythoncraft.com Sat Jul 5 15:58:31 2003 From: aahz@pythoncraft.com (Aahz) Date: Sat, 5 Jul 2003 10:58:31 -0400 Subject: [Python-Dev] Daily CVS snapshot (was Re: alternate pserver access for python CVS?) In-Reply-To: <3F06E6EA.2030101@v.loewis.de> References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> <20030705135224.GA15944@panix.com> <3F06E6EA.2030101@v.loewis.de> Message-ID: <20030705145831.GA14919@panix.com> On Sat, Jul 05, 2003, "Martin v. L=F6wis" wrote: > > I'll add a number of links to the web page when I'm done. Thanks! --=20 Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.= com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. =20 From neal@metaslash.com Sat Jul 5 17:01:28 2003 From: neal@metaslash.com (Neal Norwitz) Date: Sat, 5 Jul 2003 12:01:28 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: References: <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <20030705160127.GI1237@epoch.metaslash.com> On Fri, Jul 04, 2003 at 03:53:44PM -0400, Tim Peters wrote: > [Guido] > > I haven't heard of platforms where turning off pymalloc is required -- > > unless we hear about those, I expect that for 2.4, pymalloc may no > > longer be optional. (The reason: maintaining two versions of the same > > code is a pain, and usually the version that's not selected by default > > is severely broken after a few releases.) > > We never build without WITH_PYMALLOC defined anymore, so under the "if it's > not tested, it's broken" theory, it's already broken <0.5 wink>. OTOH, > there are really only two substantive WITH_PYMALLOC #ifdefs in the codebase, > and one of them just surrounds the bulk of the code in obmalloc.c. So as > untested features go, I bet this one is less problematic than > WITHOUT_COMPLEX (which is tested in many more places!). Depends on your definition of we. :-) I never got around to submitting the attached patch which makes it easier and safer to use memory testing tools such as Purify and Valgrind. The suppression then only needs to be applied to ADDRESS_IN_RANGE. I haven't noticed a problem with pymalloc on Linux, Solaris, Tru64, AIX, HP-UX, FreeBSD. So far there haven't seemed to be any problems with pymalloc. Somtimes, there are benefits to turning off pymalloc from time to time in order to diagnose memory in use and some other memory related issues. Usually, pymalloc is a big win. Neal -- Index: Objects/obmalloc.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/obmalloc.c,v retrieving revision 2.51 diff -w -u -r2.51 obmalloc.c --- Objects/obmalloc.c 17 Jun 2003 15:48:11 -0000 2.51 +++ Objects/obmalloc.c 5 Jul 2003 15:53:55 -0000 @@ -534,8 +534,31 @@ * so the (I) < narenas must be false, saving us from trying to index into * a NULL arenas. */ -#define ADDRESS_IN_RANGE(P, I) \ - ((I) < narenas && (uptr)(P) - arenas[I] < (uptr)ARENA_SIZE) +#define ADDRESS_IN_RANGE(P, POOL) \ + ((POOL)->arenaindex < narenas && \ + (uptr)(P) - arenas[(POOL)->arenaindex] < (uptr)ARENA_SIZE) + +/* This is only useful when running memory debuggers such as + * Purify or Valgrind. Uncomment to use. + */ +#define USING_MEMORY_DEBUGGER + +#ifdef USING_MEMORY_DEBUGGER + +/* ADDRESS_IN_RANGE may access uninitialized memory by design + * This leads to thousands of spurious warnings when using + * Purify or Valgrind. By making a function, we can easily + * suppress the uninitialized memory reads in this one function. + * So we won't ignore real errors elsewhere. + * + * Disable the macro and use a function. + */ + +#undef ADDRESS_IN_RANGE + +/* Don't make static, to ensure this isn't inlined. */ +int ADDRESS_IN_RANGE(void *P, poolp pool); +#endif /*==========================================================================*/ @@ -708,7 +731,7 @@ return; pool = POOL_ADDR(p); - if (ADDRESS_IN_RANGE(p, pool->arenaindex)) { + if (ADDRESS_IN_RANGE(p, pool)) { /* We allocated this address. */ LOCK(); /* @@ -791,7 +814,7 @@ return PyObject_Malloc(nbytes); pool = POOL_ADDR(p); - if (ADDRESS_IN_RANGE(p, pool->arenaindex)) { + if (ADDRESS_IN_RANGE(p, pool)) { /* We're in charge of this block */ size = INDEX2SIZE(pool->szidx); if (nbytes <= size) { @@ -1373,3 +1396,13 @@ } #endif /* PYMALLOC_DEBUG */ + +#ifdef USING_MEMORY_DEBUGGER +/* Make this function last so gcc won't inline it + since the definition is after the reference. */ +int ADDRESS_IN_RANGE(void *P, poolp pool) +{ + return ((pool->arenaindex) < narenas && + (uptr)(P) - arenas[pool->arenaindex] < (uptr)ARENA_SIZE); +} +#endif From kbk@shore.net Sat Jul 5 17:47:35 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 05 Jul 2003 12:47:35 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: (martin@v.loewis.de's message of "05 Jul 2003 10:25:23 +0200") References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> Message-ID: martin@v.loewis.de (Martin v. L=F6wis) writes: > I can't tell for sure what the maximum time lag of this is, as I don't > know when SF rolls their CVS snapshots (on which this is based). If > anybody can tell me, I'll happily adjust my crontab. There have been a number of complaints on the SF Support Tracker=20 that the nightly CVS repository snapshot tarballs are out of date, at least for some projects. e.g. http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D756818&group_i= d=3D1&atid=3D200001 __ KBK From mal@lemburg.com Sat Jul 5 17:52:07 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 05 Jul 2003 18:52:07 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <200307051341.h65DfL424101@pcp02138704pcs.reston01.va.comcast.net> References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> <3F06B606.6020801@lemburg.com> <200307051341.h65DfL424101@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <3F070237.1040201@lemburg.com> Guido van Rossum wrote: >>Just a thought, not sure whether it's even possible (being no CVS >>expert): wouldn't it be possible to setup a caching CVS proxy on >>a more reliable machine, e.g. the python.org one ? > > Im no CVS expert either, but I doubt that's at all possible without > access to the back-end store used for the repository. Hmm, no luck then. Oh well. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 05 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1 From tim.one@comcast.net Sat Jul 5 17:58:41 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 5 Jul 2003 12:58:41 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: <200307042001.h64K12e22878@pcp02138704pcs.reston01.va.comcast.net> Message-ID: [Guido] >>> I think there is talk though to make it impossible to turn off >>> pymalloc in the future (you can still turn it off in Python 2.3). [Tim] >> I haven't heard such talk before. There was talk of making it >> impossible to compile without cyclic gc, and-- indeed --that was >> done for 2.3. [Guido] > Oops, I think I may have been confused by that one. Me too -- it was a surprisingly common confusion when we were all talking about making cyclic gc compilation mandatory, I guess because they all "have something to do with recycling memory". Or something . From tim.one@comcast.net Sat Jul 5 18:17:41 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 5 Jul 2003 13:17:41 -0400 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: <20030705160127.GI1237@epoch.metaslash.com> Message-ID: [Neal Norwitz] > ... > I never got around to submitting the attached patch which > makes it easier and safer to use memory testing tools such > as Purify and Valgrind. The suppression then only needs to > be applied to ADDRESS_IN_RANGE. Please apply the patch, so that people can use this in 2.3 final. Nits: + USING_MEMORY_DEBUGGER should not be defined by default. + USING_MEMORY_DEBUGGER should be documented in Misc/SpecialBuilds.txt. That's also a good place to put sample incantations to make Purify (etc) shut up about this. + USING_MEMORY_DEBUGGER should probably grow a Py_ prefix. + The declaration and definition of the function form of ADDRESS_IN_RANGE should be declared static. + C functions in Python source should be defined like decorations function_name(... instead of like decorations function_name(... > I haven't noticed a problem with pymalloc on Linux, Solaris, Tru64, > AIX, HP-UX, FreeBSD. So far there haven't seemed to be any problems > with pymalloc. Its non-standard assumptions are mild. I don't know of any architecture now where a pointer can't be faithfully cast to some unsigned integral type. The biggest insecurity remaining then is addressed in a comment: ... * In theory, if SYSTEM_PAGE_SIZE is larger than the native page * size, then `POOL_ADDR(p)->arenaindex' could rarely cause a segmentation * violation fault. 4K is apparently OK for all the platforms that python * currently targets. This comment in turn assumes that whatever memory protection gimmicks an OS implements are at page granularity. This assumption could be violated too by, e.g., an OS that resolved memory read permission to word (or even byte) boundaries, but I expect that's very rare due to lack of direct HW support. > Somtimes, there are benefits to turning off pymalloc from time to time > in order to diagnose memory in use Really? In a PYMALLOC_DEBUG build, and when the envar PYTHONMALLOCSTATS is set, pymalloc delivers an exact accounting of every byte pymalloc knows about. Even bytes "lost" to various alignment requirements are accounted for. > and some other memory related issues. Usually, pymalloc is a big win. I agree . From Anthony Baxter Sun Jul 6 05:30:54 2003 From: Anthony Baxter (Anthony Baxter) Date: Sun, 06 Jul 2003 14:30:54 +1000 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <3F06B606.6020801@lemburg.com> Message-ID: <200307060430.h664UtLC024975@localhost.localdomain> >>> "M.-A. Lemburg" wrote > Just a thought, not sure whether it's even possible (being no CVS > expert): wouldn't it be possible to setup a caching CVS proxy on > a more reliable machine, e.g. the python.org one ? That's what I was referring to originally - we take the nightly snapshot and unpack it and serve from it. The reason I brought this up is that I want to get some (non-python-dev) folks to try the new email.Parser implementation - it's currently checked in on a branch, so with pserver access being screwed, I'm going to have to make my own little release of the package to get testers... Anthony -- Anthony Baxter It's never too late to have a happy childhood. From mal@lemburg.com Sun Jul 6 11:45:49 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 06 Jul 2003 12:45:49 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <200307060430.h664UtLC024975@localhost.localdomain> References: <200307060430.h664UtLC024975@localhost.localdomain> Message-ID: <3F07FDDD.9040701@lemburg.com> Anthony Baxter wrote: >>>>"M.-A. Lemburg" wrote >> >>Just a thought, not sure whether it's even possible (being no CVS >>expert): wouldn't it be possible to setup a caching CVS proxy on >>a more reliable machine, e.g. the python.org one ? > > > That's what I was referring to originally - we take the nightly snapshot > and unpack it and serve from it. Hmm, but how is CVS read-only access different from downloading a tarball ? (except maybe for the different bandwidth they require in case of updates) Perhaps we should setup an rsync server on python.org which allows getting at the current snapshot incrementally ? > The reason I brought this up is that I want to get some (non-python-dev) > folks to try the new email.Parser implementation - it's currently checked > in on a branch, so with pserver access being screwed, I'm going to have to > make my own little release of the package to get testers... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 06 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1 From skip@mojam.com Sun Jul 6 13:00:24 2003 From: skip@mojam.com (Skip Montanaro) Date: Sun, 6 Jul 2003 07:00:24 -0500 Subject: [Python-Dev] Weekly Python Bug/Patch Summary Message-ID: <200307061200.h66C0Od11548@manatee.mojam.com> Bug/Patch Summary ----------------- 379 open / 3815 total bugs (+22) 169 open / 2257 total patches (+9) New Bugs -------- ioctl only accepts 1024 byte arguments (2003-06-29) http://python.org/sf/762855 dl module not installed with 2.2.3 (2003-06-29) http://python.org/sf/763007 tut/contents.html does not exist (2003-06-29) http://python.org/sf/763032 unable to specify another compiler (2003-06-30) http://python.org/sf/763043 unit test test_time failed (2003-06-30) http://python.org/sf/763153 Sudden death with SIGSEGV in RtlEnterCriticalSection (2003-06-30) http://python.org/sf/763190 Failures in test_macostools (2003-06-30) http://python.org/sf/763708 test_bsddb3 crashes if run after test_locale (2003-07-01) http://python.org/sf/763928 pythonw crashes under one windows platform (easy-everything) (2003-07-01) http://python.org/sf/764049 recent test_httplib change uses network (2003-07-01) http://python.org/sf/764095 AF_UNIX sockets do not handle Linux-specific addressing (2003-07-02) http://python.org/sf/764437 cvs update warnings (2003-07-02) http://python.org/sf/764447 test test_nis crashed -- nis.error: no such key in map (2003-07-02) http://python.org/sf/764493 doctest fails with TypeError (2003-07-02) http://python.org/sf/764504 python treats IRIX64 and IRIX as different, but they are the (2003-07-02) http://python.org/sf/764560 PackMan reissues error messages (2003-07-02) http://python.org/sf/764615 Old bsddb version picked by setup.py (2003-07-02) http://python.org/sf/764839 Installing 2.3b2 on to non-system disk fails (2003-07-02) http://python.org/sf/764975 Subclassing from Modules (2003-07-03) http://python.org/sf/765228 test zipimport fails (2003-07-03) http://python.org/sf/765456 PackMan: per-user source install of Numeric (2003-07-03) http://python.org/sf/765601 IDE has dirty sys.argv (2003-07-03) http://python.org/sf/765603 Binary installer says it will take 0 bytes of diskspace (2003-07-03) http://python.org/sf/765608 Packman crashes with garbage database (2003-07-03) http://python.org/sf/765621 Cannot step in debugger if line # doesn't change (2003-07-03) http://python.org/sf/765624 unable to specify another compiler (2003-07-04) http://python.org/sf/765819 InfoPlist.strings files are UTF-16. (2003-07-04) http://python.org/sf/765888 bundlebuilder Info.plist files. (2003-07-04) http://python.org/sf/765903 Mac/OSX/Makefile assumes case-insensitive build (2003-07-04) http://python.org/sf/766210 string.title() doesn't understand apostrophes (2003-07-05) http://python.org/sf/766541 New Patches ----------- API Functions for PyArray (2003-06-29) http://python.org/sf/762920 address test_time.py failures under Redhat 6.2 (2003-06-29) http://python.org/sf/762934 timemodule.c: Python loses current timezone (2003-06-29) http://python.org/sf/762963 3 bugs fixed: handling of SyntaxErrors in symbol table build (2003-06-30) http://python.org/sf/763201 Minor enhancements to Variable class (2003-06-30) http://python.org/sf/763580 Support IDLE Edit of .py/.pyw from idlelib (2003-06-30) http://python.org/sf/763681 Fix for tkFont.Font(name=...) (2003-07-01) http://python.org/sf/764217 add set/getattr interface to tkFont.Font objects (2003-07-01) http://python.org/sf/764221 Bugfix for incorrect xmlrpclib.Fault representation (2003-07-02) http://python.org/sf/764470 Unicode strings in sys.path (2003-07-02) http://python.org/sf/764594 building bsddb3 on FreeBSD (2003-07-02) http://python.org/sf/764612 fix fnmatch.__all__ (2003-07-03) http://python.org/sf/765238 whichdb not ID'ing dbm files with GDBM backend (2003-07-06) http://python.org/sf/766650 Closed Bugs ----------- AssertionErrors in httplib (2003-01-11) http://python.org/sf/666219 classmethod does not check its arguments (2003-01-16) http://python.org/sf/668980 Document strptime limitation (2003-03-05) http://python.org/sf/697990 broken ncurses support in current cvs a last distribution (2003-06-04) http://python.org/sf/748926 last threads fixes broke linker (2003-06-04) http://python.org/sf/748928 websucker bug (2003-06-12) http://python.org/sf/753592 tkMessageBox.askyesnocancel missing (2003-06-26) http://python.org/sf/761144 bug in signal.signal -- raises SystemError (2003-06-27) http://python.org/sf/762198 Python segfaults when sys.stdout is changed in getattr (2003-06-28) http://python.org/sf/762455 problem building c extension with minGW on Windows (2003-06-29) http://python.org/sf/762614 Closed Patches -------------- Tutorial: remove string exceptions, add parnassus, #posts (2003-06-08) http://python.org/sf/751062 SSL crash interpreter on error (2003-06-15) http://python.org/sf/754870 adding BaseSet.filter and Set.filter_update (2003-06-26) http://python.org/sf/761104 DISTUTILS_DEBUG undocumented (2003-06-26) http://python.org/sf/761401 patch against readline module to handle signals (2003-06-27) http://python.org/sf/761865 pep-283 outdated (2003-06-28) http://python.org/sf/762502 From guido@python.org Sun Jul 6 13:42:29 2003 From: guido@python.org (Guido van Rossum) Date: Sun, 06 Jul 2003 08:42:29 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: Your message of "Sun, 06 Jul 2003 12:45:49 +0200." <3F07FDDD.9040701@lemburg.com> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> Message-ID: <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> > Hmm, but how is CVS read-only access different from downloading > a tarball ? (except maybe for the different bandwidth they require > in case of updates) CVS read-only makes it simple for anybody who has CVS installed to check out a particular branch. Downloading a tarball means you have to know how to set up a CVS repository, which most CVS users never need to do these days. (It's easy, but I probably wouldn't be able to do it myself without having to study the manual for 15 minutes, and I've done it before!) Downloading a tarball also means that each time you want to get a newer version, you have to redo the steps to set up the repository. Using a CVS mirror based on the tarballs means that only the mirror administrator has to do that, and other users can simply hook up to the mirror and use "cvs update" like they are used to. > Perhaps we should setup an rsync server on python.org which allows > getting at the current snapshot incrementally ? That would only make sense if it makes sense to have multiple mirrors, which I'm not convinced of. (OTOH we might make the CVS tree available through FTP and HTTP and RSYNC, and then all Python mirror sites would automatically have the data so all they need to do is run a CVS server on top of it if they want to, and they have instant mirroring. This might cause some mirrors to complain about the amount of data, though -- I don't know how big th eunpacked repository is.) --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Sun Jul 6 14:10:02 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 06 Jul 2003 15:10:02 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <3F081FAA.9060000@lemburg.com> Guido van Rossum wrote: >>Hmm, but how is CVS read-only access different from downloading >>a tarball ? (except maybe for the different bandwidth they require >>in case of updates) > > CVS read-only makes it simple for anybody who has CVS installed to > check out a particular branch. Ah yes, forgot about that option. > Downloading a tarball means you have to know how to set up a CVS > repository, which most CVS users never need to do these days. (It's > easy, but I probably wouldn't be able to do it myself without having > to study the manual for 15 minutes, and I've done it before!) > > Downloading a tarball also means that each time you want to get a > newer version, you have to redo the steps to set up the repository. Hmm, I was thinking of the tarball that you get by doing a clean checkout and then zipping everything up. I believe that's what Martin is doing. > Using a CVS mirror based on the tarballs means that only the mirror > administrator has to do that, and other users can simply hook up to > the mirror and use "cvs update" like they are used to. Side note: the CVS repository is already available as nightly tar ball from: http://cvs.sourceforge.net/cvstarballs/python-cvsroot.tar.gz (roughly 52MB) >>Perhaps we should setup an rsync server on python.org which allows >>getting at the current snapshot incrementally ? > > That would only make sense if it makes sense to have multiple mirrors, > which I'm not convinced of. > > (OTOH we might make the CVS tree available through FTP and HTTP and > RSYNC, and then all Python mirror sites would automatically have the > data so all they need to do is run a CVS server on top of it if they > want to, and they have instant mirroring. This might cause some > mirrors to complain about the amount of data, though -- I don't know > how big th eunpacked repository is.) I was thinking of making the clean checkouts available via FTP, HTTP and RSYNC; not the complete cvsroot repository. But you're right: if someone wants a special branch of the CVS tree then setting up a CVS mirror makes more sense. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 06 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1 From martin@v.loewis.de Sun Jul 6 14:42:13 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 06 Jul 2003 15:42:13 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <3F081FAA.9060000@lemburg.com> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> <3F081FAA.9060000@lemburg.com> Message-ID: "M.-A. Lemburg" writes: > Hmm, I was thinking of the tarball that you get by doing a clean > checkout and then zipping everything up. I believe that's what > Martin is doing. Almost. Doing a clean check-out would mean to provide my SF private key to the cronjob, which I'm not willing to do. Instead, I download the CVS repository snapshot, unpack that, and do a local checkout. There have been comments that the SF CVS snapshot might not be generated every day - I'll have to check that. > But you're right: if someone wants a special branch of the > CVS tree then setting up a CVS mirror makes more sense. OTOH, I can easily add "common" branches to the set of tarfiles that I produce - let me know if you need anything that I currently don't produce (as long as disk space allows it). Regards, Martin From Anthony Baxter Sun Jul 6 14:42:43 2003 From: Anthony Baxter (Anthony Baxter) Date: Sun, 06 Jul 2003 23:42:43 +1000 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <3F081FAA.9060000@lemburg.com> Message-ID: <200307061342.h66DghCB027333@localhost.localdomain> >>> "M.-A. Lemburg" wrote > But you're right: if someone wants a special branch of the > CVS tree then setting up a CVS mirror makes more sense. It's also just easier for doing things like "is this fixed in the trunk, or a branch?" or for generating patches against the current-CVS. But hey, it's work to set it up on, say, creosote (we'd want to make sure pserver is chrooted, for one). I've got a Z3 sprint Wed-Sun this week, but assuming I can fit in the time, I'm willing to do the work on creosote to make this happen (assuming it's a useful thing to be doing). It might be appropriate to redirect this to the pydotorg list. -- Anthony Baxter It's never too late to have a happy childhood. From zooko@zooko.com Sun Jul 6 14:50:28 2003 From: zooko@zooko.com (Zooko) Date: 6 Jul 2003 09:50:28 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: Message from Guido van Rossum of "Sun, 06 Jul 2003 08:42:29 EDT." <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> Message-ID: python-dev people wrote: > > Hmm, but how is CVS read-only access different from downloading > > a tarball ? (except maybe for the different bandwidth they require > > in case of updates) If I have a patch for a Python sitting in my CVS sandbox, I can merge it so that it applies cleanly to the current CVS HEAD. If I write a patch against a tarball, and the patch isn't accepted by the upstream maintainers before it starts to conflict with their current version, then I'm more likely to drop it instead of manually updating it to apply to the latest tarball. I have contributed at least one patch to Python which might have fallen by the wayside if I hadn't had read-only CVS access to Python's repository. Also, I've written several small patches for the programming language E [1] which fell by the wayside in part because I didn't have read-only CVS access to E's repository. Now granted, these are all "low-value" patches. If they were important patches, the maintainers would accept them right away, or I would spend the effort to manually merge them to the current version. Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links [1] http://erights.org/ From guido@python.org Sun Jul 6 14:56:39 2003 From: guido@python.org (Guido van Rossum) Date: Sun, 06 Jul 2003 09:56:39 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: Your message of "Sun, 06 Jul 2003 15:10:02 +0200." <3F081FAA.9060000@lemburg.com> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> <3F081FAA.9060000@lemburg.com> Message-ID: <200307061356.h66Dudp04970@pcp02138704pcs.reston01.va.comcast.net> > > Downloading a tarball means you have to know how to set up a CVS > > repository, which most CVS users never need to do these days. (It's > > easy, but I probably wouldn't be able to do it myself without having > > to study the manual for 15 minutes, and I've done it before!) > > > > Downloading a tarball also means that each time you want to get a > > newer version, you have to redo the steps to set up the repository. > > Hmm, I was thinking of the tarball that you get by doing a clean > checkout and then zipping everything up. I believe that's what > Martin is doing. Right, and so is http://cvs.perl.org/snapshots/python/python/. Only SF itself is making tarballs of the CVS *repository* available (as you mention below). If these files aren't mirrorred somewhere, we really should -- SF says "please ensure your project has established a backup plan" in the same paragraph where it gives the tarball link. > > Using a CVS mirror based on the tarballs means that only the mirror > > administrator has to do that, and other users can simply hook up to > > the mirror and use "cvs update" like they are used to. --Guido van Rossum (home page: http://www.python.org/~guido/) From martin@v.loewis.de Sun Jul 6 15:30:16 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 06 Jul 2003 16:30:16 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <200307061356.h66Dudp04970@pcp02138704pcs.reston01.va.comcast.net> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> <3F081FAA.9060000@lemburg.com> <200307061356.h66Dudp04970@pcp02138704pcs.reston01.va.comcast.net> Message-ID: Guido van Rossum writes: > Right, and so is http://cvs.perl.org/snapshots/python/python/. Only > SF itself is making tarballs of the CVS *repository* available (as you > mention below). If these files aren't mirrorred somewhere, we really > should -- SF says "please ensure your project has established a backup > plan" in the same paragraph where it gives the tarball link. I think Barry (or was it Jeremy?) once created a mirror for these - they are taking up disk space on pydotorg. I don't know whether that mirror is still in effect, but I would assume it is. As a side effect of producing tarballs, I now also mirror these repository tarballs. Regards, Martin From martin@v.loewis.de Sun Jul 6 15:34:38 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 06 Jul 2003 16:34:38 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> Message-ID: "Zooko" writes: > tarball, and the patch isn't accepted by the upstream maintainers > before it starts to conflict with their current version, then I'm > more likely to drop it instead of manually updating it to apply to > the latest tarball. It's not that the readonly CVS is completely inoperable - my updates on pserver usually get through just fine, if they start at all, and I never need to repeat the cvs up command more than 100 times before it starts. So if you want to maintain pending patches, using the pserver CVS is definitely the right thing to do. I'd expect that you would do a cvs up once a week or so, which should be managable even with the current problems. I have a number of patches sitting in such a sandbox myself, and I have no plans of abandoning that sandbox. Regards, Martin From zooko@zooko.com Sun Jul 6 16:05:56 2003 From: zooko@zooko.com (Zooko) Date: 6 Jul 2003 11:05:56 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: Message from martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) of "06 Jul 2003 16:34:38 +0200." References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> Message-ID: > So if you want to maintain pending patches, using the pserver CVS is > definitely the right thing to do. I'd expect that you would do a cvs > up once a week or so, which should be managable even with the current > problems. I have a number of patches sitting in such a sandbox myself, > and I have no plans of abandoning that sandbox. Indeed. I use this bash command-line when I want to cvs up (every week or so): cvs update -Pd -A ; while [ $? = 1 ] ; do cvs update -Pd -A ; done (Perhaps I shouldn't, as it degrades service for everyone else. Sorry about that. The most recent time was because Guido asked for testing of the current HEAD in preparation for the 2.3 release.) I've been told that the problem is going to be fixed soon on sf.net's end anyway. Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links From aahz@pythoncraft.com Sun Jul 6 16:59:15 2003 From: aahz@pythoncraft.com (Aahz) Date: Sun, 6 Jul 2003 11:59:15 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> <3F081FAA.9060000@lemburg.com> <200307061356.h66Dudp04970@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <20030706155915.GA8819@panix.com> On Sun, Jul 06, 2003, Martin v. L=F6wis wrote: > Guido van Rossum writes: >>=20 >> Right, and so is http://cvs.perl.org/snapshots/python/python/. Only >> SF itself is making tarballs of the CVS *repository* available (as you >> mention below). If these files aren't mirrorred somewhere, we really >> should -- SF says "please ensure your project has established a backup >> plan" in the same paragraph where it gives the tarball link. >=20 > I think Barry (or was it Jeremy?) once created a mirror for these - > they are taking up disk space on pydotorg. I don't know whether that > mirror is still in effect, but I would assume it is. As a side effect > of producing tarballs, I now also mirror these repository tarballs. Correct (more or less -- but I can't find where on creosote this stuff is right now). And thanks to the good offices of Sean Reifschneider, I've got an eight-CD collection of the CVS archives prior to the 4/2002 cleanup on python.org. --=20 Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.= com/ "Not everything in life has a clue in front of it...." --JMS From barry@python.org Sun Jul 6 19:22:29 2003 From: barry@python.org (Barry Warsaw) Date: 06 Jul 2003 14:22:29 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> <3F081FAA.9060000@lemburg.com> <200307061356.h66Dudp04970@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <1057515748.947.3.camel@anthem> On Sun, 2003-07-06 at 10:30, Martin v. L=F6wis wrote: > I think Barry (or was it Jeremy?) once created a mirror for these - > they are taking up disk space on pydotorg. I don't know whether that > mirror is still in effect, but I would assume it is. As a side effect > of producing tarballs, I now also mirror these repository tarballs. It was me, and it's basically just for backup purposes, not for alternative access. There's a cronjob on creosote that sucks down the repository tarballs via wget, saving them in /usr/local/archives. They tend to take up a huge gob of space so every now and then we clear them out on the assumption that XS4ALL is making backups . Note that we grab the Python, Mailman, mimelib, and Jython cvsroots, as well as the Jython FAQwiz and Moin. On one hand, we probably don't need to keep grabbing the mimelib cvs, but OTOH, those aren't that big anyway. I don't think it would be a lot of work to unpack those nightly and make them available via pserver, but I'm not volunteering. -Barry From tim.one@comcast.net Sun Jul 6 19:23:34 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 6 Jul 2003 14:23:34 -0400 Subject: [Python-Dev] sys.setcheckinterval doc problems In-Reply-To: <20030702202929.96112.qmail@web40506.mail.yahoo.com> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C343CA.2F1584A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit [Alex Martelli] > ... > As I was checking that, I was struck by the fact that > having "write-only" settings is quite an anomaly -- > e.g. it makes writing a function that sets the check > interval to 0 temporarily, fiddles around a bit, then > sets it back to the previous value, a bit of trouble. > > Now that the check interval is a global variable, is > there any problem with making it readable (presumably > with a new sys.getcheckinterval() function) as well as > writable? Write-only settings are indeed strange. We could add a new function, or have setcheckinterval() return the old value. The attached patch implements the former. Guido, do you object to adding this to 2.3? I don't (the potential for breakage seems insignificant). ------=_NextPart_000_0016_01C343CA.2F1584A0 Content-Type: text/plain; name="getcheck.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="getcheck.txt" Index: Doc/lib/libsys.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libsys.tex,v retrieving revision 1.65 diff -c -r1.65 libsys.tex *** Doc/lib/libsys.tex 2 Jul 2003 21:38:34 -0000 1.65 --- Doc/lib/libsys.tex 6 Jul 2003 18:21:43 -0000 *************** *** 197,202 **** --- 197,207 ---- or when \code{os._exit()} is called.} \end{datadesc} + \begin{funcdesc}{getcheckinterval}{} + Return the interpreter's ``check interval''; + see \function{setcheckinterval()}. + \end{funcdesc} + \begin{funcdesc}{getdefaultencoding}{} Return the name of the current default string encoding used by the Unicode implementation. Index: Lib/test/test_sys.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_sys.py,v retrieving revision 1.7 diff -c -r1.7 test_sys.py *** Lib/test/test_sys.py 1 May 2003 17:45:51 -0000 1.7 --- Lib/test/test_sys.py 6 Jul 2003 18:21:44 -0000 *************** *** 172,179 **** def test_setcheckinterval(self): self.assertRaises(TypeError, sys.setcheckinterval) ! sys.setcheckinterval(120) ! sys.setcheckinterval(100) def test_recursionlimit(self): self.assertRaises(TypeError, sys.getrecursionlimit, 42) --- 172,181 ---- def test_setcheckinterval(self): self.assertRaises(TypeError, sys.setcheckinterval) ! orig = sys.getcheckinterval() ! for n in 0, 100, 120, orig: # orig last to restore starting state ! sys.setcheckinterval(n) ! self.assertEquals(sys.getcheckinterval(), n) def test_recursionlimit(self): self.assertRaises(TypeError, sys.getrecursionlimit, 42) Index: Misc/NEWS =================================================================== RCS file: /cvsroot/python/python/dist/src/Misc/NEWS,v retrieving revision 1.808 diff -c -r1.808 NEWS *** Misc/NEWS 4 Jul 2003 04:40:44 -0000 1.808 --- Misc/NEWS 6 Jul 2003 18:21:46 -0000 *************** *** 10,15 **** --- 10,18 ---- Core and builtins ----------------- + - The new function sys.getcheckinterval() returns the last value set + by sys.setcheckinterval(). + - The Windows implementation of PyThread_start_new_thread() never checked error returns from Windows functions correctly. As a result, it could claim to start a new thread even when the Microsoft Index: Python/sysmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v retrieving revision 2.119 diff -c -r2.119 sysmodule.c *** Python/sysmodule.c 10 May 2003 07:08:50 -0000 2.119 --- Python/sysmodule.c 6 Jul 2003 18:21:47 -0000 *************** *** 432,437 **** --- 432,447 ---- ); static PyObject * + sys_getcheckinterval(PyObject *self, PyObject *args) + { + return PyInt_FromLong(_Py_CheckInterval); + } + + PyDoc_STRVAR(getcheckinterval_doc, + "getcheckinterval() -> current check interval; see setcheckinterval()." + ); + + static PyObject * sys_setrecursionlimit(PyObject *self, PyObject *args) { int new_limit; *************** *** 723,728 **** --- 733,740 ---- #endif {"setcheckinterval", sys_setcheckinterval, METH_VARARGS, setcheckinterval_doc}, + {"getcheckinterval", sys_getcheckinterval, METH_NOARGS, + getcheckinterval_doc}, #ifdef HAVE_DLOPEN {"setdlopenflags", sys_setdlopenflags, METH_VARARGS, setdlopenflags_doc}, ------=_NextPart_000_0016_01C343CA.2F1584A0-- From pedronis@bluewin.ch Sun Jul 6 19:30:45 2003 From: pedronis@bluewin.ch (Samuele Pedroni) Date: Sun, 06 Jul 2003 20:30:45 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <1057515748.947.3.camel@anthem> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> <3F081FAA.9060000@lemburg.com> <200307061356.h66Dudp04970@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <5.2.1.1.0.20030706202900.0253f0f0@pop.bluewin.ch> At 14:22 06.07.2003 -0400, Barry Warsaw wrote: > and Jython cvsroots, as well as >the Jython FAQwiz and Moin. I didn't know about that, now if I knew how/could access them, that would be even better :). From guido@python.org Sun Jul 6 19:34:49 2003 From: guido@python.org (Guido van Rossum) Date: Sun, 06 Jul 2003 14:34:49 -0400 Subject: [Python-Dev] sys.setcheckinterval doc problems In-Reply-To: Your message of "Sun, 06 Jul 2003 14:23:34 EDT." References: Message-ID: <200307061834.h66IYnO05686@pcp02138704pcs.reston01.va.comcast.net> > [Alex Martelli] > > ... > > As I was checking that, I was struck by the fact that > > having "write-only" settings is quite an anomaly -- > > e.g. it makes writing a function that sets the check > > interval to 0 temporarily, fiddles around a bit, then > > sets it back to the previous value, a bit of trouble. > > > > Now that the check interval is a global variable, is > > there any problem with making it readable (presumably > > with a new sys.getcheckinterval() function) as well as > > writable? [Tim] > Write-only settings are indeed strange. We could add a new function, or > have setcheckinterval() return the old value. I prefer get/set functions over the strange return-old-value API. > The attached patch implements the former. Guido, do you object to adding > this to 2.3? I don't (the potential for breakage seems insignificant). Go for it. --Guido van Rossum (home page: http://www.python.org/~guido/) From tdelaney@avaya.com Mon Jul 7 00:38:48 2003 From: tdelaney@avaya.com (Delaney, Timothy C (Timothy)) Date: Mon, 7 Jul 2003 09:38:48 +1000 Subject: [Python-Dev] Running tests on freebsd5 Message-ID: <338366A6D2E2CA4C9DAEAE652E12A1DE84468C@au3010avexu1.global.avaya.com> > From: Delaney, Timothy C (Timothy)=20 >=20 > I might have the opportunity to at least run the tests on=20 > FreeBSD 5.1. I just set up my first FreeBSD system on the weekend :) OK - got some results. Remember that these are on a minimally-configured FREEBSD-5.1-RELEASE. I looked for a bug report on SF for these but = couldn't find any - let me know which bug to attach trhe various test failures to (or let me know if I need to create a new one). I expected some tests to fail since my NIC has been set up via DHCP, = but Win2K internet connection sharing doesn't send a hostname back=20 (it assumes everyone is using WINS to lookup names I guess). running build_scripts test test_socket failed -- Traceback (most recent call last): File "/usr/home/Tim/Python-2.3b2/Lib/test/test_socket.py", line 215, = in testCrucialConstants socket.SOCK_RDM AttributeError: 'module' object has no attribute 'SOCK_RDM' This is one of the errors reported by Pieter. test test_strptime failed -- Traceback (most recent call last): File "/usr/home/Tim/Python-2.3b2/Lib/test/test_strptime.py", line = 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/usr/home/Tim/Python-2.3b2/Lib/unittest.py", line 268, in = failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone = value not set to -1 This one is almost certainly my fault ;) But the error message is wrong = I think - it should read 'but timezone value' rather than 'but timzone = value'. test test_tempfile failed -- Traceback (most recent call last): File "/usr/home/Tim/Python-2.3b2/Lib/test/test_tempfile.py", line = 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/usr/home/Tim/Python-2.3b2/Lib/unittest.py", line 264, in = failIf if expr: raise self.failureException, msg AssertionError: child process reports failure This is the other error reported by Pieter. 4 tests failed: test_mimetools test_socket test_strptime test_tempfile test_mimetools fails because I don't have a usable hostname for the = machine (due to the above DHCP configuration issues). So I can confirm that both of the issues Pieter found are present on a = *standard* FREEBSD-5.1-RELEASE install. Tim Delaney From martin@v.loewis.de Mon Jul 7 06:09:45 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 07 Jul 2003 07:09:45 +0200 Subject: [Python-Dev] Running tests on freebsd5 In-Reply-To: <338366A6D2E2CA4C9DAEAE652E12A1DE84468C@au3010avexu1.global.avaya.com> References: <338366A6D2E2CA4C9DAEAE652E12A1DE84468C@au3010avexu1.global.avaya.com> Message-ID: "Delaney, Timothy C (Timothy)" writes: > OK - got some results. Remember that these are on a minimally-configured > FREEBSD-5.1-RELEASE. I looked for a bug report on SF for these but couldn't > find any - let me know which bug to attach trhe various test failures to > (or let me know if I need to create a new one). Please always create new bug reports - you can't attach stuff to reports that you have not created. Also, please create one bug report per bug, instead of reporting multiple problems in a single report. > test test_socket failed -- Traceback (most recent call last): > File "/usr/home/Tim/Python-2.3b2/Lib/test/test_socket.py", line 215, in > testCrucialConstants > socket.SOCK_RDM > AttributeError: 'module' object has no attribute 'SOCK_RDM' AFAICT, this is a bug in your operating system. > This one is almost certainly my fault ;) But the error message is wrong I > think - it should read 'but timezone value' rather than 'but timzone value'. This is fixed in CVS. > test test_tempfile failed -- Traceback (most recent call last): > File "/usr/home/Tim/Python-2.3b2/Lib/test/test_tempfile.py", line 299, in > test_noinherit > self.failIf(retval > 0, "child process reports failure") > File "/usr/home/Tim/Python-2.3b2/Lib/unittest.py", line 264, in failIf > if expr: raise self.failureException, msg > AssertionError: child process reports failure > > This is the other error reported by Pieter. This requires deeper analysis by a platform expert. > So I can confirm that both of the issues Pieter found are present on > a *standard* FREEBSD-5.1-RELEASE install. While such information might be useful to some people, it is unlikely that anything is done about these problems, unless a platform expert steps forward and determines the true cause of the problems, one by one. Regards, Martin From mal@lemburg.com Mon Jul 7 09:58:53 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 07 Jul 2003 10:58:53 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <200307061342.h66DghCB027333@localhost.localdomain> References: <200307061342.h66DghCB027333@localhost.localdomain> Message-ID: <3F09364D.6020005@lemburg.com> Anthony Baxter wrote: >>>>"M.-A. Lemburg" wrote >> >>But you're right: if someone wants a special branch of the >>CVS tree then setting up a CVS mirror makes more sense. > > > It's also just easier for doing things like "is this fixed in > the trunk, or a branch?" or for generating patches against the > current-CVS. But hey, it's work to set it up on, say, creosote > (we'd want to make sure pserver is chrooted, for one). I've got > a Z3 sprint Wed-Sun this week, but assuming I can fit in the > time, I'm willing to do the work on creosote to make this > happen (assuming it's a useful thing to be doing). > > It might be appropriate to redirect this to the pydotorg list. Here's a howto that might help in installing a secure CVS server on python.org: http://www.prima.eu.org/tobez/cvs-howto.html -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 07 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1 From mwh@python.net Mon Jul 7 13:05:12 2003 From: mwh@python.net (Michael Hudson) Date: Mon, 07 Jul 2003 13:05:12 +0100 Subject: [Python-Dev] Invalid memory read in PyObject_Free In-Reply-To: <20030705160127.GI1237@epoch.metaslash.com> (Neal Norwitz's message of "Sat, 5 Jul 2003 12:01:28 -0400") References: <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> <20030705160127.GI1237@epoch.metaslash.com> Message-ID: <2mfzlio83r.fsf@starship.python.net> Neal Norwitz writes: > Somtimes, there are benefits to turning off pymalloc from time to time > in order to diagnose memory in use and some other memory related > issues. Usually, pymalloc is a big win. As in "hmm, I wonder if this is a pymalloc pathological case? nope"? :-) Cheers, M. -- Some people say that a monkey would bang out the complete works of Shakespeare on a typewriter give an unlimited amount of time. In the meantime, what they would probably produce is a valid sendmail configuration file. -- Nicholas Petreley From andymac@bullseye.apana.org.au Mon Jul 7 12:18:16 2003 From: andymac@bullseye.apana.org.au (Andrew MacIntyre) Date: Mon, 7 Jul 2003 21:18:16 +1000 (EST) Subject: [Python-Dev] Running tests on freebsd5 In-Reply-To: <338366A6D2E2CA4C9DAEAE652E12A1DE84468C@au3010avexu1.global.avaya.com> References: <338366A6D2E2CA4C9DAEAE652E12A1DE84468C@au3010avexu1.global.avaya.com> Message-ID: <20030707210705.L76269@bullseye.apana.org.au> On Mon, 7 Jul 2003, Delaney, Timothy C (Timothy) wrote: > test test_socket failed -- Traceback (most recent call last): > File "/usr/home/Tim/Python-2.3b2/Lib/test/test_socket.py", line 215, in > testCrucialConstants > socket.SOCK_RDM > AttributeError: 'module' object has no attribute 'SOCK_RDM' 5.x doesn't support that symbol yet... It would be nice if it did for 5.2... > test test_strptime failed -- Traceback (most recent call last): > File "/usr/home/Tim/Python-2.3b2/Lib/test/test_strptime.py", line 312, in > test_timezone > "LocaleTime().timezone has duplicate values but " > File "/usr/home/Tim/Python-2.3b2/Lib/unittest.py", line 268, in failUnless > if not expr: raise self.failureException, msg > AssertionError: LocaleTime().timezone has duplicate values but timzone value > not set to -1 > > This one is almost certainly my fault ;) But the error message is wrong I > think - it should read 'but timezone value' rather than 'but timzone value'. I don't think this is specific to FreeBSD - ISTR it being reported elsewhere (linux?). I think Brett C has this in hand. > test test_tempfile failed -- Traceback (most recent call last): > File "/usr/home/Tim/Python-2.3b2/Lib/test/test_tempfile.py", line 299, in > test_noinherit > self.failIf(retval > 0, "child process reports failure") > File "/usr/home/Tim/Python-2.3b2/Lib/unittest.py", line 264, in failIf > if expr: raise self.failureException, msg > AssertionError: child process reports failure This and some other failures that appear with specific resource settings should be resolved by recent checkins to configure.in/pyconfig.in (that add the __BSD_VISIBLE symbol). How recent was your source tree? My 5.1 box is much slower than my 4.8 box, which combined with gcc 3.2 taking longer to compile than 2.95 means I don't test the build on 5.1 as frequently as I'd like... -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From troels@2-10.org Mon Jul 7 15:38:52 2003 From: troels@2-10.org (Troels Therkelsen) Date: Mon, 7 Jul 2003 16:38:52 +0200 Subject: [Python-Dev] Deprecation warning 'assignment shadows builtin' doesn't take __builtins__ into account Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C344A6.403D6090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi python-dev, I noticed this behaviour: Python 2.3b2 (#1, Jun 30 2003, 13:04:39) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, new >>> d = {'__builtins__':{}} >>> d['mod'] = new.module('mod') >>> d['mod'].__builtins__ = d['__builtins__'] >>> exec "mod.reload = 42" in d :1: DeprecationWarning: assignment shadows builtin >>> d['sys'] = sys >>> exec "print sys._getframe().f_builtins" in d {} Surely, the DeprecationWarning shouldn't be printed if you use __builtins__ to explicitly define your own builtins dict? I mean, the 'reload' name in this case is an unknown name until it is defined in mod. I looked through the archive and found the thread which describes why this change was done, namely so that, eventually, the current builtin name checking can be moved from runtime to compile time. Shouldn't the compile time check be able to take __builtins__ into account? Assuming the answer to that is 'yes' then shouldn't the current DeprecationWarning also be able to deal with it? Looking into the code (Objects/moduleobject.c), I discovered that the code does deal with it, but since it assigns to a static variable, the builtin names are found once and then for every subsequent check, the previously calculated dict is used. However, doing this means that you get the errorenous (well, imho) warning above. And since DeprecationWarnings usually indicate that the operation will be illegal at some point, I wanted to ensure that custom builtins via __builtins__ doesn't have this error. Therefore, I submit for your approval/scorn/pointing and laughing the attached patch. It deals with the problem in a way that involves no change unless PyEval_GetBuiltins() returns a builtins dict different from PyThreadState_Get()->interp->builtin (the builtins dict should never change thus unless a custom __builtins__ is in effect as far as I can tell). In the case that a different builtins is detected, a local list of builtin names is used for that call to module_setattr(). The way the problem is solved is rather naive, I admit, but I didn't want to put any more work into it before I get confirmation from someone that I'm on the right track :-). One thing I don't understand is why the current code goes to all this trouble to create a new dict from the dict that PyEval_GetBuiltins() returns, instead of just checking directly. Ie., doing if (PyDict_GetItem(PyEval_GetBuiltins(), name) != NULL) { instead of int shadows = shadows_builtin(globals, name); if (shadows == 1) { I know that the latter will emulate a non-changable builtins dict, assuming that the first time this code is called, current_frame->f_builtins == PyThreadState_Get()->interp->builtins. As far as I can tell, this is a safe assumption. I also noticed that there's no test in Lib/test/test_module.py which verifies that shadowing builtin names raises a warning (and, indeed, that not shadowing one does not raise a warning). Is this intentional? I'm willing to write that simple test if should be there. Sorry for the long post, feel free to flog me with a wet fish ;-) Regards, Troels Therkelsen ------=_NextPart_000_0000_01C344A6.403D6090 Content-Type: application/octet-stream; name="py2.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="py2.diff" Index: Objects/moduleobject.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: = /var/local/cvs/python-tarball/python/dist/src/Objects/moduleobject.c,v=0A= retrieving revision 2.46=0A= diff -c -r2.46 moduleobject.c=0A= *** Objects/moduleobject.c 9 Jun 2003 18:41:54 -0000 2.46=0A= --- Objects/moduleobject.c 6 Jul 2003 23:55:58 -0000=0A= ***************=0A= *** 199,209 ****=0A= }=0A= =0A= static PyObject *=0A= ! find_builtin_names(void)=0A= {=0A= ! PyObject *builtins, *names, *key, *value;=0A= int pos =3D 0;=0A= - builtins =3D PyEval_GetBuiltins();=0A= if (builtins =3D=3D NULL || !PyDict_Check(builtins)) {=0A= PyErr_SetString(PyExc_SystemError, "no builtins dict!");=0A= return NULL;=0A= --- 199,208 ----=0A= }=0A= =0A= static PyObject *=0A= ! find_builtin_names(PyObject *builtins)=0A= {=0A= ! PyObject *names, *key, *value;=0A= int pos =3D 0;=0A= if (builtins =3D=3D NULL || !PyDict_Check(builtins)) {=0A= PyErr_SetString(PyExc_SystemError, "no builtins dict!");=0A= return NULL;=0A= ***************=0A= *** 224,247 ****=0A= return names;=0A= }=0A= =0A= /* returns 0 or 1 (and -1 on error) */=0A= static int=0A= shadows_builtin(PyObject *globals, PyObject *name)=0A= {=0A= static PyObject *builtin_names =3D NULL;=0A= ! if (builtin_names =3D=3D NULL) {=0A= ! builtin_names =3D find_builtin_names();=0A= ! if (builtin_names =3D=3D NULL)=0A= ! return -1;=0A= ! }=0A= ! if (!PyString_Check(name))=0A= return 0;=0A= ! if (PyDict_GetItem(globals, name) =3D=3D NULL &&=0A= ! PyDict_GetItem(builtin_names, name) !=3D NULL) {=0A= ! return 1;=0A= }=0A= else {=0A= ! return 0;=0A= }=0A= }=0A= =0A= --- 223,272 ----=0A= return names;=0A= }=0A= =0A= + static int=0A= + builtin_has_name(PyObject *builtins, PyObject *name)=0A= + {=0A= + PyObject *custom_builtins =3D find_builtin_names(builtins);=0A= + int ret;=0A= + =0A= + if (custom_builtins =3D=3D NULL) {=0A= + return -1;=0A= + }=0A= + =0A= + ret =3D (PyDict_GetItem(custom_builtins, name) !=3D NULL);=0A= + Py_DECREF(custom_builtins);=0A= + return ret;=0A= + }=0A= + =0A= /* returns 0 or 1 (and -1 on error) */=0A= static int=0A= shadows_builtin(PyObject *globals, PyObject *name)=0A= {=0A= static PyObject *builtin_names =3D NULL;=0A= ! PyObject *builtins =3D PyEval_GetBuiltins();=0A= ! =0A= ! if (!PyString_Check(name)=0A= ! || PyDict_GetItem(globals, name) !=3D NULL=0A= ! || builtins =3D=3D globals) {=0A= return 0;=0A= ! }=0A= ! =0A= ! if (builtins =3D=3D PyThreadState_Get()->interp->builtins) {=0A= ! if (builtin_names =3D=3D NULL) {=0A= ! builtin_names =3D find_builtin_names(builtins);=0A= ! if (builtin_names =3D=3D NULL) {=0A= ! return -1;=0A= ! }=0A= ! }=0A= ! if (PyDict_GetItem(builtin_names, name) !=3D NULL) {=0A= ! return 1;=0A= ! }=0A= ! else {=0A= ! return 0;=0A= ! }=0A= }=0A= else {=0A= ! return builtin_has_name(builtins, name);=0A= }=0A= }=0A= =0A= ***************=0A= *** 249,256 ****=0A= module_setattr(PyObject *m, PyObject *name, PyObject *value)=0A= {=0A= PyObject *globals =3D ((PyModuleObject *)m)->md_dict;=0A= ! PyObject *builtins =3D PyEval_GetBuiltins();=0A= ! if (globals !=3D NULL && globals !=3D builtins) {=0A= int shadows =3D shadows_builtin(globals, name);=0A= if (shadows =3D=3D 1) {=0A= if (PyErr_Warn(PyExc_DeprecationWarning,=0A= --- 274,280 ----=0A= module_setattr(PyObject *m, PyObject *name, PyObject *value)=0A= {=0A= PyObject *globals =3D ((PyModuleObject *)m)->md_dict;=0A= ! if (globals !=3D NULL) {=0A= int shadows =3D shadows_builtin(globals, name);=0A= if (shadows =3D=3D 1) {=0A= if (PyErr_Warn(PyExc_DeprecationWarning,=0A= ------=_NextPart_000_0000_01C344A6.403D6090-- From drifty@alum.berkeley.edu Mon Jul 7 18:44:16 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Mon, 07 Jul 2003 10:44:16 -0700 Subject: [Python-Dev] Deprecation warning 'assignment shadows builtin' doesn't take __builtins__ into account In-Reply-To: References: Message-ID: <3F09B170.7020300@ocf.berkeley.edu> Troels Therkelsen wrote: > Hi python-dev, > > I noticed this behaviour: > > Python 2.3b2 (#1, Jun 30 2003, 13:04:39) > [GCC 2.95.3 20010315 (release)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>>>import sys, new >>>>d = {'__builtins__':{}} >>>>d['mod'] = new.module('mod') >>>>d['mod'].__builtins__ = d['__builtins__'] >>>>exec "mod.reload = 42" in d > > :1: DeprecationWarning: assignment shadows builtin > >>>>d['sys'] = sys >>>>exec "print sys._getframe().f_builtins" in d > > {} > > Surely, the DeprecationWarning shouldn't be printed if you use > __builtins__ to explicitly define your own builtins dict? I mean, > the 'reload' name in this case is an unknown name until it is > defined in mod. > > Sorry for the long post, feel free to flog me with a wet fish ;-) > Trust me, Troels, there have been *much* longer. And the only reason anyone would want to flog you with an aquatic animal is because you attached the patch to the email instead of creating a SourceForge patch item at http://sourceforge.net/tracker/?group_id=5470&atid=305470 . If you could do that it would be really appreciated since doing changes to the patch can be tracked more easily. -Brett From lists@webcrunchers.com Mon Jul 7 20:50:14 2003 From: lists@webcrunchers.com (John D.) Date: Mon, 7 Jul 2003 12:50:14 -0700 Subject: [Python-Dev] mail.generator examples - anyone kknow where I can find them? Message-ID: Hi, I've been trying to understand the email.generator class. There are virtually NO examples showing how to "generate" an Email message. In the Email module: http://python.org/doc/current/lib/node397.html this URL has SOME examples, but no examples using "email.generator". Has anyone actually been able to figure out how to use it? I searched the web, and didn't come up with anything useful. Perhaps I'm using the wrong search keys. I've tried "message.generator examples" in all the search engines, and the 4 different search databases of Python, but (sigh) nothing. John From skip@pobox.com Mon Jul 7 20:56:46 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 7 Jul 2003 14:56:46 -0500 Subject: [Python-Dev] Re: [Spambayes] mail.generator examples - anyone kknow where I can find them? In-Reply-To: References: Message-ID: <16137.53374.3816.265404@montanaro.dyndns.org> python-list instead of python-dev would be a better place to post your request. John> I've been trying to understand the email.generator class. There John> are virtually NO examples showing how to "generate" an Email John> message. You might try poking around the Mailman 2.1 source code for examples: % find . -name '*.py' | xargs egrep -i generator ./admin/www/MMGenerator.py:"""Generator for the Mailman on-line documentation. ./admin/www/MMGenerator.py:class MMGenerator(Skeleton, Sidebar, Banner): ./Mailman/Handlers/Scrubber.py:from email.Generator import Generator ./Mailman/Handlers/Scrubber.py:# We're using a subclass of the standard Generator because we want to suppress ./Mailman/Handlers/Scrubber.py:# sub-Generators will get created passing only mangle_from_ and maxheaderlen ./Mailman/Handlers/Scrubber.py:class ScrubberGenerator(Generator): ./Mailman/Handlers/Scrubber.py: Generator.__init__(self, outfp, mangle_from_=0) ./Mailman/Handlers/Scrubber.py: Generator._write_headers(self, msg) ./Mailman/Handlers/ToDigest.py:from email.Generator import Generator ./Mailman/Handlers/ToDigest.py: g = Generator(mboxfp) ./Mailman/Handlers/ToDigest.py: g = Generator(plainmsg) ./Mailman/ListAdmin.py:from email.Generator import Generator ./Mailman/ListAdmin.py: g = Generator(fp) ./Mailman/ListAdmin.py: g = Generator(outfp) ./Mailman/Mailbox.py:from email.Generator import Generator ./Mailman/Mailbox.py: # Create a Generator instance to write the message to the file ./Mailman/Mailbox.py: g = Generator(self.fp) Skip From cavok@filibusta.crema.unimi.it Tue Jul 8 11:15:58 2003 From: cavok@filibusta.crema.unimi.it (Domenico Andreoli) Date: Tue, 8 Jul 2003 12:15:58 +0200 Subject: [Python-Dev] donating python-crack module In-Reply-To: <200307041428.h64ESnZ21916@pcp02138704pcs.reston01.va.comcast.net> References: <20030704114838.GA18542@filibusta.crema.unimi.it> <200307041245.h64CjrT21762@pcp02138704pcs.reston01.va.comcast.net> <20030704133724.GA13684@filibusta.crema.unimi.it> <200307041428.h64ESnZ21916@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <20030708101558.GA16141@filibusta.crema.unimi.it> --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 04, 2003 at 10:28:49AM -0400, Guido van Rossum wrote: > > it is already available on savannah, licensed under GPL. what's wrong > > with GPL? the story about not being usable with non-GPL software? >=20 > Many businesses prefer not to use GPL software, and I believe that if > Python itself had been GPL'ed it would not have become the success it > is now. None of the major OS languages (Perl, Python, Tcl) are GPL. >=20 > But it's up to you, and I know there are dissenting opinions, and I > don't want this debate here turning into a flamewar, so I'll leave the > choice of license up to you, the author. >=20 i'm a sustainer of the GPL cause but for software little as mine i admit GPL is really overkill. i think i'll switch to MIT license in the next release. thanks domenico -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/CpneBneQM6IOvFARAo9wAKCxBNmt4y/Di0H3aZst2gWYEYJRZwCgy3OO 3SL0nk1uti3RGg8e+wAs+dw= =Uh34 -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From skip@pobox.com Tue Jul 8 23:00:45 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 8 Jul 2003 17:00:45 -0500 Subject: [Python-Dev] Why is python linked with c++? Message-ID: <16139.16141.291211.130239@montanaro.dyndns.org> I was just doinking around with the configure script to add an --enable-profiling flag. I notice that "c++" is used to link my python.exe (this on Mac OS X): % make c++ -Kthread -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python.exe \ Modules/python.o \ libpython2.3.a -ldl c++: unrecognized option `-Kthread' case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -bundle -bundle_loader python.exe' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python.exe -E ../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -bundle -bundle_loader python.exe' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python.exe -E ../setup.py build;; \ esac running build running build_ext ... I probably would have missed it except for the fact that I was keeping my eye on the emitted compile and link commands to see if there were problems. Since when is c++ required to link the interpreter? Can someone verify this problem? Thx, Skip From nas-python@python.ca Tue Jul 8 23:22:23 2003 From: nas-python@python.ca (Neil Schemenauer) Date: Tue, 8 Jul 2003 15:22:23 -0700 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <16139.16141.291211.130239@montanaro.dyndns.org> References: <16139.16141.291211.130239@montanaro.dyndns.org> Message-ID: <20030708222223.GB4059@glacier.arctrix.com> Skip Montanaro wrote: > I was just doinking around with the configure script to add an > --enable-profiling flag. I notice that "c++" is used to link my python.exe > (this on Mac OS X): I remember this used to be the case on Linux bug I made a change that undid it: revision 1.199 date: 2001/01/27 21:39:17; author: nascheme; state: Exp; lines: +9 -6 - Remove Guido's LINKCC=CXX experiment. - Cygwin doesn't want CCSHARED flag when bulding the interpreter DLL. The current configure script sets LINKCC to CXX if CXX is set. CXX gets set if you provide --with-cxx=. It looks like CXX may also get automatically set: dnl Autoconf 2.5x does not have AC_PROG_CXX_WORKS anymore ifdef([AC_PROG_CXX_WORKS],[], [AC_DEFUN([AC_PROG_CXX_WORKS], [AC_LANG_PUSH(C++)dnl _AC_COMPILER_EXEEXT AC_LANG_POP() ] )]) if test "$check_cxx" = "yes" then AC_CHECK_PROGS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound) if test "$CXX" = "notfound" then CXX= else AC_PROG_CXX_WORKS fi fi You should be able to explicitly disable C++ using --without-cxx. In any case, I would say the behavior is intentional. Neil From dave@boost-consulting.com Wed Jul 9 01:00:12 2003 From: dave@boost-consulting.com (David Abrahams) Date: Tue, 08 Jul 2003 20:00:12 -0400 Subject: [Python-Dev] What is "installed"? Message-ID: This will sound like a heap of complaint, but there really is a point (at the end)... As someone who needs to build Python from sources (often CVS sources) on Win32, and sometimes even modify them, I have often been frustrated by the fact that many tools seem to think Python isn't "installed" unless I've run some installer. For example I think distutils still expects files such as pyconfig.h to be copied from my Python sources' PC/ subdirectory into its include/ subdirectory, which is annoying because it's a modification to my source tree that isn't performed automatically by the build process; when I update I don't want to have to remember to move files around manually. When developing Python extensions I just add the appropriate subdirectory (PC/ on Win32) to my #include path so I don't have to worry about this stuff. Now I'm getting stopped by a related problem: I need to install LEO, and it thinks there's no Python installed on my system, even though there's a perfectly good usable 'python.exe' in my path. Is it looking for something in my registry? I have no clue. So how do Python developers deal with these issues? Is there a smoother way? Am I making life difficult for myself? TIA, -- Dave Abrahams Boost Consulting www.boost-consulting.com From martin@v.loewis.de Wed Jul 9 06:40:47 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 09 Jul 2003 07:40:47 +0200 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <20030708222223.GB4059@glacier.arctrix.com> References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> Message-ID: Neil Schemenauer writes: > The current configure script sets LINKCC to CXX if CXX is set. No, it also checks if you can link C++ programs with CC, and uses CC to link if you can: # LINKCC is the command that links the python executable -- default is $(CC). # If CXX is set, and if it is needed to link a main function that was # compiled with CXX, LINKCC is CXX instead. Always using CXX is undesirable: # python might then depend on the C++ runtime # This is altered for AIX in order to build the export list before # linking. AC_SUBST(LINKCC) AC_MSG_CHECKING(LINKCC) if test -z "$LINKCC" then if test -z "$CXX"; then LINKCC="\$(PURIFY) \$(CC)" else echo 'void foo();int main(){foo();}void foo(){}' > conftest.$ac_ext $CXX -c conftest.$ac_ext 2>&5 if $CC -o conftest$ac_exeext conftest.$ac_objext 2>&5 \ && test -s conftest$ac_exeext && ./conftest$ac_exeext then LINKCC="\$(PURIFY) \$(CC)" else LINKCC="\$(PURIFY) \$(CXX)" fi rm -fr conftest* fi case $ac_sys_system in AIX*) exp_extra="\"\"" if test $ac_sys_release -ge 5 -o \ $ac_sys_release -eq 4 -a `uname -r` -ge 2 ; then exp_extra="." fi LINKCC="\$(srcdir)/Modules/makexp_aix Modules/python.exp $exp_extra \$(LIBRARY); $LINKCC";; dgux*) LINKCC="LD_RUN_PATH=$libdir $LINKCC";; Monterey64*) LINKCC="$LINKCC -L/usr/lib/ia64l64";; esac fi AC_MSG_RESULT($LINKCC) This change was needed to support various C++ compilers that would fail to link Modules/ccpython.cc with the C compiler. Regards, Martin From martin@v.loewis.de Wed Jul 9 06:44:17 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 09 Jul 2003 07:44:17 +0200 Subject: [Python-Dev] What is "installed"? In-Reply-To: References: Message-ID: David Abrahams writes: > So how do Python developers deal with these issues? I use Linux, and do 'make install', which puts everything into /usr/local. I have changed permissions on /usr/local so that I don't need to be root to put things there. I found Windows to be too painful for any kind of software development, so I use it only if I need to release software, or investigate bugs that only occur on Windows (at which times it is still painful). Regards, Martin From mhammond@skippinet.com.au Wed Jul 9 09:24:06 2003 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 9 Jul 2003 18:24:06 +1000 Subject: [Python-Dev] What is "installed"? In-Reply-To: Message-ID: <000a01c345f3$776ae710$f501a8c0@eden> > So how do Python developers deal with these issues? Is there a > smoother way? Am I making life difficult for myself? I generally setup the registry, by adding an "InstallPath" key. Most extensions then work correctly, including distutils. Now that we have the "_winreg" module, we should include a simple script you can run to setup everything you need. FYI, all you should need is: HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\InstallPath: pydir HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath: pydir\lib;pydir\pcbuild where: * "pydir" is the path to main Python directory - ie, parent of "PCBuild", "Modules" etc * The "2.3" is actually available in sys.winver * The "PythonPath" entry is generally not needed, except in embedding situations where the Python DLL isn't in the main Python build directory. Mark. From theller@python.net Wed Jul 9 09:28:41 2003 From: theller@python.net (Thomas Heller) Date: Wed, 09 Jul 2003 10:28:41 +0200 Subject: [Python-Dev] What is "installed"? In-Reply-To: (David Abrahams's message of "Tue, 08 Jul 2003 20:00:12 -0400") References: Message-ID: <8yr8rtmu.fsf@python.net> David Abrahams writes: > This will sound like a heap of complaint, but there really is a point > (at the end)... > > As someone who needs to build Python from sources (often CVS sources) > on Win32, and sometimes even modify them, I have often been frustrated > by the fact that many tools seem to think Python isn't "installed" > unless I've run some installer. > > For example I think distutils still expects files such as pyconfig.h > to be copied from my Python sources' PC/ subdirectory into its > include/ subdirectory, which is annoying because it's a modification > to my source tree that isn't performed automatically by the build > process; when I update I don't want to have to remember to move files > around manually. When developing Python extensions I just add the > appropriate subdirectory (PC/ on Win32) to my #include path so I don't > have to worry about this stuff. > > Now I'm getting stopped by a related problem: I need to install LEO, > and it thinks there's no Python installed on my system, even though > there's a perfectly good usable 'python.exe' in my path. Is it > looking for something in my registry? I have no clue. > > So how do Python developers deal with these issues? Is there a > smoother way? Am I making life difficult for myself? Does this help? http://effbot.org/zone/python-register.htm Thomas From troels@2-10.org Wed Jul 9 14:30:50 2003 From: troels@2-10.org (Troels Therkelsen) Date: Wed, 9 Jul 2003 15:30:50 +0200 Subject: SV: [Python-Dev] Deprecation warning 'assignment shadows builtin' doesn't take __builtins__ into account In-Reply-To: <3F09B170.7020300@ocf.berkeley.edu> Message-ID: > > > > Sorry for the long post, feel free to flog me with a wet fish ;-) > > > > Trust me, Troels, there have been *much* longer. And the only reason > anyone would want to flog you with an aquatic animal is because you > attached the patch to the email instead of creating a SourceForge patch > item at http://sourceforge.net/tracker/?group_id=5470&atid=305470 . If > you could do that it would be really appreciated since doing changes to > the patch can be tracked more easily. > Ok, I submitted it as a patch (768442 if anyone is interested) :-) Brett, thanks for the pointer. Now, one question still remains. Should Lib/test/test_module.py be updated to check for this new behaviour or not? Even if my patch is never added to Python, surely the current (imho faulty) behaviour should be tested for, shouldn't it? I don't mind writing the needed tests, I just don't want to waste my time doing it if it's not needed =) Regards, Troels Therkelsen From dave@boost-consulting.com Wed Jul 9 14:32:13 2003 From: dave@boost-consulting.com (David Abrahams) Date: Wed, 09 Jul 2003 09:32:13 -0400 Subject: [Python-Dev] What is "installed"? In-Reply-To: ( =?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "09 Jul 2003 07:44:17 +0200") References: Message-ID: martin@v.loewis.de (Martin v. L=F6wis) writes: > David Abrahams writes: > >> So how do Python developers deal with these issues? > > I use Linux, and do 'make install', which puts everything into > /usr/local. I have changed permissions on /usr/local so that I don't > need to be root to put things there. > > I found Windows to be too painful for any kind of software > development, so I use it only if I need to release software, or > investigate bugs that only occur on Windows (at which times it is > still painful). Clearly the position of a partisan. You're missing out on some wonderful debugging facilities. GDB et al still can't touch Visual Studio. --=20 Dave Abrahams Boost Consulting www.boost-consulting.com From aahz@pythoncraft.com Wed Jul 9 14:46:06 2003 From: aahz@pythoncraft.com (Aahz) Date: Wed, 9 Jul 2003 09:46:06 -0400 Subject: SV: [Python-Dev] Deprecation warning 'assignment shadows builtin' doesn't take __builtins__ into account In-Reply-To: References: <3F09B170.7020300@ocf.berkeley.edu> Message-ID: <20030709134606.GA8393@panix.com> On Wed, Jul 09, 2003, Troels Therkelsen wrote: > > Now, one question still remains. Should Lib/test/test_module.py be > updated to check for this new behaviour or not? Even if my patch is > never added to Python, surely the current (imho faulty) behaviour > should be tested for, shouldn't it? I don't mind writing the needed > tests, I just don't want to waste my time doing it if it's not needed > =) Tests are always welcome. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Not everything in life has a clue in front of it...." --JMS From guido@python.org Wed Jul 9 15:23:16 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 09 Jul 2003 10:23:16 -0400 Subject: [Python-Dev] Moving to California Message-ID: <200307091423.h69ENGO10695@pcp02138704pcs.reston01.va.comcast.net> Dear Python developers, Last night at OSCON I announced that I am moving to California. I have accepted a new job at Elemental Security, a security software startup in San Mateo. You may have heard of one of the founders, Dan Farmer, who is the (co-)author of several well-known free security checking programs: Satan, Titan and The Coroner's Toolkit. Elemental is a brand new company, and I can't say much yet about the product, except that it will be aimed at enterprise security and use Python. I'm very excited about working with Dan on its design and implementation. I'm also excited about moving to California, which has long been a dream of mine. I'm looking forward to getting together with the many local Python users and developers once I'm settled; right now, my life and that if my family is total chaos because we're trying to find a home and move into it by August 1st. Which brings me to Python. I will still have time for Python (it's in my contract) and I will continue to lead Python's development. In fact, once the dust of the move is settled, I expect to be more available for Python than I've been recently at Zope. But in the mean time, I'm largely dependent on the Python community and especially the great folks at PythonLabs (whom I am sadly leaving behind at Zope) to make sure that Python 2.3 comes out on time -- remember, we need to have the final out by August 1st to make Apple's Panther release of Mac OS X. I'm confident that this is possible. In the mean time, I'm here at OSCON with a busy schedule and limited access to my email, and the following weeks I will be in transition, so please be kind if I don't reply immediate when you write me. --Guido van Rossum (home page: http://www.python.org/~guido/) PS. guido@zope.com no longer works. Please use guido@python.org! From barry@python.org Wed Jul 9 15:58:39 2003 From: barry@python.org (Barry Warsaw) Date: 09 Jul 2003 10:58:39 -0400 Subject: [Python-Dev] Python 2.3 release schedule update Message-ID: <1057762719.7056.11.camel@yyz> Here is the updated plan for the Python 2.3 release. Remember that we have to release by August 1st in order to meet Apple's plans for Panther. I think we're very close, so this doesn't seem like an unreasonable milestone to meet. The plan is to release 2.3rc1 on July 17, 2003. I'll be out of town, so Jeremy will do this release, with the usual help from Fred and Tim. If we find that an rc2 is necessary, I will make that release on July 24, 2003, with a final release on July 31, 2003. If rc2 is not necessary, I would like to release Python 2.3 final a week early, i.e. July 24, 2003. Our schedule is already tight for Apple, so it would be nice to have a little extra breathing room if possible. I've updated PEP 283 to reflect this schedule. Please help by testing the current cvs and/or beta2 as much as possible. If you have critical fixes for 2.3 final, please get them in now -- don't wait until the last minute. Please be very conservative in what you check in between now and rc1. ssshhh!-don't-tell-guido-ly y'rs, -Barry From skip@pobox.com Wed Jul 9 16:41:22 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 9 Jul 2003 10:41:22 -0500 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> Message-ID: <16140.14242.937722.379766@montanaro.dyndns.org> Martin> This change was needed to support various C++ compilers that Martin> would fail to link Modules/ccpython.cc with the C compiler. What is ccpython.cc and why do I need it? I don't see it used during the build process. Regardless whether c++ is supposed to be used to link python.exe on Mac OS X or not, there is still a bug that needs fixing: ... ar cr libpython2.3.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o ranlib libpython2.3.a c++ -Kthread -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python.exe \ Modules/python.o \ libpython2.3.a -ldl c++: unrecognized option `-Kthread' ... Skip From drifty@alum.berkeley.edu Wed Jul 9 18:26:07 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Wed, 09 Jul 2003 10:26:07 -0700 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <1057762719.7056.11.camel@yyz> References: <1057762719.7056.11.camel@yyz> Message-ID: <3F0C502F.70209@ocf.berkeley.edu> Barry Warsaw wrote: > Here is the updated plan for the Python 2.3 release. Remember that we > have to release by August 1st in order to meet Apple's plans for > Panther. I think we're very close, so this doesn't seem like an > unreasonable milestone to meet. > > The plan is to release 2.3rc1 on July 17, 2003. I'll be out of town, so > Jeremy will do this release, with the usual help from Fred and Tim. > > If we find that an rc2 is necessary, I will make that release on July > 24, 2003, with a final release on July 31, 2003. So, I am going to be out of town for my younger brother's wedding starting Sunday and won't be back until July 21. During that time I will have no Net. I will obviously do what I can between now and Sunday to help. But in case I can't get everything done, there are only three things assigned to me that if I can't solve in time I would appreciate someone closing for me. One is http://www.python.org/sf/762934 which is a patch for the detection of time.tzset . It makes it more stringent by adding a check in the code just like the one in the regression test that keeps failing on various platforms. I have a comment on what needs to be changed, but they are all syntactic. The reason I have not applied it already is that it makes the detection pickier and thus will change what platforms get tzset compared to b2 and thus I am not sure how to proceed. I was also waiting for someone to apply the patch to see if it solves their bug they haven't yet so I am not holding my breath for a response. Another is http://www.python.org/sf/763708 which is a failing test for macostools. Jack has said that I am basically the only person he has found who has the failure consistently. I am going to do my darndest to solve this before I leave but I have *zero* experience with any of the MacPython code so if anyone else out there is getting a failure please speak up. And the last one is http://www.python.org/sf/762963 which is a patch for Modules/timemodule.c that normalizes the timezone since there seems to be a loss in info because of the way the code drops the GMT offset. The patch is very trivial but there is a suggestion about autoconf that I have no experience with and was going to research. My priority is the macostools bug, then the tzset one, and then the timemodule.c . Hopefully I will get to all of them but as Sunday approaches I am becoming less and less sure. -Brett From shane@zope.com Wed Jul 9 19:09:00 2003 From: shane@zope.com (Shane Hathaway) Date: Wed, 09 Jul 2003 14:09:00 -0400 Subject: [Python-Dev] What is "installed"? In-Reply-To: References: ( Martin v. Löwis's message of "09 Jul 2003 07:44:17 +0200") Message-ID: <3F0C5A3C.8030004@zope.com> David Abrahams wrote: > martin@v.loewis.de (Martin v. L=F6wis) writes: >>I found Windows to be too painful for any kind of software >>development, so I use it only if I need to release software, or >>investigate bugs that only occur on Windows (at which times it is >>still painful). >=20 > Clearly the position of a partisan. You're missing out on some > wonderful debugging facilities. GDB et al still can't touch Visual > Studio. And Visual Studio can't touch GDB. When you're thousands of miles away=20 from the server you're debugging and you have only an SSH connection,=20 GDB suddenly has a wonderful UI. :-) Shane From guido@python.org Wed Jul 9 19:24:06 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 09 Jul 2003 14:24:06 -0400 Subject: [Python-Dev] Need help with urllib/urllib2 (SF bug 549151) Message-ID: <200307091824.h69IO6t11876@pcp02138704pcs.reston01.va.comcast.net> Looking at my outstanding SF bugs/patches, I came across python.org/sf/549151 . John J Lee has given a good summary of what needs to be done, but I don't have time for it. Is there anyone else who can do this: > 1. Apply Guido's patch for urllib.py: guido.txt. The docs are > already correct. Already done. > 2. 301 in response to POST is still not redirected in urllib2. > urllib2.py.patch3 fixes that (note patch3, not patch2). It also > removes my Request.get_method method (which now seems like > overkill, as well as breaking the URL scheme-independence of > Request). Also fixes an exception message. Please make this the priority. > 3. liburllib2.tex.patch2 updates the docs to reflect the changes > in urllib2.py.patch3, rephrases a note and adds a missing method > description. > > 4. liburllib.tex.patch2: trivial rewording of docs for clarity. Doc updates are easy. > 5. Backport above changes to 2.2 bugfix branch. This can be put off. :-) Thanks! --Guido van Rossum (home page: http://www.python.org/~guido/) From martin@v.loewis.de Wed Jul 9 22:00:04 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 09 Jul 2003 23:00:04 +0200 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <16140.14242.937722.379766@montanaro.dyndns.org> References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > What is ccpython.cc and why do I need it? I don't see it used > during the build process. It might be MAINOBJ, and it is located Modules. Whether it is on your system, I don't know - see configure.in. > Regardless whether c++ is supposed to be used to link python.exe on Mac OS X > or not, there is still a bug that needs fixing: Can you submit a patch? Apparently, configure determines that -Kthread is supported on your system. If it isn't, you should find out why the test testing for it succeeds. Regards, Martin From skip@pobox.com Wed Jul 9 22:30:01 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 9 Jul 2003 16:30:01 -0500 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> Message-ID: <16140.35161.656121.992065@montanaro.dyndns.org> >> What is ccpython.cc and why do I need it? I don't see it used during >> the build process. Martin> It might be MAINOBJ, and it is located Modules. Whether it is on Martin> your system, I don't know - see configure.in. I think you misunderstood what I wrote. As far as I can tell, ccpython.cc is not compiled when building python.exe on my Mac. Accordingly, the link step should use gcc, not c++. >> Regardless whether c++ is supposed to be used to link python.exe on >> Mac OS X or not, there is still a bug that needs fixing: Martin> Can you submit a patch? Apparently, configure determines that Martin> -Kthread is supported on your system. If it isn't, you should Martin> find out why the test testing for it succeeds. The -Kthread thing is just a warning. gcc/g++ complains but completes the command, exiting with a 0 status. I tried adding -Werror and -Wall to the command line but the exit status was still 0. I think you need different check than the usual command completion to determine whether -Kthread should be given or not. If you can suggest some ways to do this with configure macros I will take a stab at it, but I don't understand autoconf/configure well enough. I suspect doing something like c++ -Kthread ... 2>&1 >/dev/null | egrep 'unrecognized option' is too fragile, but that may be the only sort of solution available. I took a quick look at a RH8 machine. Its gcc doesn't understand -Kthreads either. Maybe it's a safe assumption that if $CC == gcc -Kthreads should not be given. Skip From martin@v.loewis.de Wed Jul 9 22:49:28 2003 From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 09 Jul 2003 23:49:28 +0200 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <16140.35161.656121.992065@montanaro.dyndns.org> References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> Message-ID: <3F0C8DE8.3010403@v.loewis.de> Skip Montanaro wrote: > I think you misunderstood what I wrote. As far as I can tell, ccpython.cc > is not compiled when building python.exe on my Mac. Accordingly, the link > step should use gcc, not c++. This is uncertain. There is a configuration mechanism that determines whether you need the C++ compiler to link, and it comes to the conclusion that you do. It might be a bug that it not also tries compiling ccpython.cc, but so far, nobody has complained that it should > I think you need different check than the usual command completion to > determine whether -Kthread should be given or not. If you can suggest some > ways to do this with configure macros I will take a stab at it, but I don't > understand autoconf/configure well enough. I suspect doing something like > > c++ -Kthread ... 2>&1 >/dev/null | egrep 'unrecognized option' > > is too fragile, but that may be the only sort of solution available. It's not necessary to understand autoconf at all. Tell me what algorithm *you* use to determine that -Kthread is a bad idea, and I tell you how to translate it into autoconf. The current algorithm is not only supposed to find out whether -Kthread is available, but also if it has any effect - i.e. whether providing that option indeed enables the threads library which wouldn't be enabled without it. For some reason, it determines that -Kthread is supported and has the desired effect. Study config.log to find out what tests it performs, and why it then concludes that -Kthread is a good thing. > I took a quick look at a RH8 machine. Its gcc doesn't understand -Kthreads > either. Maybe it's a safe assumption that if $CC == gcc -Kthreads should > not be given. Hmm. On my machine, it concludes that it should use -pthread, which is supported and has the desired effect. A platform expert should be able to tell what to use on your system. Regards, Martin From skip@pobox.com Wed Jul 9 23:09:56 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 9 Jul 2003 17:09:56 -0500 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <3F0C8DE8.3010403@v.loewis.de> References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> <3F0C8DE8.3010403@v.loewis.de> Message-ID: <16140.37556.743704.816087@montanaro.dyndns.org> >> I think you need different check than the usual command completion to >> determine whether -Kthread should be given or not. If you can >> suggest some ways to do this with configure macros I will take a stab >> at it, but I don't understand autoconf/configure well enough. I >> suspect doing something like >> >> c++ -Kthread ... 2>&1 >/dev/null | egrep 'unrecognized option' >> >> is too fragile, but that may be the only sort of solution available. Martin> It's not necessary to understand autoconf at all. Tell me what Martin> algorithm *you* use to determine that -Kthread is a bad idea, Martin> and I tell you how to translate it into autoconf. I used my eyeballs. gcc/g++ as I've now posted a couple times complains about the -Kthread flag, but goes on to complete the command and exits with a 0 status. A bit of fiddling I did since my last post suggests it doesn't like -pthread either, at least not on Mac OS X. Martin> The current algorithm is not only supposed to find out whether Martin> -Kthread is available, but also if it has any effect - Martin> i.e. whether providing that option indeed enables the threads Martin> library which wouldn't be enabled without it. For some reason, Martin> it determines that -Kthread is supported and has the desired Martin> effect. It has the desired effect presumably because -Kthread isn't required. Gcc just emits the warning and ignores the flag. Skip From drifty@alum.berkeley.edu Wed Jul 9 23:54:25 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Wed, 09 Jul 2003 15:54:25 -0700 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <3F0C502F.70209@ocf.berkeley.edu> References: <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> Message-ID: <3F0C9D21.4030207@ocf.berkeley.edu> Brett C. wrote: > Barry Warsaw wrote: > >> Here is the updated plan for the Python 2.3 release. Remember that we >> have to release by August 1st in order to meet Apple's plans for >> Panther. I think we're very close, so this doesn't seem like an >> unreasonable milestone to meet. >> >> The plan is to release 2.3rc1 on July 17, 2003. I'll be out of town, so >> Jeremy will do this release, with the usual help from Fred and Tim. >> >> If we find that an rc2 is necessary, I will make that release on July >> 24, 2003, with a final release on July 31, 2003. > > > So, I am going to be out of town for my younger brother's wedding > starting Sunday and won't be back until July 21. During that time I > will have no Net. > > I will obviously do what I can between now and Sunday to help. But in > case I can't get everything done, there are only three things assigned > to me that if I can't solve in time I would appreciate someone closing > for me. > > One is http://www.python.org/sf/762934 which is a patch for the > detection of time.tzset . It makes it more stringent by adding a check > in the code just like the one in the regression test that keeps failing > on various platforms. I have a comment on what needs to be changed, but > they are all syntactic. The reason I have not applied it already is > that it makes the detection pickier and thus will change what platforms > get tzset compared to b2 and thus I am not sure how to proceed. I was > also waiting for someone to apply the patch to see if it solves their > bug they haven't yet so I am not holding my breath for a response. > > Another is http://www.python.org/sf/763708 which is a failing test for > macostools. Jack has said that I am basically the only person he has > found who has the failure consistently. I am going to do my darndest to > solve this before I leave but I have *zero* experience with any of the > MacPython code so if anyone else out there is getting a failure please > speak up. > > And the last one is http://www.python.org/sf/762963 which is a patch for > Modules/timemodule.c that normalizes the timezone since there seems to > be a loss in info because of the way the code drops the GMT offset. The > patch is very trivial but there is a suggestion about autoconf that I > have no experience with and was going to research. > > My priority is the macostools bug, then the tzset one, and then the > timemodule.c . Hopefully I will get to all of them but as Sunday > approaches I am becoming less and less sure. > Quick update on the above items: * So the timemodule.c patch I closed and rejected. * The time.tzset patch I still need an all-clear from someone that it is okay to apply. * The macostools I researched and hit a brick wall when it passed into Carbon API land. I will have to work with someone to get this one solved. -Brett From jjl@pobox.com Thu Jul 10 01:02:27 2003 From: jjl@pobox.com (John J Lee) Date: Thu, 10 Jul 2003 01:02:27 +0100 (BST) Subject: [Python-Dev] Need help with urllib/urllib2 (SF bug 549151) Message-ID: Guido wrote (in SF tracker for bug #549151): > Feel free to assign this to yourself if you want to grab it. If this was directed at me: I'm not a Python SF admin. I'm happy to re-check & apply the patches, but it's up to you to decide whether it's worth the bother to add me as an admin just for that one thing. I suppose I do have some other urllib2 patches-in-progress, but no obvious need for me to be an admin for that, either. Incidentally, one of the patches, RFE 759792 (which I posted recently), eliminates the need for most of my other patches, since they can then be written as classes to be passed to urllib2.build_opener, as if they were handler classes. I'd be grateful for any comments on that (I know, wait until 2.3 is out...). [Most of the others are either unposted as yet or only posted as place-holders.] BTW, I guess it's too late to get rid of urllib2.Request.get_method, since that got into 2.2.3. [It's true that, thanks to yours truly, 2.2.3's urllib2 is broken (there's a typo in the redirect code, believe it or not), but that doesn't make it OK to introduce a new method, then immediately yank it out again, I suppose!] John From tim.one@comcast.net Thu Jul 10 02:33:58 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 9 Jul 2003 21:33:58 -0400 Subject: [Python-Dev] What is "installed"? In-Reply-To: <000a01c345f3$776ae710$f501a8c0@eden> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C34661.CE436080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Another possibility is to use the native Windows facilities for fiddling the registry. For example, edit the attached .reg file to taste, then right-click on it in Explorer and select Merge from the context menu. Or you can just double-click its icon. ------=_NextPart_000_000A_01C34661.CE436080 Content-Type: application/octet-stream; name="py22.reg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="py22.reg" REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Python\PythonCore] [HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.2] [HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.2\InstallPath] @="C:\\PYTHON22" ------=_NextPart_000_000A_01C34661.CE436080-- From martin@v.loewis.de Thu Jul 10 06:11:34 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 10 Jul 2003 07:11:34 +0200 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <16140.37556.743704.816087@montanaro.dyndns.org> References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> <3F0C8DE8.3010403@v.loewis.de> <16140.37556.743704.816087@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > It has the desired effect presumably because -Kthread isn't required. Gcc > just emits the warning and ignores the flag. That alone is not the desired effect. You also want to that, with -Kthread, functions like pthread_create become available, and calling these functions should succeed. Can you find out what the value of ac_cv_pthread_is_default is inside configure on your system? Regards, Martin From jjl@pobox.com Thu Jul 10 13:45:14 2003 From: jjl@pobox.com (John J Lee) Date: Thu, 10 Jul 2003 13:45:14 +0100 (BST) Subject: [Python-Dev] Re: cookie support for FancyURLopener? Message-ID: Randy wrote: > I have never contributed to the python source, but I am considering > adding cookie support to the FancyURLopener library, especially in the I presume you're planning to use my code, since you mailed me about it earlier. IMHO, it's not yet in any fit state to put forward for inclusion in the Python library. I hope to get it there in time for 2.4. Actually, how late is it possible to be in the release cycle and still get something like this in? And, more importantly, do people have an opinion on whether cookie support is appropriate in the standard library? My code is rather long -- is that a problem, if I'm prepared to maintain it myself? For various reasons, it'll get shorter than it is ATM, but it's unavoidably complicated if you want to get it right, I'm afraid. Anyway, that said, Randy, there's nothing to stop you writing the glue code to give urllib cookie support now (I already have urllib2 glue code). That might be useful: my last attempt at a urllib patch tells me that, since I don't use urllib, I'd probably mess it up ;-( OTOH, personally, I don't like the idea of extending urllib any further. Does urllib actually do anything that urllib2 doesn't do better? Maybe it should be deprecated (I don't mean scheduled for removal, of course, just marked as being the wrong thing for new code)? I think that would be useful, because people seem to be afraid of urllib2 -- perhaps simply because the docs look longer than they are thanks to the large number of sections. If that were done, I suppose the various little functions in there (urlencode, quote, quote_plus, etc.) would have to find a new home. BTW, anybody know how to follow-up to a thread when you don't have the original message in your mail client? John From aahz@pythoncraft.com Thu Jul 10 14:14:48 2003 From: aahz@pythoncraft.com (Aahz) Date: Thu, 10 Jul 2003 09:14:48 -0400 Subject: [Python-Dev] Re: cookie support for FancyURLopener? In-Reply-To: References: Message-ID: <20030710131447.GA12277@panix.com> On Thu, Jul 10, 2003, John J Lee wrote: > > Actually, how late is it possible to be in the release cycle and still get > something like this in? And, more importantly, do people have an opinion > on whether cookie support is appropriate in the standard library? My code > is rather long -- is that a problem, if I'm prepared to maintain it > myself? For various reasons, it'll get shorter than it is ATM, but it's > unavoidably complicated if you want to get it right, I'm afraid. Brand new module? Never after first beta, probably best to make sure it's ready at least a month before first beta. > BTW, anybody know how to follow-up to a thread when you don't have the > original message in your mail client? If you've got the Message-ID, just stick in the References: line (like a netnews post). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Not everything in life has a clue in front of it...." --JMS From jjl@pobox.com Thu Jul 10 14:23:28 2003 From: jjl@pobox.com (John J Lee) Date: Thu, 10 Jul 2003 14:23:28 +0100 (BST) Subject: [Python-Dev] Re: cookie support for FancyURLopener? In-Reply-To: <20030710131447.GA12277@panix.com> Message-ID: On Thu, 10 Jul 2003, Aahz wrote: [...] > Brand new module? Never after first beta, probably best to make sure > it's ready at least a month before first beta. [...] What might that translate into in terms of time, for 2.4? The bugfix releases on python.org (2.2.3, 2.1.3, 2.01 etc.) seem to be about a year apart, so I guess the major releases are about the same, with the beta period being only a month or so? Plenty of time if so! Thanks for the follow-up tip. John From randy.gamage@modicon.com Thu Jul 10 14:26:20 2003 From: randy.gamage@modicon.com (randy.gamage@modicon.com) Date: Thu, 10 Jul 2003 09:26:20 -0400 Subject: [Python-Dev] Re: cookie support for FancyURLopener? Message-ID: John, I wrote that e-mail before I found your ClientCookie library. I was naive in thinking that it would be a simple hack to add cookie support - your library shows that it's a significant amount of work, and from my experience, your code works very well. As for incorporating into Python or not, that's not my decision, but for convenience, it would be nice for many users if that was the case. Randy ==================== Randy Gamage Schneider Electric Ethernet Architect randy.gamage@modicon.com 978-975-9330 John J Lee To: randy.gamage@modicon.com cc: python-dev@python.org 07/10/2003 08:45 Subject: Re: cookie support for FancyURLopener? AM Randy wrote: > I have never contributed to the python source, but I am considering > adding cookie support to the FancyURLopener library, especially in the I presume you're planning to use my code, since you mailed me about it earlier. IMHO, it's not yet in any fit state to put forward for inclusion in the Python library. I hope to get it there in time for 2.4. Actually, how late is it possible to be in the release cycle and still get something like this in? And, more importantly, do people have an opinion on whether cookie support is appropriate in the standard library? My code is rather long -- is that a problem, if I'm prepared to maintain it myself? For various reasons, it'll get shorter than it is ATM, but it's unavoidably complicated if you want to get it right, I'm afraid. Anyway, that said, Randy, there's nothing to stop you writing the glue code to give urllib cookie support now (I already have urllib2 glue code). That might be useful: my last attempt at a urllib patch tells me that, since I don't use urllib, I'd probably mess it up ;-( OTOH, personally, I don't like the idea of extending urllib any further. Does urllib actually do anything that urllib2 doesn't do better? Maybe it should be deprecated (I don't mean scheduled for removal, of course, just marked as being the wrong thing for new code)? I think that would be useful, because people seem to be afraid of urllib2 -- perhaps simply because the docs look longer than they are thanks to the large number of sections. If that were done, I suppose the various little functions in there (urlencode, quote, quote_plus, etc.) would have to find a new home. BTW, anybody know how to follow-up to a thread when you don't have the original message in your mail client? John From aahz@pythoncraft.com Thu Jul 10 14:40:29 2003 From: aahz@pythoncraft.com (Aahz) Date: Thu, 10 Jul 2003 09:40:29 -0400 Subject: [Python-Dev] Re: cookie support for FancyURLopener? In-Reply-To: References: <20030710131447.GA12277@panix.com> Message-ID: <20030710134028.GA22212@panix.com> On Thu, Jul 10, 2003, John J Lee wrote: > On Thu, 10 Jul 2003, Aahz wrote: >> >> Brand new module? Never after first beta, probably best to make sure >> it's ready at least a month before first beta. > > What might that translate into in terms of time, for 2.4? The bugfix > releases on python.org (2.2.3, 2.1.3, 2.01 etc.) seem to be about a year > apart, so I guess the major releases are about the same, with the beta > period being only a month or so? Plenty of time if so! There hasn't been any discussion of a schedule for 2.4 yet. I'd guess the first beta won't be until at least January of next year. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Not everything in life has a clue in front of it...." --JMS From jeremy@zope.com Thu Jul 10 14:50:54 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 10 Jul 2003 09:50:54 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <1057762719.7056.11.camel@yyz> References: <1057762719.7056.11.camel@yyz> Message-ID: <1057845054.2600.19.camel@slothrop.zope.com> On Wed, 2003-07-09 at 10:58, Barry Warsaw wrote: > The plan is to release 2.3rc1 on July 17, 2003. I'll be out of town, so > Jeremy will do this release, with the usual help from Fred and Tim. If anyone has bugs or patches they'd like to see addressed before rc1, please make sure the priority is at 7 or higher so that they are easier to track. Jeremy From skip@pobox.com Thu Jul 10 15:17:00 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 10 Jul 2003 09:17:00 -0500 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> <3F0C8DE8.3010403@v.loewis.de> <16140.37556.743704.816087@montanaro.dyndns.org> Message-ID: <16141.30044.453979.807772@montanaro.dyndns.org> --z/AYhL4hXj Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Martin> Can you find out what the value of ac_cv_pthread_is_default is Martin> inside configure on your system? Sure. From config.log: configure:4205: checking whether pthreads are available without options configure:4235: gcc -o conftest -g -O2 -pg conftest.c >&5 configure:4238: $? = 0 configure:4240: ./conftest configure:4243: $? = 0 configure:4259: result: yes That suggests the following tests for -Kthread or -pthread are superfluous. I tried modifying configure.in in an obvious way (diff attached), but the generated configure file doesn't work, spewing a bunch of '=' characters to the display until I kill the process. The config.log doesn't show anything helpful. Skip --z/AYhL4hXj Content-Type: application/octet-stream Content-Disposition: attachment; filename="configure.in.diff" Content-Transfer-Encoding: base64 KioqIC90bXAvc2tpcC9jb25maWd1cmUuaW4ufjEuNDIzfjZmR080SglUaHUgSnVsIDEwIDA5 OjE0OjIzIDIwMDMKLS0tIC90bXAvc2tpcC9jb25maWd1cmUuaW42ZkdiQ1EJVGh1IEp1bCAx MCAwOToxNDoyMyAyMDAzCioqKioqKioqKioqKioqKgoqKiogNzkxLDc5NyAqKioqCiAgQUNf TVNHX1JFU1VMVCgkYWNfY3Zfa3B0aHJlYWQpCiAgZmkKICAKISBpZiB0ZXN0ICRhY19jdl9r cHRocmVhZCA9IG5vCiAgdGhlbgogICMgLUt0aHJlYWQsIGlmIGF2YWlsYWJsZSwgcHJvdmlk ZXMgdGhlIHJpZ2h0ICNkZWZpbmVzCiAgIyBhbmQgbGlua2VyIG9wdGlvbnMgdG8gbWFrZSBw dGhyZWFkX2NyZWF0ZSBhdmFpbGFibGUKLS0tIDc5MSw4MDAgLS0tLQogIEFDX01TR19SRVNV TFQoJGFjX2N2X2twdGhyZWFkKQogIGZpCiAgCiEgaWYgJGFjX2N2X3B0aHJlYWRfaXNfZGVm YXVsdCA9IHllcwohIHRoZW4KISAgICBhY19jdl9rdGhyZWFkPW5vCiEgZWxpZiB0ZXN0ICRh Y19jdl9rcHRocmVhZCA9IG5vCiAgdGhlbgogICMgLUt0aHJlYWQsIGlmIGF2YWlsYWJsZSwg cHJvdmlkZXMgdGhlIHJpZ2h0ICNkZWZpbmVzCiAgIyBhbmQgbGlua2VyIG9wdGlvbnMgdG8g bWFrZSBwdGhyZWFkX2NyZWF0ZSBhdmFpbGFibGUKKioqKioqKioqKioqKioqCioqKiA4MjIs ODI4ICoqKioKICBBQ19NU0dfUkVTVUxUKCRhY19jdl9rdGhyZWFkKQogIGZpCiAgCiEgaWYg dGVzdCAkYWNfY3Zfa3RocmVhZCA9IG5vCiAgdGhlbgogICMgLXB0aHJlYWQsIGlmIGF2YWls YWJsZSwgcHJvdmlkZXMgdGhlIHJpZ2h0ICNkZWZpbmVzCiAgIyBhbmQgbGlua2VyIG9wdGlv bnMgdG8gbWFrZSBwdGhyZWFkX2NyZWF0ZSBhdmFpbGFibGUKLS0tIDgyNSw4MzQgLS0tLQog IEFDX01TR19SRVNVTFQoJGFjX2N2X2t0aHJlYWQpCiAgZmkKICAKISBpZiAkYWNfY3ZfcHRo cmVhZF9pc19kZWZhdWx0ID0geWVzCiEgdGhlbgohICAgICBhY19jdl9wdGhyZWFkPW5vCiEg ZWxpZiB0ZXN0ICRhY19jdl9rdGhyZWFkID0gbm8KICB0aGVuCiAgIyAtcHRocmVhZCwgaWYg YXZhaWxhYmxlLCBwcm92aWRlcyB0aGUgcmlnaHQgI2RlZmluZXMKICAjIGFuZCBsaW5rZXIg b3B0aW9ucyB0byBtYWtlIHB0aHJlYWRfY3JlYXRlIGF2YWlsYWJsZQo= --z/AYhL4hXj-- From barry@python.org Thu Jul 10 15:28:49 2003 From: barry@python.org (Barry Warsaw) Date: 10 Jul 2003 10:28:49 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <3F0C9D21.4030207@ocf.berkeley.edu> References: <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> Message-ID: <1057847329.15764.1.camel@yyz> On Wed, 2003-07-09 at 18:54, Brett C. wrote: > * The time.tzset patch I still need an all-clear from someone that it is > okay to apply. I applied this patch, autoreconf'd and rebuilt from scratch on RH9. Everything seemed to work just fine. If that makes you feel confident enough to apply the patch for rc1, then go ahead. I don't have RH6.2 around to test on that so I don't know if it fixes the actual problem observed in the report. -Barry From pje@telecommunity.com Thu Jul 10 16:25:11 2003 From: pje@telecommunity.com (Phillip J. Eby) Date: Thu, 10 Jul 2003 11:25:11 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <1057847329.15764.1.camel@yyz> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> Message-ID: <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> At 10:28 AM 7/10/03 -0400, Barry Warsaw wrote: >On Wed, 2003-07-09 at 18:54, Brett C. wrote: > > > * The time.tzset patch I still need an all-clear from someone that it is > > okay to apply. > >I applied this patch, autoreconf'd and rebuilt from scratch on RH9. >Everything seemed to work just fine. If that makes you feel confident >enough to apply the patch for rc1, then go ahead. I don't have RH6.2 >around to test on that so I don't know if it fixes the actual problem >observed in the report. I do. Is this just a matter of checking out the current CVS HEAD and running make test? From barry@python.org Thu Jul 10 16:29:57 2003 From: barry@python.org (Barry Warsaw) Date: 10 Jul 2003 11:29:57 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> Message-ID: <1057850996.15764.11.camel@yyz> On Thu, 2003-07-10 at 11:25, Phillip J. Eby wrote: > At 10:28 AM 7/10/03 -0400, Barry Warsaw wrote: > >On Wed, 2003-07-09 at 18:54, Brett C. wrote: > > > > > * The time.tzset patch I still need an all-clear from someone that it is > > > okay to apply. > > > >I applied this patch, autoreconf'd and rebuilt from scratch on RH9. > >Everything seemed to work just fine. If that makes you feel confident > >enough to apply the patch for rc1, then go ahead. I don't have RH6.2 > >around to test on that so I don't know if it fixes the actual problem > >observed in the report. > > I do. Is this just a matter of checking out the current CVS HEAD and > running make test? You need to (or at least this is what I did): - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test The patch only modifies configure.in which is why you need to regenerate the configure file with autoreconf. -Barry From neal@metaslash.com Thu Jul 10 16:33:54 2003 From: neal@metaslash.com (Neal Norwitz) Date: Thu, 10 Jul 2003 11:33:54 -0400 Subject: [Python-Dev] Review popen fd leak fix Message-ID: <20030710153354.GM1237@epoch.metaslash.com> There are fd leaks in popen2 when exceptions occur. It would be nice to get the fix into 2.3. Could others review the patch attached to the bug: http://python.org/sf/761888 There may also be some relation to bug 768649, but I'm not sure since I can't reproduce the problem. Thanks, Neal From pje@telecommunity.com Thu Jul 10 17:39:43 2003 From: pje@telecommunity.com (Phillip J. Eby) Date: Thu, 10 Jul 2003 12:39:43 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <1057850996.15764.11.camel@yyz> References: <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> Message-ID: <5.1.1.6.0.20030710123908.03075890@telecommunity.com> At 11:29 AM 7/10/03 -0400, Barry Warsaw wrote: >You need to (or at least this is what I did): > >- check out the head >- make distclean >- apply the patch >- autoreconf >- ./configure --with-pydebug >- make test > >The patch only modifies configure.in which is why you need to regenerate >the configure file with autoreconf. Does that mean I need to have GNU autoconf? If so, what version? From mwh@python.net Thu Jul 10 17:48:29 2003 From: mwh@python.net (Michael Hudson) Date: Thu, 10 Jul 2003 17:48:29 +0100 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <5.1.1.6.0.20030710123908.03075890@telecommunity.com> ("Phillip J. Eby"'s message of "Thu, 10 Jul 2003 12:39:43 -0400") References: <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> <5.1.1.6.0.20030710123908.03075890@telecommunity.com> Message-ID: <2m3chemioy.fsf@starship.python.net> "Phillip J. Eby" writes: > At 11:29 AM 7/10/03 -0400, Barry Warsaw wrote: >>You need to (or at least this is what I did): >> >>- check out the head >>- make distclean >>- apply the patch >>- autoreconf >>- ./configure --with-pydebug >>- make test >> >>The patch only modifies configure.in which is why you need to regenerate >>the configure file with autoreconf. > > Does that mean I need to have GNU autoconf? If so, what version? Yes. 2.53 (not sure if that's "2.53 or above", if you're going to install an autoconf just for the sake of this excercise, install 2.53). Cheers, M. -- ARTHUR: Yes. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard". -- The Hitch-Hikers Guide to the Galaxy, Episode 1 From tim@multitalents.net Thu Jul 10 17:57:36 2003 From: tim@multitalents.net (Tim Rice) Date: Thu, 10 Jul 2003 09:57:36 -0700 (PDT) Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <16141.30044.453979.807772@montanaro.dyndns.org> References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> <3F0C8DE8.3010403@v.loewis.de> <16140.37556.743704.816087@montanaro.dyndns.org> <16141.30044.453979.807772@montanaro.dyndns.org> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-758783491-1057856256=:20112 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is a simpler patch you could try. On Thu, 10 Jul 2003, Skip Montanaro wrote: > > Martin> Can you find out what the value of ac_cv_pthread_is_default is > Martin> inside configure on your system? > > Sure. From config.log: > > configure:4205: checking whether pthreads are available without options > configure:4235: gcc -o conftest -g -O2 -pg conftest.c >&5 > configure:4238: $? = 0 > configure:4240: ./conftest > configure:4243: $? = 0 > configure:4259: result: yes > > That suggests the following tests for -Kthread or -pthread are superfluous. > I tried modifying configure.in in an obvious way (diff attached), but the > generated configure file doesn't work, spewing a bunch of '=' characters to > the display until I kill the process. The config.log doesn't show anything > helpful. > > Skip > > -- Tim Rice Multitalents (707) 887-1469 tim@multitalents.net ---559023410-758783491-1057856256=:20112 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="configure.in.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="configure.in.diff" LS0tIGNvbmZpZ3VyZS5pbi5vbGQJMjAwMy0wNy0xMCAwOTo0MTo1My44NzM3 NjAwMDAgLTA3MDANCisrKyBjb25maWd1cmUuaW4JMjAwMy0wNy0xMCAwOTo0 NDoxOS40NDg3MjAwMDAgLTA3MDANCkBAIC03NTEsNyArNzUxLDExIEBADQog ICByZXR1cm4gMDsNCiB9DQogXSwNCi0gIGFjX2N2X3B0aHJlYWRfaXNfZGVm YXVsdD15ZXMsDQorWw0KKyAgYWNfY3ZfcHRocmVhZF9pc19kZWZhdWx0PXll cw0KKyAgYWNfY3Zfa3RocmVhZD1ubw0KKyAgYWNfY3ZfcHRocmVhZD1ubw0K K10sDQogICBhY19jdl9wdGhyZWFkX2lzX2RlZmF1bHQ9bm8sDQogICBhY19j dl9wdGhyZWFkX2lzX2RlZmF1bHQ9bm8pDQogXSkNCg== ---559023410-758783491-1057856256=:20112-- From drifty@alum.berkeley.edu Thu Jul 10 18:03:34 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Thu, 10 Jul 2003 10:03:34 -0700 Subject: [Python-Dev] Need help with urllib/urllib2 (SF bug 549151) In-Reply-To: References: Message-ID: <3F0D9C66.5000500@ocf.berkeley.edu> John J Lee wrote: > Guido wrote (in SF tracker for bug #549151): > >>Feel free to assign this to yourself if you want to grab it. > > > If this was directed at me: I'm not a Python SF admin. I'm happy to > re-check & apply the patches, but it's up to you to decide whether it's > worth the bother to add me as an admin just for that one thing. > It was actually directed at all of the existing developers on python-dev. > BTW, I guess it's too late to get rid of urllib2.Request.get_method, since > that got into 2.2.3. [It's true that, thanks to yours truly, 2.2.3's > urllib2 is broken (there's a typo in the redirect code, believe it or > not), but that doesn't make it OK to introduce a new method, then > immediately yank it out again, I suppose!] > Did the 2.2 branch get patched with a fix for the typo? If not please make a patch since the 2.2 branch is going to be around for a while. As for removing the method, it has to be deprecated first since it has been in an actual release. -Brett From barry@python.org Thu Jul 10 18:05:13 2003 From: barry@python.org (Barry Warsaw) Date: 10 Jul 2003 13:05:13 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <5.1.1.6.0.20030710123908.03075890@telecommunity.com> References: <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> <5.1.1.6.0.20030710123908.03075890@telecommunity.com> Message-ID: <1057856713.15764.20.camel@yyz> On Thu, 2003-07-10 at 12:39, Phillip J. Eby wrote: > At 11:29 AM 7/10/03 -0400, Barry Warsaw wrote: > >You need to (or at least this is what I did): > > > >- check out the head > >- make distclean > >- apply the patch > >- autoreconf > >- ./configure --with-pydebug > >- make test > > > >The patch only modifies configure.in which is why you need to regenerate > >the configure file with autoreconf. > > Does that mean I need to have GNU autoconf? If so, what version? Yes, I think so. RH9 has autoconf 2.57. But I think older versions will work. -Barry From pje@telecommunity.com Thu Jul 10 18:08:15 2003 From: pje@telecommunity.com (Phillip J. Eby) Date: Thu, 10 Jul 2003 13:08:15 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <1057856713.15764.20.camel@yyz> References: <5.1.1.6.0.20030710123908.03075890@telecommunity.com> <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> <5.1.1.6.0.20030710112422.03022e60@telecommunity.com> <5.1.1.6.0.20030710123908.03075890@telecommunity.com> Message-ID: <5.1.1.6.0.20030710130742.023b5ec0@telecommunity.com> At 01:05 PM 7/10/03 -0400, Barry Warsaw wrote: >On Thu, 2003-07-10 at 12:39, Phillip J. Eby wrote: > > At 11:29 AM 7/10/03 -0400, Barry Warsaw wrote: > > >You need to (or at least this is what I did): > > > > > >- check out the head > > >- make distclean > > >- apply the patch > > >- autoreconf > > >- ./configure --with-pydebug > > >- make test > > > > > >The patch only modifies configure.in which is why you need to regenerate > > >the configure file with autoreconf. > > > > Does that mean I need to have GNU autoconf? If so, what version? > >Yes, I think so. RH9 has autoconf 2.57. I've got 2.57, so I'm checking out the head now. Looks like the checkout is going to take longer than the other steps will... :( From pje@telecommunity.com Thu Jul 10 20:53:21 2003 From: pje@telecommunity.com (Phillip J. Eby) Date: Thu, 10 Jul 2003 15:53:21 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <1057847329.15764.1.camel@yyz> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> Message-ID: <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> At 10:28 AM 7/10/03 -0400, Barry Warsaw wrote: >On Wed, 2003-07-09 at 18:54, Brett C. wrote: > > > * The time.tzset patch I still need an all-clear from someone that it is > > okay to apply. > >I applied this patch, autoreconf'd and rebuilt from scratch on RH9. >Everything seemed to work just fine. If that makes you feel confident >enough to apply the patch for rc1, then go ahead. I don't have RH6.2 >around to test on that so I don't know if it fixes the actual problem >observed in the report. No joy: test test_time failed -- Traceback (most recent call last): File "/home/admin/PythonCVS/dist/src/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/PythonCVS/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST This was on a clean HEAD checkout, applying the patch (762934), run 'autoreconf' in dist/src, followed by './configure --with-pydebug' and 'make test'. From skip@pobox.com Thu Jul 10 21:04:25 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 10 Jul 2003 15:04:25 -0500 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> <3F0C8DE8.3010403@v.loewis.de> <16140.37556.743704.816087@montanaro.dyndns.org> <16141.30044.453979.807772@montanaro.dyndns.org> Message-ID: <16141.50889.737066.126655@montanaro.dyndns.org> --14oPWSAz6+ Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Tim> Here is a simpler patch you could try. Thanks. That didn't work either, but led to a solution (attached) that did. Is there anyone out there who does require -Kthread or -pthread in their environment who can try this out? Let me know if you can't generate a configure script and I'll shoot my modified one to you. Skip --14oPWSAz6+ Content-Type: application/octet-stream Content-Disposition: attachment; filename="configure.in.diff" Content-Transfer-Encoding: base64 KioqIC90bXAvc2tpcC9jb25maWd1cmUuaW4ufjEuNDIzfjZmRzRaeAlUaHUgSnVsIDEwIDE1 OjAzOjA5IDIwMDMKLS0tIC90bXAvc2tpcC9jb25maWd1cmUuaW42ZkdxakEJVGh1IEp1bCAx MCAxNTowMzowOSAyMDAzCioqKioqKioqKioqKioqKgoqKiogNzUxLDc1NyAqKioqCiAgICBy ZXR1cm4gMDsKICB9CiAgXSwKISAgIGFjX2N2X3B0aHJlYWRfaXNfZGVmYXVsdD15ZXMsCiAg ICBhY19jdl9wdGhyZWFkX2lzX2RlZmF1bHQ9bm8sCiAgICBhY19jdl9wdGhyZWFkX2lzX2Rl ZmF1bHQ9bm8pCiAgXSkKLS0tIDc1MSw3NjEgLS0tLQogICAgcmV0dXJuIDA7CiAgfQogIF0s CiEgWwohICAgYWNfY3ZfcHRocmVhZF9pc19kZWZhdWx0PXllcwohICAgYWNfY3Zfa3RocmVh ZD1ubwohICAgYWNfY3ZfcHRocmVhZD1ubwohIF0sCiAgICBhY19jdl9wdGhyZWFkX2lzX2Rl ZmF1bHQ9bm8sCiAgICBhY19jdl9wdGhyZWFkX2lzX2RlZmF1bHQ9bm8pCiAgXSkKKioqKioq KioqKioqKioqCioqKiA3OTEsNzk3ICoqKioKICBBQ19NU0dfUkVTVUxUKCRhY19jdl9rcHRo cmVhZCkKICBmaQogIAohIGlmIHRlc3QgJGFjX2N2X2twdGhyZWFkID0gbm8KICB0aGVuCiAg IyAtS3RocmVhZCwgaWYgYXZhaWxhYmxlLCBwcm92aWRlcyB0aGUgcmlnaHQgI2RlZmluZXMK ICAjIGFuZCBsaW5rZXIgb3B0aW9ucyB0byBtYWtlIHB0aHJlYWRfY3JlYXRlIGF2YWlsYWJs ZQotLS0gNzk1LDgwMSAtLS0tCiAgQUNfTVNHX1JFU1VMVCgkYWNfY3Zfa3B0aHJlYWQpCiAg ZmkKICAKISBpZiB0ZXN0ICRhY19jdl9rcHRocmVhZCA9IG5vIC1hICRhY19jdl9wdGhyZWFk X2lzX2RlZmF1bHQgPSBubwogIHRoZW4KICAjIC1LdGhyZWFkLCBpZiBhdmFpbGFibGUsIHBy b3ZpZGVzIHRoZSByaWdodCAjZGVmaW5lcwogICMgYW5kIGxpbmtlciBvcHRpb25zIHRvIG1h a2UgcHRocmVhZF9jcmVhdGUgYXZhaWxhYmxlCioqKioqKioqKioqKioqKgoqKiogODIyLDgy OCAqKioqCiAgQUNfTVNHX1JFU1VMVCgkYWNfY3Zfa3RocmVhZCkKICBmaQogIAohIGlmIHRl c3QgJGFjX2N2X2t0aHJlYWQgPSBubwogIHRoZW4KICAjIC1wdGhyZWFkLCBpZiBhdmFpbGFi bGUsIHByb3ZpZGVzIHRoZSByaWdodCAjZGVmaW5lcwogICMgYW5kIGxpbmtlciBvcHRpb25z IHRvIG1ha2UgcHRocmVhZF9jcmVhdGUgYXZhaWxhYmxlCi0tLSA4MjYsODMyIC0tLS0KICBB Q19NU0dfUkVTVUxUKCRhY19jdl9rdGhyZWFkKQogIGZpCiAgCiEgaWYgdGVzdCAkYWNfY3Zf a3RocmVhZCA9IG5vIC1hICRhY19jdl9wdGhyZWFkX2lzX2RlZmF1bHQgPSBubwogIHRoZW4K ICAjIC1wdGhyZWFkLCBpZiBhdmFpbGFibGUsIHByb3ZpZGVzIHRoZSByaWdodCAjZGVmaW5l cwogICMgYW5kIGxpbmtlciBvcHRpb25zIHRvIG1ha2UgcHRocmVhZF9jcmVhdGUgYXZhaWxh YmxlCg== --14oPWSAz6+-- From aahz@pythoncraft.com Thu Jul 10 21:15:59 2003 From: aahz@pythoncraft.com (Aahz) Date: Thu, 10 Jul 2003 16:15:59 -0400 Subject: [Python-Dev] 2.3 startup speed? Message-ID: <20030710201559.GA5732@panix.com> What's the current status of the startup speed for Python 2.3? Did anyone ever check in fixes for that? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Not everything in life has a clue in front of it...." --JMS From python@rcn.com Thu Jul 10 21:20:13 2003 From: python@rcn.com (Raymond Hettinger) Date: Thu, 10 Jul 2003 16:20:13 -0400 Subject: [Python-Dev] 2.3 startup speed? References: <20030710201559.GA5732@panix.com> Message-ID: <006601c34720$aba8d540$125ffea9@oemcomputer> > What's the current status of the startup speed for Python 2.3? It's still more snail than racehorse. Raymond Hettinger From martin@v.loewis.de Thu Jul 10 21:30:49 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 10 Jul 2003 22:30:49 +0200 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <16141.50889.737066.126655@montanaro.dyndns.org> References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> <3F0C8DE8.3010403@v.loewis.de> <16140.37556.743704.816087@montanaro.dyndns.org> <16141.30044.453979.807772@montanaro.dyndns.org> <16141.50889.737066.126655@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > Thanks. That didn't work either, but led to a solution (attached) that did. > Is there anyone out there who does require -Kthread or -pthread in their > environment who can try this out? Let me know if you can't generate a > configure script and I'll shoot my modified one to you. It is part of the problem that those systems are not in wide use (SCO would be one of them; another would be Solaris with the native compiler). The patch looks right, please apply it. Regards, Martin From martin@v.loewis.de Thu Jul 10 21:32:15 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 10 Jul 2003 22:32:15 +0200 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <20030710201559.GA5732@panix.com> References: <20030710201559.GA5732@panix.com> Message-ID: Aahz writes: > Did anyone ever check in fixes for that? Yes, MAL checked in a patch, to remove re usage in encodings/__init__.py. Nobody ever verified whether this had any impact - most likely the impact was not significant. Regards, Martin From skip@pobox.com Thu Jul 10 21:44:38 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 10 Jul 2003 15:44:38 -0500 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> <3F0C8DE8.3010403@v.loewis.de> <16140.37556.743704.816087@montanaro.dyndns.org> <16141.30044.453979.807772@montanaro.dyndns.org> <16141.50889.737066.126655@montanaro.dyndns.org> Message-ID: <16141.53302.659976.764809@montanaro.dyndns.org> Martin> The patch looks right, please apply it. Done. Skip From skip@pobox.com Thu Jul 10 21:46:41 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 10 Jul 2003 15:46:41 -0500 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: References: <20030710201559.GA5732@panix.com> Message-ID: <16141.53425.276173.894077@montanaro.dyndns.org> Martin> Yes, MAL checked in a patch, to remove re usage in Martin> encodings/__init__.py. Nobody ever verified whether this had any Martin> impact - most likely the impact was not significant. I thought that part of the problem was continued attempts to look for modules in the usually non-existent python23.zip. I believe Just said something about the current structure requiring it to remain in sys.path even if it doesn't exist. Skip From barry@python.org Thu Jul 10 21:51:31 2003 From: barry@python.org (Barry Warsaw) Date: 10 Jul 2003 16:51:31 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> Message-ID: <1057870291.15764.109.camel@yyz> On Thu, 2003-07-10 at 15:53, Phillip J. Eby wrote: > No joy: Dang. That pretty much nails it for me. Please note that I will not be able to track this mailing list for about the next 11 days. Jeremy will be interim RM in the meantime. -Barry From just@letterror.com Thu Jul 10 22:34:19 2003 From: just@letterror.com (Just van Rossum) Date: Thu, 10 Jul 2003 23:34:19 +0200 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <16141.53425.276173.894077@montanaro.dyndns.org> Message-ID: Skip Montanaro wrote: > Martin> Yes, MAL checked in a patch, to remove re usage in > Martin> encodings/__init__.py. Nobody ever verified whether this had any > Martin> impact - most likely the impact was not significant. > > I thought that part of the problem was continued attempts to look for > modules in the usually non-existent python23.zip. I believe Just > said something about the current structure requiring it to remain in > sys.path even if it doesn't exist. Yes. I was hoping to find the time to work on the new import mechanism before b1, and then before b2, but didn't. While it's clear that a non-existing zip file on sys.path has _some_ effect, I'm not at all convinced it's the most significant source of the startup slowdown since 2.2. It would be great to know to what extent MAL's patch helped. Just From tim@multitalents.net Fri Jul 11 00:00:50 2003 From: tim@multitalents.net (Tim Rice) Date: Thu, 10 Jul 2003 16:00:50 -0700 (PDT) Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <16141.53302.659976.764809@montanaro.dyndns.org> References: <16139.16141.291211.130239@montanaro.dyndns.org> <20030708222223.GB4059@glacier.arctrix.com> <16140.14242.937722.379766@montanaro.dyndns.org> <16140.35161.656121.992065@montanaro.dyndns.org> <3F0C8DE8.3010403@v.loewis.de> <16140.37556.743704.816087@montanaro.dyndns.org> <16141.30044.453979.807772@montanaro.dyndns.org> <16141.50889.737066.126655@montanaro.dyndns.org> <16141.53302.659976.764809@montanaro.dyndns.org> Message-ID: On Thu, 10 Jul 2003, Skip Montanaro wrote: > > Martin> The patch looks right, please apply it. > > Done. And it still works on UnixWare 7.1.1 which requires -Kthread. > > Skip > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > -- Tim Rice Multitalents (707) 887-1469 tim@multitalents.net From jjl@pobox.com Fri Jul 11 01:57:00 2003 From: jjl@pobox.com (John J Lee) Date: Fri, 11 Jul 2003 01:57:00 +0100 (BST) Subject: [Python-Dev] Need help with urllib/urllib2 (SF bug 549151) In-Reply-To: <3F0D9C66.5000500@ocf.berkeley.edu> Message-ID: On Thu, 10 Jul 2003, Brett C. wrote: > Did the 2.2 branch get patched with a fix for the typo? Yes. [...] > As for removing the method, it has to be deprecated first since it has > been in an actual release. I don't think there is sufficient reason to remove it now it has been released. I think it was a minor point, anyway: nobody replied to my original request for comments on this issue, and I don't think it really breaks the protocol-independence of Request any more than add_data or add_header do. I won't go into why that method was removed again in a patch uploaded to the tracker (but not applied to CVS) after 2.2.3 was released, because this thread would never end. My sincere apologies again to everyone for so thoroughly messing up these redirect patches. John From tim.one@comcast.net Fri Jul 11 04:15:22 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 10 Jul 2003 23:15:22 -0400 Subject: [Python-Dev] RE: Congratulations to the Active Award Winners: Presented by ActiveState at O'Reilly Open Source Conference In-Reply-To: <9CE5DB8B868DCA4FB1AB629707F01DE48B9381@exchange.activestate.ca> Message-ID: FYI, some highly deserved recognition came two Python-Dev'ers (overshadowing Guido's feeble announcement of a new job ): http://www.activestate.com/Corporate/ActiveAwards/ From jeremy@zope.com Fri Jul 11 14:50:04 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 11 Jul 2003 09:50:04 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: References: <20030710201559.GA5732@panix.com> Message-ID: <1057931403.6408.22.camel@slothrop.zope.com> On Thu, 2003-07-10 at 16:32, Martin v. L=F6wis wrote: > Aahz writes: >=20 > > Did anyone ever check in fixes for that? >=20 > Yes, MAL checked in a patch, to remove re usage in > encodings/__init__.py. Nobody ever verified whether this had any > impact - most likely the impact was not significant. It looks like Python 2.2.3 and 2.3 both import re. The primary difference that I see between the two is that 2.3 imports the warnings module, which entails 7 more imports. + import warnings + import linecache + import encodings + import encodings + import codecs + import _codecs + import encodings.aliases + import encodings.iso8859_15 Jeremy From jeremy@zope.com Fri Jul 11 15:04:41 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 11 Jul 2003 10:04:41 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <1057931403.6408.22.camel@slothrop.zope.com> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> Message-ID: <1057932281.6407.28.camel@slothrop.zope.com> On Fri, 2003-07-11 at 09:50, Jeremy Hylton wrote: > + import warnings > + import linecache > + import encodings > + import encodings > + import codecs > + import _codecs > + import encodings.aliases > + import encodings.iso8859_15 Oops. I jumped the gun here. warnings doesn't use encodings or codecs. Something else imports that. Another obnoxious thing is that site.py imports distutils just for the benefit of people running from a build directory. It would be nice to find a solution for the build directory that didn't not require a bunch of distutils package imports. Jeremy From fred@zope.com Fri Jul 11 15:16:05 2003 From: fred@zope.com (Fred L. Drake, Jr.) Date: Fri, 11 Jul 2003 10:16:05 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <1057932281.6407.28.camel@slothrop.zope.com> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> Message-ID: <16142.50853.575209.723871@grendel.zope.com> Jeremy Hylton writes: > Another obnoxious thing is that site.py imports distutils just for the > benefit of people running from a build directory. It would be nice to > find a solution for the build directory that didn't not require a bunch > of distutils package imports. Perhaps, but... those imports only happen if it already looks like you're running from a build directory, so they don't impact the imports for an installed Python. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From jeremy@zope.com Fri Jul 11 15:27:23 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 11 Jul 2003 10:27:23 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <16142.50853.575209.723871@grendel.zope.com> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> Message-ID: <1057933643.20984.40.camel@slothrop.zope.com> On Fri, 2003-07-11 at 10:16, Fred L. Drake, Jr. wrote: > Perhaps, but... those imports only happen if it already looks like > you're running from a build directory, so they don't impact the > imports for an installed Python. You are so true. I just did fresh installs of 2.2.3 and 2.3 to see what happens when I run from an install Python. A nice minimal set of imports for 2.2.3: import site import os import posix import posixpath import stat import UserDict import copy_reg import types import __future__ There are a lot more for 2.3 (and each one costs more). import zipimport import site import os import posix import posixpath import stat import UserDict import copy_reg import types import warnings import linecache import re import sre import sre_compile import _sre import sre_constants import sre_parse import string import encodings import codecs import _codecs import encodings.aliases import encodings.iso8859_15 We can blame the extra imports on three new features. The zip import feature requires the zipimport module. The warnings feature requires warnings, linecache, and re, where re is costly -- seven imports in total. The top-level "import re" was removed from warnings.py, but it doesn't make any difference. The routine that *uses* the re module is called from the top-level of the warnings module. The default file system encoding feature requires the encodings and codecs packages to be loaded. That's another five imports. Anyone want to drop warnings and encodings? <0.9 wink> Jeremy From jeremy@zope.com Fri Jul 11 15:37:32 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 11 Jul 2003 10:37:32 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <1057933643.20984.40.camel@slothrop.zope.com> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> <1057933643.20984.40.camel@slothrop.zope.com> Message-ID: <1057934252.20984.46.camel@slothrop.zope.com> I've got a plan, which I'll implement today unless someone can find a hole in it. The warnings module stores 5-tuples of filter information, including two compiled regular expressions. There are two filters installed by default, which is why we load re during startup. The two default filters use the regular expression "". So we're getting absolutely no benefit from those regular expressions. I propose to modify the two regex slots in the filter tuple to also store None, where None means matching anything. If we make that change, then we can install the default filters without importing re. A quick test of this change improved startup time by 20%. Unfortunately, even with a 20% boost, it still takes twice as long to do python -c "pass". Jeremy From skip@pobox.com Fri Jul 11 15:55:04 2003 From: skip@pobox.com (Skip Montanaro) Date: Fri, 11 Jul 2003 09:55:04 -0500 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <1057934252.20984.46.camel@slothrop.zope.com> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> <1057933643.20984.40.camel@slothrop.zope.com> <1057934252.20984.46.camel@slothrop.zope.com> Message-ID: <16142.53192.292645.202685@montanaro.dyndns.org> Jeremy> The two default filters use the regular expression "". So we're Jeremy> getting absolutely no benefit from those regular expressions. I Jeremy> propose to modify the two regex slots in the filter tuple to Jeremy> also store None, where None means matching anything. Why bother compiling the regular expressions ahead of time? Just store strings and use re.match(...) instead of pat.match(...). When you encounter a potential warning you want to suppress, I suspect it's not generally going to be in a speed critical part of the system. If it is a potential performance issue, the re module will have the compiled regular expression in its cache. Skip From jeremy@zope.com Fri Jul 11 16:04:43 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 11 Jul 2003 11:04:43 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <16142.53192.292645.202685@montanaro.dyndns.org> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> <1057933643.20984.40.camel@slothrop.zope.com> <1057934252.20984.46.camel@slothrop.zope.com> <16142.53192.292645.202685@montanaro.dyndns.org> Message-ID: <1057935883.20984.49.camel@slothrop.zope.com> On Fri, 2003-07-11 at 10:55, Skip Montanaro wrote: > Jeremy> The two default filters use the regular expression "". So we're > Jeremy> getting absolutely no benefit from those regular expressions. I > Jeremy> propose to modify the two regex slots in the filter tuple to > Jeremy> also store None, where None means matching anything. > > Why bother compiling the regular expressions ahead of time? Just store > strings and use re.match(...) instead of pat.match(...). When you encounter > a potential warning you want to suppress, I suspect it's not generally going > to be in a speed critical part of the system. If it is a potential > performance issue, the re module will have the compiled regular expression > in its cache. I'd like to avoid importing re at all if it isn't needed. If you write a simple script and care about it's startup time, it would be nice if Python didn't require you to load re just to ignore Overflow warnings. Jeremy From skip@pobox.com Fri Jul 11 16:50:10 2003 From: skip@pobox.com (Skip Montanaro) Date: Fri, 11 Jul 2003 10:50:10 -0500 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <1057935883.20984.49.camel@slothrop.zope.com> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> <1057933643.20984.40.camel@slothrop.zope.com> <1057934252.20984.46.camel@slothrop.zope.com> <16142.53192.292645.202685@montanaro.dyndns.org> <1057935883.20984.49.camel@slothrop.zope.com> Message-ID: <16142.56498.57773.129839@montanaro.dyndns.org> --oAEwk5Z4e1 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Jeremy> I'd like to avoid importing re at all if it isn't needed. If Jeremy> you write a simple script and care about it's startup time, it Jeremy> would be nice if Python didn't require you to load re just to Jeremy> ignore Overflow warnings. You lost me. If the pattern is a simple string, only the code in the warnings module needs re and the functions which need it can import it themselves. I've been running with the attached diff for some time with no problems (since the last time we discussed this topic). Why does the user of the warnings module need to import re? Skip --oAEwk5Z4e1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="warnings.diff" Content-Transfer-Encoding: base64 KioqIC90bXAvc2tpcC93YXJuaW5ncy5weS5+MS4yMX42Zkc1MkkJRnJpIEp1bCAxMSAxMDo0 Nzo1NCAyMDAzCi0tLSAvdG1wL3NraXAvd2FybmluZ3MucHk2ZkdHQlAJRnJpIEp1bCAxMSAx MDo0Nzo1NCAyMDAzCioqKioqKioqKioqKioqKgoqKiogNTgsNjMgKioqKgotLS0gNTgsNjQg LS0tLQogIAogIGRlZiB3YXJuX2V4cGxpY2l0KG1lc3NhZ2UsIGNhdGVnb3J5LCBmaWxlbmFt ZSwgbGluZW5vLAogICAgICAgICAgICAgICAgICAgIG1vZHVsZT1Ob25lLCByZWdpc3RyeT1O b25lKToKKyAgICAgaW1wb3J0IHJlCiAgICAgIGlmIG1vZHVsZSBpcyBOb25lOgogICAgICAg ICAgbW9kdWxlID0gZmlsZW5hbWUKICAgICAgICAgIGlmIG1vZHVsZVstMzpdLmxvd2VyKCkg PT0gIi5weSI6CioqKioqKioqKioqKioqKgoqKiogNzcsODUgKioqKgogICAgICAjIFNlYXJj aCB0aGUgZmlsdGVycwogICAgICBmb3IgaXRlbSBpbiBmaWx0ZXJzOgogICAgICAgICAgYWN0 aW9uLCBtc2csIGNhdCwgbW9kLCBsbiA9IGl0ZW0KISAgICAgICAgIGlmICgobXNnIGlzIE5v bmUgb3IgbXNnLm1hdGNoKHRleHQpKSBhbmQKICAgICAgICAgICAgICBpc3N1YmNsYXNzKGNh dGVnb3J5LCBjYXQpIGFuZAohICAgICAgICAgICAgIChtc2cgaXMgTm9uZSBvciBtb2QubWF0 Y2gobW9kdWxlKSkgYW5kCiAgICAgICAgICAgICAgKGxuID09IDAgb3IgbGluZW5vID09IGxu KSk6CiAgICAgICAgICAgICAgYnJlYWsKICAgICAgZWxzZToKLS0tIDc4LDg2IC0tLS0KICAg ICAgIyBTZWFyY2ggdGhlIGZpbHRlcnMKICAgICAgZm9yIGl0ZW0gaW4gZmlsdGVyczoKICAg ICAgICAgIGFjdGlvbiwgbXNnLCBjYXQsIG1vZCwgbG4gPSBpdGVtCiEgICAgICAgICBpZiAo cmUubWF0Y2gobXNnLCB0ZXh0LCByZS5JKSBhbmQKICAgICAgICAgICAgICBpc3N1YmNsYXNz KGNhdGVnb3J5LCBjYXQpIGFuZAohICAgICAgICAgICAgIHJlLm1hdGNoKG1vZCwgbW9kdWxl KSBhbmQKICAgICAgICAgICAgICAobG4gPT0gMCBvciBsaW5lbm8gPT0gbG4pKToKICAgICAg ICAgICAgICBicmVhawogICAgICBlbHNlOgoqKioqKioqKioqKioqKioKKioqIDEzNywxNDMg KioqKgogICAgICAiIiJJbnNlcnQgYW4gZW50cnkgaW50byB0aGUgbGlzdCBvZiB3YXJuaW5n cyBmaWx0ZXJzIChhdCB0aGUgZnJvbnQpLgogIAogICAgICBVc2UgYXNzZXJ0aW9ucyB0byBj aGVjayB0aGF0IGFsbCBhcmd1bWVudHMgaGF2ZSB0aGUgcmlnaHQgdHlwZS4iIiIKLSAgICAg aW1wb3J0IHJlCiAgICAgIGFzc2VydCBhY3Rpb24gaW4gKCJlcnJvciIsICJpZ25vcmUiLCAi YWx3YXlzIiwgImRlZmF1bHQiLCAibW9kdWxlIiwKICAgICAgICAgICAgICAgICAgICAgICAg Im9uY2UiKSwgImludmFsaWQgYWN0aW9uOiAlcyIgJSBgYWN0aW9uYAogICAgICBhc3NlcnQg aXNpbnN0YW5jZShtZXNzYWdlLCBiYXNlc3RyaW5nKSwgIm1lc3NhZ2UgbXVzdCBiZSBhIHN0 cmluZyIKLS0tIDEzOCwxNDMgLS0tLQoqKioqKioqKioqKioqKioKKioqIDE0NiwxNTMgKioq KgogICAgICBhc3NlcnQgaXNpbnN0YW5jZShtb2R1bGUsIGJhc2VzdHJpbmcpLCAibW9kdWxl IG11c3QgYmUgYSBzdHJpbmciCiAgICAgIGFzc2VydCBpc2luc3RhbmNlKGxpbmVubywgaW50 KSBhbmQgbGluZW5vID49IDAsIFwKICAgICAgICAgICAgICJsaW5lbm8gbXVzdCBiZSBhbiBp bnQgPj0gMCIKISAgICAgaXRlbSA9IChhY3Rpb24sIHJlLmNvbXBpbGUobWVzc2FnZSwgcmUu SSksIGNhdGVnb3J5LAohICAgICAgICAgICAgIHJlLmNvbXBpbGUobW9kdWxlKSwgbGluZW5v KQogICAgICBpZiBhcHBlbmQ6CiAgICAgICAgICBmaWx0ZXJzLmFwcGVuZChpdGVtKQogICAg ICBlbHNlOgotLS0gMTQ2LDE1MiAtLS0tCiAgICAgIGFzc2VydCBpc2luc3RhbmNlKG1vZHVs ZSwgYmFzZXN0cmluZyksICJtb2R1bGUgbXVzdCBiZSBhIHN0cmluZyIKICAgICAgYXNzZXJ0 IGlzaW5zdGFuY2UobGluZW5vLCBpbnQpIGFuZCBsaW5lbm8gPj0gMCwgXAogICAgICAgICAg ICAgImxpbmVubyBtdXN0IGJlIGFuIGludCA+PSAwIgohICAgICBpdGVtID0gKGFjdGlvbiwg bWVzc2FnZSwgY2F0ZWdvcnksIG1vZHVsZSwgbGluZW5vKQogICAgICBpZiBhcHBlbmQ6CiAg ICAgICAgICBmaWx0ZXJzLmFwcGVuZChpdGVtKQogICAgICBlbHNlOgo= --oAEwk5Z4e1-- From theller@python.net Fri Jul 11 16:20:19 2003 From: theller@python.net (Thomas Heller) Date: Fri, 11 Jul 2003 17:20:19 +0200 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <1057933643.20984.40.camel@slothrop.zope.com> (Jeremy Hylton's message of "11 Jul 2003 10:27:23 -0400") References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> <1057933643.20984.40.camel@slothrop.zope.com> Message-ID: Jeremy Hylton writes: > On Fri, 2003-07-11 at 10:16, Fred L. Drake, Jr. wrote: >> Perhaps, but... those imports only happen if it already looks like >> you're running from a build directory, so they don't impact the >> imports for an installed Python. > > You are so true. I just did fresh installs of 2.2.3 and 2.3 to see what > happens when I run from an install Python. > > A nice minimal set of imports for 2.2.3: > > import site > import os > import posix > import posixpath > import stat > import UserDict > import copy_reg > import types > import __future__ > > There are a lot more for 2.3 (and each one costs more). > > import zipimport > import site > import os > import posix > import posixpath > import stat > import UserDict > import copy_reg > import types > import warnings > import linecache > import re > import sre > import sre_compile > import _sre > import sre_constants > import sre_parse > import string > import encodings > import codecs > import _codecs > import encodings.aliases > import encodings.iso8859_15 > > We can blame the extra imports on three new features. > > The zip import feature requires the zipimport module. > > The warnings feature requires warnings, linecache, and re, where re is > costly -- seven imports in total. The top-level "import re" was removed > from warnings.py, but it doesn't make any difference. The routine that > *uses* the re module is called from the top-level of the warnings > module. > > The default file system encoding feature requires the encodings and > codecs packages to be loaded. That's another five imports. > > Anyone want to drop warnings and encodings? <0.9 wink> > Sure. There's another problem with these imports happening *very* early, it breaks py2exe, and maybe also McMillan installer because these imports happen *before* the import hook is installed. Thomas From jeremy@zope.com Fri Jul 11 17:04:18 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 11 Jul 2003 12:04:18 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <16142.56498.57773.129839@montanaro.dyndns.org> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> <1057933643.20984.40.camel@slothrop.zope.com> <1057934252.20984.46.camel@slothrop.zope.com> <16142.53192.292645.202685@montanaro.dyndns.org> <1057935883.20984.49.camel@slothrop.zope.com> <16142.56498.57773.129839@montanaro.dyndns.org> Message-ID: <1057939457.6408.52.camel@slothrop.zope.com> On Fri, 2003-07-11 at 11:50, Skip Montanaro wrote: > Jeremy> I'd like to avoid importing re at all if it isn't needed. If > Jeremy> you write a simple script and care about it's startup time, it > Jeremy> would be nice if Python didn't require you to load re just to > Jeremy> ignore Overflow warnings. > > You lost me. If the pattern is a simple string, only the code in the > warnings module needs re and the functions which need it can import it > themselves. I've been running with the attached diff for some time with no > problems (since the last time we discussed this topic). Why does the user > of the warnings module need to import re? I'm lost, too. If a warning gets generated, you would need to have re imported to filter the warning. If a user writes a short script that generates warnings that is ignored (OverflowWarning or PendingDeprecationWarning), the re module will need to be imported. My change allows scripts that don't actually need re to run without importing it, even if they do generate ignored warnings. Jeremy From guido@python.org Fri Jul 11 17:45:51 2003 From: guido@python.org (Guido van Rossum) Date: Fri, 11 Jul 2003 12:45:51 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: Your message of "Fri, 11 Jul 2003 10:37:32 EDT." <1057934252.20984.46.camel@slothrop.zope.com> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> <1057933643.20984.40.camel@slothrop.zope.com> <1057934252.20984.46.camel@slothrop.zope.com> Message-ID: <200307111645.h6BGjqw03309@pcp02138704pcs.reston01.va.comcast.net> > I've got a plan, which I'll implement today unless someone can find a > hole in it. The warnings module stores 5-tuples of filter information, > including two compiled regular expressions. There are two filters > installed by default, which is why we load re during startup. > > The two default filters use the regular expression "". So we're getting > absolutely no benefit from those regular expressions. I propose to > modify the two regex slots in the filter tuple to also store None, where > None means matching anything. > > If we make that change, then we can install the default filters without > importing re. A quick test of this change improved startup time by 20%. It seems you already implemented this; I approve (though I hope some other folks will carefully review the changes to warnings.py, which are a bit more extensive than I feel comfortable with this close to a release). > Unfortunately, even with a 20% boost, it still takes twice as long to do > python -c "pass". There's a little time for more research into this. --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@zope.com Fri Jul 11 18:25:14 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 11 Jul 2003 13:25:14 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <20030710201559.GA5732@panix.com> References: <20030710201559.GA5732@panix.com> Message-ID: <1057944314.6534.69.camel@slothrop.zope.com> --=-xRJ1W9x+0jsd/L7bf43k Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2003-07-10 at 16:15, Aahz wrote: > What's the current status of the startup speed for Python 2.3? Did > anyone ever check in fixes for that? I did some more measurements of what I think are startup time and teardown time. I assume people who care about startup time for small scripts care about teardown time for small scripts, too, since it's time spent executing code. (You might consider it time wasted, since the process is exiting and it's mostly giving memory back to obmalloc <0.5 wink>.) I measured the time it takes to execute two different scripts: python -c "pass" and python -c "import os; os._exit(0)". I believe the os._exit() script measures just startup time, because the process exits immediately without running Py_Finalize(). So I'll refer to two times "total" time and "startup" time for the two scripts. I took the measurements after the warnings changes I made today. Times reported here are the minimum of each real, user, and sys time over 10 runs of the script. This is on my RH 7.3 desktop. (Timing script attached.) py kind real user sys (time in ms) 2.2 total 32 21 2 2.2 startup 29 14 4 2.3 total 53 33 6 2.3 startup 41 21 4 (I took the minimums of the individual component times, so they don't add up quite right.) One thing to observe is that the teardown time (the difference between total and startup) is much larger in 2.3. It's 3ms in 2.2 and 12ms in 2.3. We added to extra GC collection phases to 2.3 teardown, so that isn't too surprising. One thing I learned is that timings take from a build directory are quite different from timings taken after an install. The cost of loading up distutils is high. Jeremy --=-xRJ1W9x+0jsd/L7bf43k Content-Disposition: attachment; filename=startup.py Content-Type: text/x-python; name=startup.py; charset=iso-8859-15 Content-Transfer-Encoding: 7bit #! /usr/bin/env python """Simple script to time Python startup time""" import os def timeit1(stmt): """Return real, user, and sys from single execution.""" i, o, e = os.popen3('time %s -c "%s"' % (py, stmt)) buf = e.read() i.close() o.close() e.close() return parse_time(buf) def timeit(stmt, iters=10): """Return the lowest real, user, and sys each from iters trials.""" L = [timeit1(stmt) for i in range(iters)] return map(min, zip(*L)) def parse_time(buf): real = None user = None sys = None for line in buf.split("\n"): if not line: continue kind, _t = line.split("\t") t = int(float(_t[2:-1]) * 1000) if kind == "real": real = t elif kind == "user": user = t elif kind == "sys": sys = t return real, user, sys def main(argv): global py py = argv[0] total = timeit("pass") startup = timeit("import os; os._exit(0)") print py print "kind real user sys (time in ms)" fmt = "%-8s %4s %4s %4s" print fmt % ("total", total[0], total[1], total[2]) print fmt % ("startup", startup[0], startup[1], startup[2]) if __name__ == "__main__": import sys main(sys.argv[1:]) --=-xRJ1W9x+0jsd/L7bf43k-- From jeremy@zope.com Fri Jul 11 19:04:05 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 11 Jul 2003 14:04:05 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: <200307111645.h6BGjqw03309@pcp02138704pcs.reston01.va.comcast.net> References: <20030710201559.GA5732@panix.com> <1057931403.6408.22.camel@slothrop.zope.com> <1057932281.6407.28.camel@slothrop.zope.com> <16142.50853.575209.723871@grendel.zope.com> <1057933643.20984.40.camel@slothrop.zope.com> <1057934252.20984.46.camel@slothrop.zope.com> <200307111645.h6BGjqw03309@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <1057946644.6408.73.camel@slothrop.zope.com> On Fri, 2003-07-11 at 12:45, Guido van Rossum wrote: > It seems you already implemented this; I approve (though I hope some > other folks will carefully review the changes to warnings.py, which > are a bit more extensive than I feel comfortable with this close to a > release). It is code that gets exercised a lot. Zope, for example, generates lots and lots of warnings, so we should be able to build up our confidence quickly. Jeremy From drifty@alum.berkeley.edu Sat Jul 12 04:19:40 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Fri, 11 Jul 2003 20:19:40 -0700 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> Message-ID: <3F0F7E4C.2050003@ocf.berkeley.edu> Phillip J. Eby wrote: > No joy: > > test test_time failed -- Traceback (most recent call last): > File "/home/admin/PythonCVS/dist/src/Lib/test/test_time.py", line 107, > in test_tzset > self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) > File "/home/admin/PythonCVS/dist/src/Lib/unittest.py", line 268, in > failUnless > if not expr: raise self.failureException, msg > AssertionError: AEST > > This was on a clean HEAD checkout, applying the patch (762934), run > 'autoreconf' in dist/src, followed by './configure --with-pydebug' and > 'make test'. > OK, now what shall we do? Could we hard-code the test itself by doing a string comparison in C to see if the name of the timezones match? -Brett From pinard@iro.umontreal.ca Sat Jul 12 05:31:42 2003 From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois_Pinard?=) Date: 12 Jul 2003 00:31:42 -0400 Subject: [Python-Dev] Assymetry in repr(STRING) Message-ID: Hello, all. I just noticed: ----------------------------------------------------------------------> Python 2.3b2 (#2, Jun 30 2003, 10:14:37) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import nested_scopes, generators, division >>> '\n\f\b\t' '\n\x0c\x08\t' >>> ----------------------------------------------------------------------< and wonder if this is really on purpose that `\f' is not echoed as `\f', for example. Would not it be nicer if white space effectors were consistently interpreted? If `\n' and `\t' got the special treat, why not the others? -- François Pinard http://www.iro.umontreal.ca/~pinard From drifty@alum.berkeley.edu Sun Jul 13 00:08:01 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Sat, 12 Jul 2003 16:08:01 -0700 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <3F0F7E4C.2050003@ocf.berkeley.edu> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <3F0C9D21.4030207@ocf.berkeley.edu> <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> <3F0F7E4C.2050003@ocf.berkeley.edu> Message-ID: <3F1094D1.2070601@ocf.berkeley.edu> Brett C. wrote: > Phillip J. Eby wrote: > > >> No joy: >> >> test test_time failed -- Traceback (most recent call last): >> File "/home/admin/PythonCVS/dist/src/Lib/test/test_time.py", line >> 107, in test_tzset >> self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) >> File "/home/admin/PythonCVS/dist/src/Lib/unittest.py", line 268, in >> failUnless >> if not expr: raise self.failureException, msg >> AssertionError: AEST >> >> This was on a clean HEAD checkout, applying the patch (762934), run >> 'autoreconf' in dist/src, followed by './configure --with-pydebug' and >> 'make test'. >> > > OK, now what shall we do? Could we hard-code the test itself by doing a > string comparison in C to see if the name of the timezones match? > I went ahead and coded up my own version of the patch to check for AEDT explicitly. I can't test it, though, because I am having problems getting a newer version of Autoconf to run on my OS X laptop (OS X comes with 2.52). If someone can give it a go and fix any errors on it hopefully this will do the trick. -Brett From skip@pobox.com Sun Jul 13 02:48:28 2003 From: skip@pobox.com (Skip Montanaro) Date: Sat, 12 Jul 2003 20:48:28 -0500 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <3F1094D1.2070601@ocf.berkeley.edu> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> <3F0F7E4C.2050003@ocf.berkeley.edu> <3F1094D1.2070601@ocf.berkeley.edu> Message-ID: <16144.47724.153593.807179@montanaro.dyndns.org> Brett> I can't test it, though, because I am having problems getting a Brett> newer version of Autoconf to run on my OS X laptop (OS X comes Brett> with 2.52). If someone can give it a go and fix any errors on it Brett> hopefully this will do the trick. Not directly related, but if you install fink (fink.sf.net) you'll get autoconf 2.57. What is it you need "given a go"? Skip From drifty@alum.berkeley.edu Sun Jul 13 03:17:14 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Sat, 12 Jul 2003 19:17:14 -0700 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <16144.47724.153593.807179@montanaro.dyndns.org> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> <3F0F7E4C.2050003@ocf.berkeley.edu> <3F1094D1.2070601@ocf.berkeley.edu> <16144.47724.153593.807179@montanaro.dyndns.org> Message-ID: <3F10C12A.3020708@ocf.berkeley.edu> Skip Montanaro wrote: > Brett> I can't test it, though, because I am having problems getting a > Brett> newer version of Autoconf to run on my OS X laptop (OS X comes > Brett> with 2.52). If someone can give it a go and fix any errors on it > Brett> hopefully this will do the trick. > > Not directly related, but if you install fink (fink.sf.net) you'll get > autoconf 2.57. > With the Fink installed I don't see installed in /sw anywhere. Perhaps my Fink is too old (don't really use it). > What is it you need "given a go"? > The patch. See if it works for people as it should. I managed to get autoconf 2.53 to work on my laptop and tzset still showed up, but I got some other new errors that might be related. I am going to try to get 2.57 working on my laptop before I start worrying about the new errors. -Brett From drifty@alum.berkeley.edu Sun Jul 13 03:47:07 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Sat, 12 Jul 2003 19:47:07 -0700 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <3F10C12A.3020708@ocf.berkeley.edu> References: <3F0C9D21.4030207@ocf.berkeley.edu> <1057762719.7056.11.camel@yyz> <3F0C502F.70209@ocf.berkeley.edu> <5.1.1.6.0.20030710155135.01f810b0@telecommunity.com> <3F0F7E4C.2050003@ocf.berkeley.edu> <3F1094D1.2070601@ocf.berkeley.edu> <16144.47724.153593.807179@montanaro.dyndns.org> <3F10C12A.3020708@ocf.berkeley.edu> Message-ID: <3F10C82B.3080502@ocf.berkeley.edu> Brett C. wrote: > Skip Montanaro wrote: > >> What is it you need "given a go"? >> > > The patch. See if it works for people as it should. I managed to get > autoconf 2.53 to work on my laptop and tzset still showed up, but I got > some other new errors that might be related. I am going to try to get > 2.57 working on my laptop before I start worrying about the new errors. > The "new errors" I mean I think might be related to autoreconf and not the tzset detection code. -Brett From drifty@alum.berkeley.edu Sun Jul 13 04:54:15 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Sat, 12 Jul 2003 20:54:15 -0700 Subject: [Python-Dev] Vacation and possibly a new bug Message-ID: <3F10D7E7.3080304@ocf.berkeley.edu> Just a quick reminder, I am going off for a vacation and my brother's wedding tomorrow (July 13) and won't have a definite Net connection until July 22. The bug #762934 (patch for configure.in to detect time.tzset better) is still open. I uploaded my own version of the patch that is more explicit in detecting whether the function works properly. It works for me, but tzset has always worked properly for me. If someone with Red Hat 6.2 can test it that would be great (that will close bug #763153). The macostools error (bug #763708) is still happening and I still think it could be an OS X bug and not ours. And after I updated my copy of CVS and tried out the patch for tzset detection as mentioned above I got a failure in test_pep277.py (only difference between CVS and my checkout is configure.in and only in the tzset code and regrtest.py): ./python.exe Lib/test/test_pep277.py ~/Progs/Python/CVS/python/dist/src test_directory (__main__.UnicodeFileTests) ... u'\xdf-\u66e8\u66e9\u66eb' ok test_failures (__main__.UnicodeFileTests) ... ERROR test_listdir (__main__.UnicodeFileTests) ... ERROR test_open (__main__.UnicodeFileTests) ... ok test_rename (__main__.UnicodeFileTests) ... ok ====================================================================== ERROR: test_failures (__main__.UnicodeFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pep277.py", line 64, in test_failures self._apply_failure(open, name, IOError) File "Lib/test/test_pep277.py", line 54, in _apply_failure if check_fn_in_exception and details.filename != filename: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 12: ordinal not in range(128) ====================================================================== ERROR: test_listdir (__main__.UnicodeFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_pep277.py", line 82, in test_listdir f2 = os.listdir(unicode(test_support.TESTFN,"mbcs")) File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/encodings/mbcs.py", line 14, in ? class Codec(codecs.Codec): File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/encodings/mbcs.py", line 18, in Codec encode = codecs.mbcs_encode AttributeError: 'module' object has no attribute 'mbcs_encode' ---------------------------------------------------------------------- Ran 5 tests in 0.872s FAILED (errors=2) Traceback (most recent call last): File "Lib/test/test_pep277.py", line 113, in ? test_main() File "Lib/test/test_pep277.py", line 108, in test_main test_support.run_unittest(UnicodeFileTests) File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/test/test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "/Users/drifty/Progs/Python/CVS/python/dist/src/Lib/test/test_support.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in __main__.UnicodeFileTests [7442 refs] This is under OS X so if this is a serious bug and not some funky fluke on my system hopefully someone else like Skip, Just, or Michael will get it and be able to work on it. Good luck on getting 2.3 final out the door. I feel bad having a patch and a possible bug being open before I leave. Sorry, guys. I hope to come back with little python-dev email and what little I get are positive. =) -Brett From martin@v.loewis.de Sun Jul 13 08:10:05 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 13 Jul 2003 09:10:05 +0200 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F10D7E7.3080304@ocf.berkeley.edu> References: <3F10D7E7.3080304@ocf.berkeley.edu> Message-ID: "Brett C." writes: > And after I updated my copy of CVS and tried out the patch for tzset > detection as mentioned above I got a failure in test_pep277.py (only > difference between CVS and my checkout is configure.in and only in the > tzset code and regrtest.py): That would be most likely due to Just's activating supports_unicode_filenames in posixpath.py. Regards, Martin From skip@mojam.com Sun Jul 13 13:00:23 2003 From: skip@mojam.com (Skip Montanaro) Date: Sun, 13 Jul 2003 07:00:23 -0500 Subject: [Python-Dev] Weekly Python Bug/Patch Summary Message-ID: <200307131200.h6DC0NI18554@manatee.mojam.com> Bug/Patch Summary ----------------- 375 open / 3846 total bugs (-2) 165 open / 2271 total patches (-2) New Bugs -------- Installing documentation doesn't make it show up (2003-07-06) http://python.org/sf/766842 AttributeError thrown by urllib.open_http (2003-07-07) http://python.org/sf/767111 socket.inet_aton on 64bit platform (2003-07-07) http://python.org/sf/767150 Explicit interp reference during build fails (2003-07-08) http://python.org/sf/768068 Distutils broken on Os X (2003-07-09) http://python.org/sf/768306 hardcoded python paths (2003-07-09) http://python.org/sf/768391 Subtle bug in os.path.realpath on Cygwin (2003-07-09) http://python.org/sf/768419 Alt key doesn't work in IDLE for MacOSX (2003-07-09) http://python.org/sf/768469 Column Number is not visible in MacOSX (2003-07-09) http://python.org/sf/768481 popen4 doesn't close filedescriptors when in Threads (2003-07-09) http://python.org/sf/768649 Odd behavior in the file object (2003-07-09) http://python.org/sf/768698 Droplets aren't always recognized as apps in MacPython 2.3b2 (2003-07-10) http://python.org/sf/769406 weird/buggy inspect.getsource behavious (2003-07-11) http://python.org/sf/769569 "make info" croaks (2003-07-11) http://python.org/sf/769861 classmethod(classmethod(foo)) -> SystemError (2003-07-13) http://python.org/sf/770465 cStringIO does not set closed attr (2003-07-13) http://python.org/sf/770485 New Patches ----------- fix one or two bugs in trace.py (2003-07-06) http://python.org/sf/766910 Add a 'isotime' format to standard logging (2003-07-08) http://python.org/sf/767600 configure interpreter for profiling (2003-07-08) http://python.org/sf/768079 Warning 'assignment shadows builtin' __builtins__ fix (2003-07-09) http://python.org/sf/768442 IRIX libmpc patch (2003-07-09) http://python.org/sf/768840 PyMarshal_ReadLastObjectFromFile (2003-07-12) http://python.org/sf/770280 Closed Bugs ----------- __coerce__ not working with new classes (2001-11-08) http://python.org/sf/479698 __slots__ undocumented (2002-01-11) http://python.org/sf/502544 gcc warning in unicodeobject.c (2002-04-15) http://python.org/sf/544248 urllib2 POSTs on redirect (2002-04-26) http://python.org/sf/549151 python should obey the FHS (2002-07-30) http://python.org/sf/588756 Import fails in Idle (2002-10-07) http://python.org/sf/619713 Pythonwin : close() on a stdout (2002-11-25) http://python.org/sf/643571 SequenceMatcher finds suboptimal sequenc (2002-11-29) http://python.org/sf/645629 test_socket test_unicode_file fail on 2.3a1 on winNT (2003-01-07) http://python.org/sf/663782 Seg fault in gcmodule.c (2003-01-17) http://python.org/sf/669838 urllib2 HTTPDigestAuthHandler misnamed class attr (2003-02-07) http://python.org/sf/682648 Erroneous error message from IDLE (2003-03-07) http://python.org/sf/699630 u''.translate not documented (2003-03-19) http://python.org/sf/706546 bsddb.first()/next() raise undocumented exception (2003-04-03) http://python.org/sf/715063 HTMLParser -- possible bug in handle_comment (2003-05-21) http://python.org/sf/741029 Tutorial: 4.7.2 Keyword Arguments **name output order wrong (2003-06-16) http://python.org/sf/755564 tut/contents.html does not exist (2003-06-29) http://python.org/sf/763032 recent test_httplib change uses network (2003-07-01) http://python.org/sf/764095 python treats IRIX64 and IRIX as different, but they are the (2003-07-02) http://python.org/sf/764560 string.title() doesn't understand apostrophes (2003-07-05) http://python.org/sf/766541 Closed Patches -------------- clean up trace.py (2002-04-11) http://python.org/sf/542562 Adds a builtin decimal type (FixedPoint) (2002-12-14) http://python.org/sf/653938 __del__ in dumbdbm fails under some circumstances (2003-04-17) http://python.org/sf/723231 Clarify docs for except target assignment (2003-04-24) http://python.org/sf/726751 unicode "support" for shlex.py (2003-05-23) http://python.org/sf/742290 sys.interrupt_main() (2003-06-12) http://python.org/sf/753733 -DPIC should be added for the -fPIC case (2003-06-27) http://python.org/sf/761969 Support IDLE Edit of .py/.pyw from idlelib (2003-06-30) http://python.org/sf/763681 Bugfix for incorrect xmlrpclib.Fault representation (2003-07-02) http://python.org/sf/764470 building bsddb3 on FreeBSD (2003-07-02) http://python.org/sf/764612 From barry.alan.scott@ntlworld.com Sun Jul 13 17:59:47 2003 From: barry.alan.scott@ntlworld.com (Barry Scott) Date: Sun, 13 Jul 2003 17:59:47 +0100 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <16139.16141.291211.130239@montanaro.dyndns.org> Message-ID: <5.2.1.1.0.20030713175713.0258e2a8@torment.chelsea.private> Is linking with c++ the trick that allows C++ extensions to be dynamically loaded into python? A while a go we had to get the ports of python fixed to allow C++ extensions to be usable. Barry From martin@v.loewis.de Sun Jul 13 18:05:51 2003 From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 13 Jul 2003 19:05:51 +0200 Subject: [Python-Dev] Why is python linked with c++? In-Reply-To: <5.2.1.1.0.20030713175713.0258e2a8@torment.chelsea.private> References: <5.2.1.1.0.20030713175713.0258e2a8@torment.chelsea.private> Message-ID: <3F11916F.4020802@v.loewis.de> Barry Scott wrote: > Is linking with c++ the trick that allows C++ extensions to be > dynamically loaded into python? It should be, yes. It all depends on the compiler: some compilers require that the executable is linked with the C++ compiler, some compilers require that main is compiled with the C++ compiler, some compilers allow to load C++ extensions even if only the C compiler was used when building Python, some compilers don't support C++ at all, and so on. configure is supposed to figure it all out. If there is a specific platform/compiler/phase-of-the-moon combination that is not working, but which could be made working by using different magic incantations, please submit a bug report. Regards, Martin From martin@v.loewis.de Sun Jul 13 19:22:16 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 13 Jul 2003 20:22:16 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <3F09364D.6020005@lemburg.com> References: <200307061342.h66DghCB027333@localhost.localdomain> <3F09364D.6020005@lemburg.com> Message-ID: "M.-A. Lemburg" writes: > Here's a howto that might help in installing a secure CVS server > on python.org: > > http://www.prima.eu.org/tobez/cvs-howto.html That is overkill. All we would need is a anonymous-only pserver installation. Write access is not reasonable, as the database would be always roughly a day behind. Setting up a pserver is relatively straight-forward - it just takes some time to execute all the necessary steps. Regards, Martin From skip@pobox.com Sun Jul 13 19:32:15 2003 From: skip@pobox.com (Skip Montanaro) Date: Sun, 13 Jul 2003 13:32:15 -0500 Subject: [Python-Dev] improving dumbdbm's survival chances... Message-ID: <16145.42415.10003.235348@montanaro.dyndns.org> (CC'ing python-dev because I think there's a simple improvement/fix for dumbdbm here.) I realize we (the Spambayes folks) want to discourage people from using dumbdbm, but for those who are either stuck with it or don't realize they are using it, I wonder if we can do a little something to help them out. As I understand it, if a machine crashes or is shut down without exiting Outlook, there's a good chance that the dumbdbm's _commit method won't have been called and the directory and data files will be out-of-sync. It seems that dumbdbm doesn't support a sync() method which shelve likes to call. Shelve's sync method gets called from time-to-time by the Spambayes storage code. dumbdbm.sync has this statement: if hasattr(self.dict, 'sync'): self.dict.sync() so maybe it's as simple (short-term) as modifying dbmstorage.open_dumbdbm() to def open_dumbdbm(*args): """Open a dumbdbm database.""" import dumbdbm db = dumbdbm.open(*args) if not hasattr(db, "sync"): db.sync = db._commit return db The above should help. Meanwhile, it appears that would be a good method to add to dumbdbm databases both for 2.3 and the 2.2 maintenance branch. Skip From martin@v.loewis.de Sun Jul 13 19:54:06 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 13 Jul 2003 20:54:06 +0200 Subject: [Python-Dev] improving dumbdbm's survival chances... In-Reply-To: <16145.42415.10003.235348@montanaro.dyndns.org> References: <16145.42415.10003.235348@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > The above should help. Meanwhile, it appears that would be a good method to > add to dumbdbm databases both for 2.3 and the 2.2 maintenance branch. Certainly - once 2.3 goes into maintenance. Regards, Martin From tim.one@comcast.net Sun Jul 13 20:16:56 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 13 Jul 2003 15:16:56 -0400 Subject: [Python-Dev] RE: [spambayes-dev] improving dumbdbm's survival chances... In-Reply-To: <16145.42415.10003.235348@montanaro.dyndns.org> Message-ID: [Skip] > I realize we (the Spambayes folks) want to discourage people from > using dumbdbm, but for those who are either stuck with it or don't > realize they are using it, I wonder if we can do a little something > to help them out. > > As I understand it, if a machine crashes or is shut down without > exiting Outlook, there's a good chance that the dumbdbm's _commit > method won't have been called and the directory and data files will > be out-of-sync. This is so. Worse, because spambayes never calls close() on its Shelf object, it implicitly relies on dumbdbm.__del__ to rewrite the dir file, but dumbdbm.__del__ can easily trigger a shutdown race in dumbdbm._commit (referencing the global "_os" that has already been rebound to None by shutdown cleanup), and the .dir file and .dat files on disk remain inconsistent in that case. (I fixed this race for 2.3 final, BTW.) > It seems that dumbdbm doesn't support a sync() method which shelve > likes to call. Shelve's sync method gets called from time-to-time by > the Spambayes storage code. dumbdbm.sync has this statement: No, you're quoting shelve.py here: > if hasattr(self.dict, 'sync'): > self.dict.sync() > > so maybe it's as simple (short-term) as modifying > dbmstorage.open_dumbdbm() to > > def open_dumbdbm(*args): > """Open a dumbdbm database.""" > import dumbdbm > db = dumbdbm.open(*args) > if not hasattr(db, "sync"): > db.sync = db._commit > return db That would help spambayes a lot, because DBDictClassifier.store() does call self.db.sync() on its Shelf at the important times. It wouldn't stop the shutdown race in dumbdbm._commit() from bombing out with an exception, but for spambayes that would no longer matter to on-disk database integrity. People using dumbdbm with spambayes would still be a lot better off using a plain in-memory dict, though (on all counts: it would consume less memory, consume less disk space for the dict pickle, and run faster). > The above should help. Meanwhile, it appears that would be a good > method to add to dumbdbm databases both for 2.3 and the 2.2 > maintenance branch. Fine by me, although I doubt a 2.2.4 will get released. Adding sync = _commit to the 2.3 code (+ docs + test) should be sufficient. BTW, this code in the spambayes storage.py is revolting (having one module change the documented default behavior of another module is almost always indefensible -- I can't see any reason for this abuse in spambayes): """ # Make shelve use binary pickles by default. oldShelvePickler = shelve.Pickler def binaryDefaultPickler(f, binary=1): return oldShelvePickler(f, binary) shelve.Pickler = binaryDefaultPickler """ From skip@pobox.com Mon Jul 14 02:26:41 2003 From: skip@pobox.com (Skip Montanaro) Date: Sun, 13 Jul 2003 20:26:41 -0500 Subject: [Python-Dev] RE: [spambayes-dev] improving dumbdbm's survival chances... In-Reply-To: References: <16145.42415.10003.235348@montanaro.dyndns.org> Message-ID: <16146.1745.865650.293138@montanaro.dyndns.org> >> It seems that dumbdbm doesn't support a sync() method which shelve >> likes to call. Shelve's sync method gets called from time-to-time by >> the Spambayes storage code. dumbdbm.sync has this statement: Tim> No, you're quoting shelve.py here: >> if hasattr(self.dict, 'sync'): >> self.dict.sync() Yup. The Spambayes storage code calls Shelve's sync method. It in turn (in the code I quoted) will call the underlying db module's sync method if it has it. It seems to me that dumdbm's _commit() method is the same as the sync() method which Shelve is looking for. >> def open_dumbdbm(*args): >> """Open a dumbdbm database.""" >> import dumbdbm >> db = dumbdbm.open(*args) >> if not hasattr(db, "sync"): >> db.sync = db._commit >> return db Tim> That would help spambayes a lot, because DBDictClassifier.store() Tim> does call self.db.sync() on its Shelf at the important times. Yeah, that's what I was getting at. Tim> People using dumbdbm with spambayes would still be a lot better off Tim> using a plain in-memory dict, though (on all counts: it would Tim> consume less memory, consume less disk space for the dict pickle, Tim> and run faster). Tim> Fine by me, although I doubt a 2.2.4 will get released. Adding Tim> sync = _commit Tim> to the 2.3 code (+ docs + test) should be sufficient. I'm willing to do that. Martin seemed to disagree that it should go in until after 2.3 is released. I'll submit a patch and let others decide. Skip From tim.one@comcast.net Mon Jul 14 04:05:38 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 13 Jul 2003 23:05:38 -0400 Subject: [Python-Dev] RE: [spambayes-dev] improving dumbdbm's survival chances... In-Reply-To: <16146.1745.865650.293138@montanaro.dyndns.org> Message-ID: [Tim] > Fine by me, although I doubt a 2.2.4 will get released. > Adding > > sync = _commit > > to the 2.3 code (+ docs + test) should be sufficient. [Skip] > I'm willing to do that. Martin seemed to disagree that it should go > in until after 2.3 is released. I'll submit a patch and let others > decide. I'll approve the patch, so let's save time and just check it in. Adding a sync method to dumbdbm cannot break any code except for code that relies on dumbdbm.open(...).sync() raising AttributeError, and it's highly unlikely any such code exists. We already know that the lack of a sync method in dumbdbm is directly responsible for catastrophic database corruption problems in one major Python app. Waiting for 2.3.1 to fix a serious bug would be silly, especially given that the fix is an obvious one-liner adding new behavior while leaving all existing method behaviors alone. From Anthony Baxter Mon Jul 14 08:47:34 2003 From: Anthony Baxter (Anthony Baxter) Date: Mon, 14 Jul 2003 17:47:34 +1000 Subject: [Python-Dev] Can't compile _tkinter.c with Redhat 9 (post-SF#719880) In-Reply-To: Message-ID: <200307140747.h6E7lZpi000671@localhost.localdomain> [only tangentially related to python-dev, but a followup to a previous annoying problem] I finally got annoyed enough by the Redhat 9 tcl/tk disaster to do something about it. I grabbed the tcl/tk source for the version installed in RH9 (the original source, not the one modified by redhat) and rebuilt it, and made a couple of RPMs. http://www.interlink.com.au/anthony/tech/rh9-tcltk/ I have no idea at all about the state of unicode/UCS2/UCS4 in these builds, it's just built with whatever tcl/tk 8.3.5 builds by default. I only deal with 8 bit fonts, so I don't care enough about the state of multi-byte fonts in tcl/tk to spend time on this. I _do_ care about having my exmh chew through 100 meg of memory on startup and then leaking memory like a sieve, however, and this version of the RPMs seem to fix this. Python2.2-cvs and Python2.3-cvs seem to build fine against it. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From skip@pobox.com Mon Jul 14 13:19:17 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 14 Jul 2003 07:19:17 -0500 Subject: [Python-Dev] RE: [spambayes-dev] improving dumbdbm's survival chances... In-Reply-To: References: <16146.1745.865650.293138@montanaro.dyndns.org> Message-ID: <16146.40901.885251.591450@montanaro.dyndns.org> Tim> I'll approve the patch, so let's save time and just check it in. Done. Checked in the obvious fix for dumbdbm.py and added a minimal libdumbdbm.tex file to the Doc/lib directory (with appropriate stitches to tie it into the libref manual). For the spambayes-dev folks, I also checked in a change to spambayes/dbmstorage.py which makes db.sync == db._commit if it doesn't already have a sync method. Skip From blunck@gst.com Mon Jul 14 15:07:18 2003 From: blunck@gst.com (Christopher Blunck) Date: Mon, 14 Jul 2003 10:07:18 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <3F07FDDD.9040701@lemburg.com> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> Message-ID: <20030714140718.GC7911@homer.gst.com> On Sun, Jul 06, 2003 at 12:45:49PM +0200, M.-A. Lemburg wrote: > Anthony Baxter wrote: > >>>>"M.-A. Lemburg" wrote > Hmm, but how is CVS read-only access different from downloading > a tarball ? (except maybe for the different bandwidth they require > in case of updates) In terms of bandwidth, a CVS update is probably more efficient than a snapshot tarball downloaded over http. In terms of computational intensity, the tarball downloaded over http is more simplistic than a CVS update. A CVS update is also chattier than a snapshot tarball. And lastly, a CVS update is more I/O instensive (lots of file open and closes). If I were to guess, I'd say that the SF folks are experiencing CPU, I/O, and bandwidth problems. If they tell us all to use snapshot tarballs, it eliminates two of their problems (CPU and I/O), allowing them to focus on pure bandwidth issues. As a parallel activity, they can re-vamp their CVS infrastructure (which they've mentioned doing) and distribute the CPU and I/O over multiple resources. Disregard the rest of this if you're not interested in my personal opinion. It is my personal opinion that the sooner py is off sf.net's cvs server the better. Right now, Python co-habitates with other heavy projects on SF. Our CVS performance is negatively impacted by the success of other projects. The degradation is so severe in some cases that you can't even pull a CVS update via pserver (or you have to work with a copy 24 hours old). The cost in efficiency might be more than the dollar cost of hosting the repository elsewhere. -c -- 10:00:00 up 58 days, 23:35, 8 users, load average: 0.11, 0.20, 0.20 From Anthony Baxter Mon Jul 14 16:31:54 2003 From: Anthony Baxter (Anthony Baxter) Date: Tue, 15 Jul 2003 01:31:54 +1000 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <20030714140718.GC7911@homer.gst.com> Message-ID: <200307141531.h6EFVsH9010119@localhost.localdomain> >>> Christopher Blunck wrote > [ bunch of CVS-vs-tarball comparisions ] Most importantly, though - if you've got a local CVS checkout that you've modified (say, if you're working on a patch), you can do a cvs up and not lose your modifications. Unpacking a tarball over the top of your code doesn't tend to leave your mods around. :) Anthony From blunck@gst.com Mon Jul 14 20:52:17 2003 From: blunck@gst.com (Christopher Blunck) Date: Mon, 14 Jul 2003 15:52:17 -0400 Subject: [Python-Dev] Volunteering to help with pserver cvs on python.org Message-ID: <20030714195217.GA13186@homer.gst.com> In case anyone is interested or would like some help . . . I'm offering to help install/configure/support the installation of a pserver style cvs repository on python.org. I'm not sure if it's needed or desired, but wanted to offer anyway. -c -- 15:50:00 up 59 days, 5:25, 10 users, load average: 0.03, 0.05, 0.17 From martin@v.loewis.de Mon Jul 14 21:25:48 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 14 Jul 2003 22:25:48 +0200 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: <20030714140718.GC7911@homer.gst.com> References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <20030714140718.GC7911@homer.gst.com> Message-ID: Christopher Blunck writes: > It is my personal opinion that the sooner py is off sf.net's cvs server the > better. In this generality, I strongly disagree. It would be a desaster if the Python CVS would move before Python 2.3 is released; we would likely not meet our own deadline. Regards, Martin From blunck@gst.com Mon Jul 14 22:02:13 2003 From: blunck@gst.com (Christopher Blunck) Date: Mon, 14 Jul 2003 17:02:13 -0400 Subject: [Python-Dev] alternate pserver access for python CVS? In-Reply-To: References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <20030714140718.GC7911@homer.gst.com> Message-ID: <20030714210212.GA15492@homer.gst.com> On Mon, Jul 14, 2003 at 10:25:48PM +0200, Martin v. L=F6wis wrote: > Christopher Blunck writes: >=20 > > It is my personal opinion that the sooner py is off sf.net's cvs serv= er the > > better.=20 >=20 > In this generality, I strongly disagree. It would be a desaster if the > Python CVS would move before Python 2.3 is released; we would likely > not meet our own deadline. I agree. I'm not arguing for moving prior to the 2.3 release. It would = have to be done after to avoid downtime. -c --=20 17:00:00 up 59 days, 6:35, 10 users, load average: 0.41, 0.25, 0.15 From python@rcn.com Tue Jul 15 19:43:00 2003 From: python@rcn.com (Raymond Hettinger) Date: Tue, 15 Jul 2003 14:43:00 -0400 Subject: [Python-Dev] Python 2.3 release schedule update References: <1057762719.7056.11.camel@yyz> <1057845054.2600.19.camel@slothrop.zope.com> Message-ID: <001501c34b00$eaf035c0$a8b5958d@oemcomputer> > On Wed, 2003-07-09 at 10:58, Barry Warsaw wrote: > > The plan is to release 2.3rc1 on July 17, 2003. I'll be out of town, so > > Jeremy will do this release, with the usual help from Fred and Tim. > > If anyone has bugs or patches they'd like to see addressed before rc1, > please make sure the priority is at 7 or higher so that they are easier > to track. Are we still on track for a release on Thursday? Raymond ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# ################################################################# From jeremy@alum.mit.edu Tue Jul 15 21:29:00 2003 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: 15 Jul 2003 16:29:00 -0400 Subject: [Python-Dev] Python 2.3 release schedule update In-Reply-To: <001501c34b00$eaf035c0$a8b5958d@oemcomputer> References: <1057762719.7056.11.camel@yyz> <1057845054.2600.19.camel@slothrop.zope.com> <001501c34b00$eaf035c0$a8b5958d@oemcomputer> Message-ID: <1058300940.4459.148.camel@slothrop.zope.com> On Tue, 2003-07-15 at 14:43, Raymond Hettinger wrote: > > On Wed, 2003-07-09 at 10:58, Barry Warsaw wrote: > > > The plan is to release 2.3rc1 on July 17, 2003. I'll be out of town, so > > > Jeremy will do this release, with the usual help from Fred and Tim. > > > > If anyone has bugs or patches they'd like to see addressed before rc1, > > please make sure the priority is at 7 or higher so that they are easier > > to track. > > Are we still on track for a release on Thursday? I think we are. It looks like all the tests are passing and all the high priority bugs and patches are handled. I'm sitting on a patch for distutils support for VC 7.1 that I'd like to include. It looks safe. It's easy to verify that it doesn't break VC 6 and 7.0, and it can only improve things for VC 7.1. I expect to get to it tomorrow early AM. I think it's too late to do anything more about startup / teardown time. On the plus side, a couple simple benchmarks are showing good results for me. In addition to pystone, I'm doing an HTML benchmark -- feeding Hamlet to HTMLParser(). benchmark 2.1 2.2 2.3 pystone 5.02 4.68 3.68 html 19.96 20.97 15.93 That's shows Python 2.3 is 27% faster than 2.2.cvs for pystone and 31% faster for html. Jeremy From just@letterror.com Tue Jul 15 21:44:13 2003 From: just@letterror.com (Just van Rossum) Date: Tue, 15 Jul 2003 22:44:13 +0200 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: Message-ID: Martin v. L=F6wis wrote: > "Brett C." writes: >=20 > > And after I updated my copy of CVS and tried out the patch for > > tzset detection as mentioned above I got a failure in > > test_pep277.py (only difference between CVS and my checkout is > > configure.in and only in the tzset code and regrtest.py): >=20 > That would be most likely due to Just's activating > supports_unicode_filenames in posixpath.py. That seems to be correct. Unfortuanately I have no time to look into this, as I'm leaving tomorrow for a trip. Jack is also away (until the 22nd). Is anyone left on python-dev with an OSX box? Just From skip@pobox.com Tue Jul 15 22:33:16 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 15 Jul 2003 16:33:16 -0500 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: Message-ID: <16148.29468.500711.746030@montanaro.dyndns.org> Just> Is anyone left on python-dev with an OSX box? Yeah, me. I can't do anything this evening, but can look at it tomorrow. What's the bug id? Skip From martin@v.loewis.de Tue Jul 15 22:50:35 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 15 Jul 2003 23:50:35 +0200 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16148.29468.500711.746030@montanaro.dyndns.org> References: <16148.29468.500711.746030@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > Yeah, me. I can't do anything this evening, but can look at it tomorrow. > What's the bug id? No bug id: test_pep277 fails. Regards, Martin From pf_moore@yahoo.co.uk Tue Jul 15 22:41:52 2003 From: pf_moore@yahoo.co.uk (Paul Moore) Date: Tue, 15 Jul 2003 22:41:52 +0100 Subject: [Python-Dev] Re: Python 2.3 release schedule update References: <1057762719.7056.11.camel@yyz> <1057845054.2600.19.camel@slothrop.zope.com> <001501c34b00$eaf035c0$a8b5958d@oemcomputer> <1058300940.4459.148.camel@slothrop.zope.com> Message-ID: <7k6j5uxr.fsf@yahoo.co.uk> Jeremy Hylton writes: > I think it's too late to do anything more about startup / teardown > time. On the plus side, a couple simple benchmarks are showing good > results for me. In addition to pystone, I'm doing an HTML benchmark -- > feeding Hamlet to HTMLParser(). There's a bug, 771097, which appears to be the root cause of some problems with the various freeze-type utilities (Installer, cx_Freeze, py2exe). Is there any chance of this going in? Thanks, Paul. -- This signature intentionally left blank From kiko@async.com.br Tue Jul 15 23:24:22 2003 From: kiko@async.com.br (Christian Reis) Date: Tue, 15 Jul 2003 19:24:22 -0300 Subject: [Python-Dev] LC_NUMERIC and C libraries Message-ID: <20030715222422.GA3625@async.com.br> Hello there, I've been tracking down some usability issues in our GUI apps lately, and one of them has brought me through GTK+ [1] into the Python parser. The problem is simple: as per [2], The setlocale() function in the locale module gives the Python programmer the impression that you can manipulate the LC_NUMERIC locale setting, but this not the case at the C level: C code will always find that the LC_NUMERIC locale setting is "C". This is because too much would break when the decimal point character is set to something else than a period (e.g. the Python parser would break). This presents a problem to PyGTK in particular (and to other toolkits which are `numeric-aware') since the library it wraps, GTK+, depends on LC_NUMERIC being set correctly to be able to handle input in certain widgets correctly. Case at hand: GtkSpinButton, which allows the entry of values with decimal separator. The decimal separator needs to be localized, since our locale (pt_BR -- as do many others) uses commas instead of dots to separate decimals. Because Python always sets LC_NUMERIC to C, however, this doesn't work -- commas are rejected, as GTK+, while parsing the string, doesn't recognize it as a valid `float' (in the C locale). I've spoken briefly to Guido about this, and he's suggested python-dev as the place to ask. I'd really like to know how bad "too much would break" is, and if anybody contemplates a way to fix it [*]. I'd volunteer to work on the change, of course. [1] http://bugzilla.gnome.org/show_bug.cgi?id=114132 [2] http://www.python.org/doc/current/lib/embedding-locale.html [*] Havoc Pennington, from the GTK+ team, has offered a LC_NUMERIC-agnostic strtod() implementation, but I get the feeling this is more involved than just that. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From mhammond@skippinet.com.au Wed Jul 16 01:31:25 2003 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 16 Jul 2003 10:31:25 +1000 Subject: [Python-Dev] Re: Python 2.3 release schedule update In-Reply-To: <7k6j5uxr.fsf@yahoo.co.uk> Message-ID: <039f01c34b31$97ab1c00$f502a8c0@eden> > Jeremy Hylton writes: > > > I think it's too late to do anything more about startup / teardown > > time. On the plus side, a couple simple benchmarks are showing good > > results for me. In addition to pystone, I'm doing an HTML > benchmark -- > > feeding Hamlet to HTMLParser(). > > There's a bug, 771097, which appears to be the root cause of some > problems with the various freeze-type utilities (Installer, cx_Freeze, > py2exe). Is there any chance of this going in? I checked in my fix to that. Mark. From skip@pobox.com Wed Jul 16 03:42:32 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 15 Jul 2003 21:42:32 -0500 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: <16148.29468.500711.746030@montanaro.dyndns.org> Message-ID: <16148.48024.605585.84838@montanaro.dyndns.org> >>>>> "Martin" =3D=3D Martin v L=F6wis writes: Martin> Skip Montanaro writes: >> Yeah, me. I can't do anything this evening, but can look at it = tomorrow. >> What's the bug id? Martin> No bug id: test_pep277 fails. One problem seems obvious to me. test_pep277.UnicodeFileTests defines = this method: def test_listdir(self): f1 =3D os.listdir(test_support.TESTFN) f1.sort() f2 =3D os.listdir(unicode(test_support.TESTFN,"mbcs")) f2.sort() print f1 print f2 The unicode() call winds up trying to call codecs.mbcs_encode which is imported from the _codecs module. mbcs_encode is only defined on Windo= ws, and only if there is a usable wchar_t. It's clear this is going to fai= l on Mac OS X. This seems better: def test_listdir(self): =09import sys f1 =3D os.listdir(test_support.TESTFN) f1.sort() f2 =3D os.listdir(unicode(test_support.TESTFN, sys.getfilesystemencoding())) f2.sort() print f1 print f2 If someone with ready access to a Windows machine can try that change tonight I'll check it in, otherwise it will have to wait until I'm at w= ork tomorrow morning. The second error is due to details.filename at line 53 being a plain st= ring containing non-ASCII characters. When it is 'not_@test/Gr\xc3\xbc\xc3\x9f-Gott' and is compared with filename which= is u'not_@test/Gr\xc3\xbc\xc3\x9f-Gott' a UnicodeDecodeError is raised try= ing to coerce details.filename to unicode. Simply converting it using unicode(details.filename, sys.getfilesystemencoding()) before compariso= n doesn't seem correct, because there's no guarantee that details.filenam= e is in the file system encoding at that point. It certainly fails for me: >>> s =3D 'not_@test/Gr\xfc\xdf-Gott' >>> import sys >>> unicode(s, sys.getfilesystemencoding()) Traceback (most recent call last): File "", line 1, in ? UnicodeDecodeError: 'utf8' codec can't decode bytes in position 12-= 17: unsupported Unicode code range I suspect details.filename needs to be set to a unicode object, but I d= on't know where or how. Skip From tim.one@comcast.net Wed Jul 16 03:53:25 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 15 Jul 2003 22:53:25 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16148.48024.605585.84838@montanaro.dyndns.org> Message-ID: [Skip, test_pep277.py] > ... > This seems better: Not with hard tab characters it ain't . > def test_listdir(self): > import sys > f1 = os.listdir(test_support.TESTFN) > f1.sort() > f2 = os.listdir(unicode(test_support.TESTFN, > sys.getfilesystemencoding())) > f2.sort() > print f1 > print f2 > > If someone with ready access to a Windows machine can try that change > tonight I'll check it in, otherwise it will have to wait until I'm at > work tomorrow morning. Caution: if someone does this, say which version of Windows you used. This entire test file is skipped on Win95/98/ME, so a report of "no problem" from one of those won't help. I'll try it on Win2K tomorrow (I won't have access to Win2K until then). From mhammond@skippinet.com.au Wed Jul 16 04:48:36 2003 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 16 Jul 2003 13:48:36 +1000 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: Message-ID: <03ed01c34b4d$238cc960$f502a8c0@eden> > > If someone with ready access to a Windows machine can try > that change > > tonight I'll check it in, otherwise it will have to wait > until I'm at > > work tomorrow morning. > > Caution: if someone does this, say which version of Windows > you used. This > entire test file is skipped on Win95/98/ME, so a report of > "no problem" from > one of those won't help. > > I'll try it on Win2K tomorrow (I won't have access to Win2K > until then). win2k here, and after verifying that sys.getfilesystemencoding() is indeed "mbcs", testing, adding an import of the sys module and testing again , I felt confident enough to check it in! Mark. From martin@v.loewis.de Wed Jul 16 05:32:49 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 16 Jul 2003 06:32:49 +0200 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16148.48024.605585.84838@montanaro.dyndns.org> References: <16148.29468.500711.746030@montanaro.dyndns.org> <16148.48024.605585.84838@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > I suspect details.filename needs to be set to a unicode object, but I don't > know where or how. I see. You should revert Just's checkin of setting supports_unicode_filenames in posixpath.py. OSX doesn't. On Windows, posixmodule.c uses posix_error_with_unicode_filename, which recreates a Unicode object, whereas on Unix (including OSX) posix_error_with_filename is used, which puts the converted byte string into the exception. This is clearly brain-dead: AFAICT, in all cases, we are putting a basestring object into the exception essentially denoting a file name which we already have a Python object for. So this entire error handling should be changed to a new posix_error_with_basestring_filename, which would pass the original Python object that the user was providing, instead of creating new strings for the exception. However, this would be a significant rewrite of the entire error handling, which we can't do before 2.3. Regards, Martin From martin@v.loewis.de Wed Jul 16 05:44:21 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 16 Jul 2003 06:44:21 +0200 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <20030715222422.GA3625@async.com.br> References: <20030715222422.GA3625@async.com.br> Message-ID: Christian Reis writes: > I've spoken briefly to Guido about this, and he's suggested python-dev > as the place to ask. I'd really like to know how bad "too much would > break" is, and if anybody contemplates a way to fix it [*]. I'd volunteer to > work on the change, of course. I added the special-casing of LC_NUMERIC when I found Python can't parse floating point literals in Python source code anymore, in such a locale (de_DE uses the same convention). This is triggered by atof(3) changing its meaning, inside compile.c:parsenumber. If that was fixed, it would still be the case that the float() and str() builtins would change their meaning, with potential breakage to applications and the standard library. I can't give examples for such breakage myself right now - you might just want to run the test suite and see what breaks. However, it probably would be better if float() and str() continued to be locale-inaware. If you can come up with a change that really allows setting LC_NUMERIC, works on all platforms, has the above properties (parsing, float, and str don't change), and passes the test suite, I'm all in favour of adding it to 2.4. Regards, Martin From kiko@async.com.br Wed Jul 16 15:44:32 2003 From: kiko@async.com.br (Christian Reis) Date: Wed, 16 Jul 2003 11:44:32 -0300 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: References: <20030715222422.GA3625@async.com.br> Message-ID: <20030716144432.GH782@async.com.br> On Wed, Jul 16, 2003 at 06:44:21AM +0200, Martin v. L=F6wis wrote: > Christian Reis writes: >=20 > > I've spoken briefly to Guido about this, and he's suggested python-de= v > > as the place to ask. I'd really like to know how bad "too much would > > break" is, and if anybody contemplates a way to fix it [*]. I'd volun= teer to > > work on the change, of course.=20 >=20 > I added the special-casing of LC_NUMERIC when I found Python can't > parse floating point literals in Python source code anymore, in such a > locale (de_DE uses the same convention). This is triggered by atof(3) > changing its meaning, inside compile.c:parsenumber. Is there a good reason to prefer atof() over strtod(), if we already have a locale-safe version of the latter? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From dave@boost-consulting.com Wed Jul 16 18:14:32 2003 From: dave@boost-consulting.com (David Abrahams) Date: Wed, 16 Jul 2003 13:14:32 -0400 Subject: [Python-Dev] What is "installed"?, RE: [Python-Dev] What is "installed"?, Re: [Python-Dev] What is "installed"? In-Reply-To: <000a01c345f3$776ae710$f501a8c0@eden> (Mark Hammond's message of "Wed, 9 Jul 2003 18:24:06 +1000, Wed, 9 Jul 2003 21:33:58 -0400, Wed, 09 Jul 2003 10:28:41 +0200") References: <000a01c345f3$776ae710$f501a8c0@eden> Message-ID: Thanks to Mark, Tim, and Thomas for the valuable hints. Unfortunately, Leo seems to require something else. I guess I'm gonna download a regular installation now :(. "Mark Hammond" writes: > I generally setup the registry, by adding an "InstallPath" key. Most > extensions then work correctly, including distutils. Now that we have the > "_winreg" module, we should include a simple script you can run to setup > everything you need. > > FYI, all you should need is: > > HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\InstallPath: > pydir > > HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath: > pydir\lib;pydir\pcbuild > > where: > * "pydir" is the path to main Python directory - ie, parent of "PCBuild", > "Modules" etc > * The "2.3" is actually available in sys.winver > * The "PythonPath" entry is generally not needed, except in embedding > situations where the Python DLL isn't in the main Python build directory. > "Tim Peters" writes: > Another possibility is to use the native Windows facilities for fiddling the > registry. For example, edit the attached .reg file to taste, then > right-click on it in Explorer and select Merge from the context menu. Or > you can just double-click its icon. > Thomas Heller writes: > Does this help? > > http://effbot.org/zone/python-register.htm > > Thomas > -- Dave Abrahams Boost Consulting www.boost-consulting.com From martin@v.loewis.de Wed Jul 16 19:59:51 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 16 Jul 2003 20:59:51 +0200 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <20030716144432.GH782@async.com.br> References: <20030715222422.GA3625@async.com.br> <20030716144432.GH782@async.com.br> Message-ID: Christian Reis writes: > > I added the special-casing of LC_NUMERIC when I found Python can't > > parse floating point literals in Python source code anymore, in such a > > locale (de_DE uses the same convention). This is triggered by atof(3) > > changing its meaning, inside compile.c:parsenumber. > > Is there a good reason to prefer atof() over strtod(), if we already > have a locale-safe version of the latter? I don't think so - it is the same on systems where strtod is supported. However, I think Python uses atof since strtod might not be available. Regards, Martin From rwgk@cci.lbl.gov Wed Jul 16 20:12:34 2003 From: rwgk@cci.lbl.gov (Ralf W. Grosse-Kunstleve) Date: Wed, 16 Jul 2003 12:12:34 -0700 (PDT) Subject: [Python-Dev] DeprecationWarning: assignment shadows builtin Message-ID: <200307161912.h6GJCYcE085755@boa.lbl.gov> Starting with Python 2.3b2 I am getting DeprecationWarnings: Python 2.3b2 (#1, Jun 30 2003, 06:35:48) [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import std_vector __main__:1: DeprecationWarning: assignment shadows builtin >>> dir(std_vector) ['__doc__', '__file__', '__name__', 'array_cast', 'boost_array_sum', 'cos', 'double', 'float', 'in_place_multiply', 'int', 'long', 'size_t'] std_vector is a Boost.Python extension module (http://www.boost.org/libs/python/doc/index.html). It provides Python bindings for C++ std::vector<> template instantiations, for example: Python C++ std_vector.int std::vector std_vector.long std::vector std_vector.size_t std::vector std_vector.float std::vector std_vector.double std::vector Example usage: a = std_vector.float((1,2,3)) Does the DeprecationWarning mean that I cannot provide this intuitive interface anymore? It seems to me that the names of builtin types are essentially made equivalent to reserved keywords. I.e. from the user's perspective 2.3b2 introduces an inflation of reserved keywords. I am asking myself if the anticipated (?) performance benefits justify this intrusive change. Ralf From nas-python@python.ca Wed Jul 16 20:52:56 2003 From: nas-python@python.ca (Neil Schemenauer) Date: Wed, 16 Jul 2003 12:52:56 -0700 Subject: [Python-Dev] DeprecationWarning: assignment shadows builtin In-Reply-To: <200307161912.h6GJCYcE085755@boa.lbl.gov> References: <200307161912.h6GJCYcE085755@boa.lbl.gov> Message-ID: <20030716195256.GA4945@glacier.arctrix.com> Ralf W. Grosse-Kunstleve wrote: > >>> import std_vector > __main__:1: DeprecationWarning: assignment shadows builtin > >>> dir(std_vector) > ['__doc__', '__file__', '__name__', 'array_cast', 'boost_array_sum', > 'cos', 'double', 'float', 'in_place_multiply', 'int', 'long', 'size_t'] > > std_vector is a Boost.Python extension module I suspect the warning is shown due to the way Boost builds the namespace of the extension module. Shadowing of builtin names is checked by the setattr method of the module type. Boost is probably using module_setattr to populate the global dictionary. There's nothing wrong with doing that except that it triggers a spurious warning. > Does the DeprecationWarning mean that I cannot provide this intuitive > interface anymore? That was not the intention. Having module globals that shadow builtins is okay. The warning is supposed to be triggered if the scope of a name is changed from builtin to global at runtime. Eg: import string string.str = 'ha ha' That's a strange thing to do and I suspect there is little code out there that does it. Unfortunately the code that tries to detect it is imperfect. > It seems to me that the names of builtin types are essentially made > equivalent to reserved keywords. No, see above. Neil From pedronis@bluewin.ch Wed Jul 16 21:30:35 2003 From: pedronis@bluewin.ch (Samuele Pedroni) Date: Wed, 16 Jul 2003 22:30:35 +0200 Subject: [Python-Dev] DeprecationWarning: assignment shadows builtin In-Reply-To: <20030716195256.GA4945@glacier.arctrix.com> References: <200307161912.h6GJCYcE085755@boa.lbl.gov> <200307161912.h6GJCYcE085755@boa.lbl.gov> Message-ID: <5.2.1.1.0.20030716222255.0255c840@pop.bluewin.ch> At 12:52 16.07.2003 -0700, Neil Schemenauer wrote: > > Does the DeprecationWarning mean that I cannot provide this intuitive > > interface anymore? > >That was not the intention. Having module globals that shadow builtins >is okay. The warning is supposed to be triggered if the scope of a name >is changed from builtin to global at runtime. Eg: > > import string > string.str = 'ha ha' > >That's a strange thing to do and I suspect there is little code out >there that does it. Unfortunately the code that tries to detect it is >imperfect. I seriously think that the code triggering the warning should be backed off, I discussed about the warning/global speedup issue with Guido at Europython, I didn't propose there to back it off, and we didn't finish, still it was more or less clear that there is no strong case at the moment for the warning, because it is unclear whether is the right kind of flavor of limitation in terms of having a simple explanation for it, the issue with __init__ modules is still unclear etc... regards. From guido@python.org Wed Jul 16 21:43:44 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 16 Jul 2003 16:43:44 -0400 Subject: [Python-Dev] DeprecationWarning: assignment shadows builtin In-Reply-To: Your message of "Wed, 16 Jul 2003 12:52:56 PDT." <20030716195256.GA4945@glacier.arctrix.com> References: <200307161912.h6GJCYcE085755@boa.lbl.gov> <20030716195256.GA4945@glacier.arctrix.com> Message-ID: <200307162043.h6GKhiU26848@pcp02138704pcs.reston01.va.comcast.net> > Ralf W. Grosse-Kunstleve wrote: > > >>> import std_vector > > __main__:1: DeprecationWarning: assignment shadows builtin > > >>> dir(std_vector) > > ['__doc__', '__file__', '__name__', 'array_cast', 'boost_array_sum', > > 'cos', 'double', 'float', 'in_place_multiply', 'int', 'long', 'size_t'] > > > > std_vector is a Boost.Python extension module [Neil] > I suspect the warning is shown due to the way Boost builds the namespace > of the extension module. Shadowing of builtin names is checked by the > setattr method of the module type. Boost is probably using > module_setattr to populate the global dictionary. There's nothing wrong > with doing that except that it triggers a spurious warning. But this is yet another situation where this warning is issued but it really shouldn't be issued. I'm beginning to think that perhaps we should make it a PendingDeprecationWarning instead? That should be simple even this close to the 2.3c1 release. --Guido van Rossum (home page: http://www.python.org/~guido/) From Raymond Hettinger" If there is someone using WinME, please send me a note. I would like to have a second confirmation of a bug that appears to platform specific. Thanks, Raymond Hettinger -- stuck on the world's worst o.s. -- From nas-python@python.ca Wed Jul 16 22:22:09 2003 From: nas-python@python.ca (Neil Schemenauer) Date: Wed, 16 Jul 2003 14:22:09 -0700 Subject: [Python-Dev] DeprecationWarning: assignment shadows builtin In-Reply-To: <5.2.1.1.0.20030716222255.0255c840@pop.bluewin.ch> References: <200307161912.h6GJCYcE085755@boa.lbl.gov> <200307161912.h6GJCYcE085755@boa.lbl.gov> <5.2.1.1.0.20030716222255.0255c840@pop.bluewin.ch> Message-ID: <20030716212209.GA5440@glacier.arctrix.com> Samuele Pedroni wrote: > I seriously think that the code triggering the warning should be backed off, I'm inclined to agree. :-) Luckily the code is easy to back out if we decide to do so. Neil From nas-python@python.ca Wed Jul 16 22:24:27 2003 From: nas-python@python.ca (Neil Schemenauer) Date: Wed, 16 Jul 2003 14:24:27 -0700 Subject: [Python-Dev] DeprecationWarning: assignment shadows builtin In-Reply-To: <200307162043.h6GKhiU26848@pcp02138704pcs.reston01.va.comcast.net> References: <200307161912.h6GJCYcE085755@boa.lbl.gov> <20030716195256.GA4945@glacier.arctrix.com> <200307162043.h6GKhiU26848@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <20030716212426.GB5440@glacier.arctrix.com> Guido van Rossum wrote: > But this is yet another situation where this warning is issued but it > really shouldn't be issued. Yup, and I'm sure there are more. > I'm beginning to think that perhaps we should make it a > PendingDeprecationWarning instead? That should be simple even this > close to the 2.3c1 release. Changing the warning class or removing it completely should be no problem. Neil From tim.one@comcast.net Wed Jul 16 22:22:42 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 16 Jul 2003 17:22:42 -0400 Subject: [Python-Dev] WinME In-Reply-To: <004101c34bdc$3a990120$44b22c81@oemcomputer> Message-ID: [Raymond Hettinger] > If there is someone using WinME, please send me a note. Nobody on Python-Dev runs a baby OS. Chat it up anyway -- 98SE and ME generally act identically, the only real difference being that 98 is run by elite computer professionals. From guido@python.org Wed Jul 16 22:51:17 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 16 Jul 2003 17:51:17 -0400 Subject: [Python-Dev] DeprecationWarning: assignment shadows builtin In-Reply-To: Your message of "Wed, 16 Jul 2003 14:24:27 PDT." <20030716212426.GB5440@glacier.arctrix.com> References: <200307161912.h6GJCYcE085755@boa.lbl.gov> <20030716195256.GA4945@glacier.arctrix.com> <200307162043.h6GKhiU26848@pcp02138704pcs.reston01.va.comcast.net> <20030716212426.GB5440@glacier.arctrix.com> Message-ID: <200307162151.h6GLpHu27113@pcp02138704pcs.reston01.va.comcast.net> > Guido van Rossum wrote: > > But this is yet another situation where this warning is issued but it > > really shouldn't be issued. [Neil] > Yup, and I'm sure there are more. > > > I'm beginning to think that perhaps we should make it a > > PendingDeprecationWarning instead? That should be simple even this > > close to the 2.3c1 release. > > Changing the warning class or removing it completely should be no > problem. OK, let's remove it comletely. Its time will come. --Guido van Rossum (home page: http://www.python.org/~guido/) From gjc@inescporto.pt Thu Jul 17 10:30:06 2003 From: gjc@inescporto.pt (Gustavo J. A. M. Carneiro) Date: 17 Jul 2003 10:30:06 +0100 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: References: <20030715222422.GA3625@async.com.br> <20030716144432.GH782@async.com.br> Message-ID: <1058434206.19479.10.camel@spectrum.inescn.pt> A Qua, 2003-07-16 =E0s 19:59, Martin v. L=F6wis escreveu: > Christian Reis writes: >=20 > > > I added the special-casing of LC_NUMERIC when I found Python can't > > > parse floating point literals in Python source code anymore, in suc= h a > > > locale (de_DE uses the same convention). This is triggered by atof(= 3) > > > changing its meaning, inside compile.c:parsenumber. > >=20 > > Is there a good reason to prefer atof() over strtod(), if we already > > have a locale-safe version of the latter? >=20 > I don't think so - it is the same on systems where strtod is supported. > However, I think Python uses atof since strtod might not be available. I've been grepping through the Python source, and it seems both atof() and strtod() are used plenty. I made two new functions: Py_strtod() and Py_atof(), and replaced all calls to atof and strtod with calls to these new functions. At the moment, Py_atof() calls atof(), and Py_strtod() calls strtod(). Soon, I will replace them with an implementation based on glib's g_ascii_strtod. Open issues: 1- Naming: I'm hacking the Python source for the 1st time; Should I be using any other name, rather than Py_atof() and Py_strtod()? 2- float->string conversion: We need to get this replaced too, I guess. This one is more tricky. snprintf seems to be used for this, and it can produce strings with variable precision. glib has g_ascii_dtostr, but it always outputs numbers with the maximum precision that allows conversion back with g_ascii_strtod() without information loss. 3- Of course, I am not touching the locale module! =20 I'm going to proceed with this, but any advice is welcome! Regards. --=20 Gustavo Jo=E3o Alves Marques Carneiro From skip@pobox.com Thu Jul 17 13:57:32 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 17 Jul 2003 07:57:32 -0500 Subject: [Python-Dev] test_pep277 Message-ID: <16150.40252.164820.708110@montanaro.dyndns.org> We still have this problem about test_pep277. I suspect Martin's right that we should back out Just's change to posixpath and tackle it after the release. However, I wonder why this error with detail.filename not being a unicode object ERROR: test_failures (__main__.UnicodeFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "../Lib/test/test_pep277.py", line 64, in test_failures self._apply_failure(open, name, IOError) File "../Lib/test/test_pep277.py", line 54, in _apply_failure if check_fn_in_exception and details.filename != filename: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 12: ordinal not in range(128) isn't seen on Windows? I presume the IOError is raised and the same comparison is made. Is it possible that check_fn_in_exception is False on Windows? Skip From jeremy@alum.mit.edu Thu Jul 17 14:56:27 2003 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: 17 Jul 2003 09:56:27 -0400 Subject: [Python-Dev] test_pep277 In-Reply-To: <16150.40252.164820.708110@montanaro.dyndns.org> References: <16150.40252.164820.708110@montanaro.dyndns.org> Message-ID: <1058450187.7746.38.camel@slothrop.zope.com> On Thu, 2003-07-17 at 08:57, Skip Montanaro wrote: > We still have this problem about test_pep277. I suspect Martin's right that > we should back out Just's change to posixpath and tackle it after the > release. However, I wonder why this error with detail.filename not being a > unicode object I wasn't paying close enough attention. Can you point me at Martin's suggestion? I'd be happy to back out a change if it is doing more harm than good. BTW, I'll be hanging out on the python-dev channel of irc.freenode.net today if anyone wants to talk about the release. Jeremy From mal@lemburg.com Thu Jul 17 15:04:45 2003 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 17 Jul 2003 16:04:45 +0200 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <1058434206.19479.10.camel@spectrum.inescn.pt> References: <20030715222422.GA3625@async.com.br> <20030716144432.GH782@async.com.br> <1058434206.19479.10.camel@spectrum.inescn.pt> Message-ID: <3F16ACFD.8040603@lemburg.com> Gustavo J. A. M. Carneiro wrote: > 1- Naming: I'm hacking the Python source for the 1st time; Should I be > using any other name, rather than Py_atof() and Py_strtod()? PyOS_atof() and PyOS_strtod() would better fit the current scheme (see e.g. PyOS_strtoul()). -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jul 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2003-07-01: Released mxODBC.Zope.DA for FreeBSD 1.0.6 beta 1 From fdrake@acm.org Thu Jul 17 15:20:35 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 17 Jul 2003 10:20:35 -0400 Subject: [Python-Dev] Doc/ tree closes at noon, US/Eastern Message-ID: <16150.45235.157891.942002@grendel.zope.com> The Doc/ portion of the Python source tree will be closed at noon, US/Eastern time. That leaves one hour and 40 minutes for finding typos and making it really easy for me to fix your favorite documentation bugs/omissions. No complicated changes will be accepted. If you have an outstanding doc bug/patch on SourceForge that you feel absolutely *must* be addressed in Python 2.3, raise the priority to 7, but realize that the amount of time I can make available is fairly limited today. Thanks! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From just@letterror.com Thu Jul 17 15:35:56 2003 From: just@letterror.com (Just van Rossum) Date: Thu, 17 Jul 2003 09:35:56 -0500 Subject: [Python-Dev] Doc/ tree closes at noon, US/Eastern In-Reply-To: <16150.45235.157891.942002@grendel.zope.com> Message-ID: Fred L. Drake, Jr. wrote: > The Doc/ portion of the Python source tree will be closed at noon, > US/Eastern time. That leaves one hour and 40 minutes for finding > typos and making it really easy for me to fix your favorite > documentation bugs/omissions. No complicated changes will be > accepted. > > If you have an outstanding doc bug/patch on SourceForge that you feel > absolutely *must* be addressed in Python 2.3, raise the priority to 7, > but realize that the amount of time I can make available is fairly > limited today. I posted a note to the checkins list this morning about a readline.c change I'd like to see reversed. Considering I have nothing to do right now here in Minneapolis, I might as well do this myself. Any objections? Just From skip@pobox.com Thu Jul 17 15:43:40 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 17 Jul 2003 09:43:40 -0500 Subject: [Python-Dev] test_pep277 In-Reply-To: <1058450187.7746.38.camel@slothrop.zope.com> References: <16150.40252.164820.708110@montanaro.dyndns.org> <1058450187.7746.38.camel@slothrop.zope.com> Message-ID: <16150.46620.272097.219008@montanaro.dyndns.org> Jeremy> I wasn't paying close enough attention. Can you point me at Jeremy> Martin's suggestion? I'd be happy to back out a change if it is Jeremy> doing more harm than good. Martin's message is here: http://mail.python.org/pipermail/python-dev/2003-July/036874.html I think v1.61 of posixpath.py needs to be backed out. I don't know if Just made any doc changes to go along with it. Skip From jeremy@zope.com Thu Jul 17 15:44:43 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 17 Jul 2003 10:44:43 -0400 Subject: [Python-Dev] Doc/ tree closes at noon, US/Eastern In-Reply-To: References: Message-ID: <1058453082.7745.44.camel@slothrop.zope.com> On Thu, 2003-07-17 at 10:35, Just van Rossum wrote: > Fred L. Drake, Jr. wrote: > > > The Doc/ portion of the Python source tree will be closed at noon, > > US/Eastern time. That leaves one hour and 40 minutes for finding > > typos and making it really easy for me to fix your favorite > > documentation bugs/omissions. No complicated changes will be > > accepted. > > > > If you have an outstanding doc bug/patch on SourceForge that you feel > > absolutely *must* be addressed in Python 2.3, raise the priority to 7, > > but realize that the amount of time I can make available is fairly > > limited today. > > I posted a note to the checkins list this morning about a readline.c > change I'd like to see reversed. Considering I have nothing to do right > now here in Minneapolis, I might as well do this myself. Any objections? No objections, provided you also say what you'd like to see happen about the pep277 problem that Skip mentioned earlier today. Or maybe you should just go to the Mall of America :-). Jeremy From kiko@async.com.br Thu Jul 17 15:53:54 2003 From: kiko@async.com.br (Christian Reis) Date: Thu, 17 Jul 2003 11:53:54 -0300 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <1058434206.19479.10.camel@spectrum.inescn.pt> References: <20030715222422.GA3625@async.com.br> <20030716144432.GH782@async.com.br> <1058434206.19479.10.camel@spectrum.inescn.pt> Message-ID: <20030717145354.GN524@async.com.br> On Thu, Jul 17, 2003 at 10:30:06AM +0100, Gustavo J. A. M. Carneiro wrote: > I've been grepping through the Python source, and it seems both atof() > and strtod() are used plenty. I made two new functions: Py_strtod() and > Py_atof(), and replaced all calls to atof and strtod with calls to these > new functions. At the moment, Py_atof() calls atof(), and Py_strtod() > calls strtod(). Soon, I will replace them with an implementation based > on glib's g_ascii_strtod. I thought a bit about Martin's recommendation for float() and str(). Now this is a bit tricky, because if we *do* support LC_NUMERIC in a PyGTK interface, for instance, a spinbutton.get_text() that returned "50,00" would *not* be parseable by float(). The underlying truth is that locale-represented values will not be directly convertible to Python's C-locale values. I'm not sure this is correct. If it isn't I suggest two alternatives: offer an additional float() that *does* support LC_NUMERIC (float_localized?), or change float() semantics. If the latter, we might like to change float() to parse *both* the standard format and the locale-determined format. There may be [broken] code that relies on float raising a TypeError if something like "50,00" is passed to it, however. Other than that it seems safe as a special-case. Similar considerations work the opposite way for str(); however there is no option for the double behaviour we can support in float -- either it generates a locale-formatted float, or not, and the latter seems `more correct'. We have locale.format() for that anyway. Your opinions are appreciated, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From just@letterror.com Thu Jul 17 15:55:33 2003 From: just@letterror.com (Just van Rossum) Date: Thu, 17 Jul 2003 09:55:33 -0500 Subject: [Python-Dev] test_pep277 In-Reply-To: <16150.46620.272097.219008@montanaro.dyndns.org> Message-ID: Skip Montanaro wrote: > I think v1.61 of posixpath.py needs to be backed out. I don't know > if Just made any doc changes to go along with it. No, but there was a bug report: #767645. Btw. didn't mhammond's patch solve the issue well enough for now? (recompiling now, will test in a bit.) Just From nas@python.ca Thu Jul 17 18:26:44 2003 From: nas@python.ca (Neil Schemenauer) Date: Thu, 17 Jul 2003 10:26:44 -0700 Subject: [Python-Dev] ANSI strict aliasing and Python Message-ID: <20030717172643.GA9305@glacier.arctrix.com> Recently the GCC option -fno-strict-aliasing flag got added. The intention was to silence GCC warnings like this: ../Objects/object.c: In function `PyObject_IsTrue': ../Objects/object.c:1565: warning: dereferencing type-punned pointer will break strict-aliasing rules It looks like most (maybe all) of those warnings are triggered by Py_True and Py_False. Is there some other way of defining Py_True and Py_False so that we can avoid those errors? Maybe it's a lost cause anyhow, I don't really understand the ANSI spec on this issue. This is what I found: """ An object shall have its stored value accessed only by an lvalue that has one of the following types: * the declared type of the object, * a qualified version of the declared type of the object, * a type that is the signed or unsigned type corresponding to the declared type of the object, * a type that is the signed or unsigned type corresponding to a qualified version of the declared type of the object, * an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a sub-aggregate or contained union), or * a character type. """ Does this mean that code like: void f (PyObject *a, PyDictObject *b) { a->ob_refcnt += 1; b->ob_refcnt -= 1; } [...] f((PyObject *)somedict, somedict); is disallowed? Neil From jeremy@alum.mit.edu Thu Jul 17 19:09:03 2003 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: 17 Jul 2003 14:09:03 -0400 Subject: [Python-Dev] I've tagged the tree Message-ID: <1058465343.7746.54.camel@slothrop.zope.com> Now it really is too late for those last minutes changes. I've tagged the tree in anticipation of a release tonight. Jeremy From skip@pobox.com Thu Jul 17 19:18:40 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 17 Jul 2003 13:18:40 -0500 Subject: [Python-Dev] cygwin errors Message-ID: <16150.59520.379317.762429@montanaro.dyndns.org> I did a cvs up on cygwin to test out Michael Hudson's latest readline.c patch. That worked, but I get a lot of other test failures. I'm in the midst of other stuff and know next to nothing about what's expected out of cygwin. Can someone give me some hints? Things that are failing: test_netrc fails with NetrcParseError: bad toplevel token 'line1' (@test, line 4) during make test test_bz2 fails, test_pty, test_fork1 and test_popen2 crash, and it quits with signal 11 during test_select or test_poll Any suggestions? Skip From theller@python.net Thu Jul 17 19:25:06 2003 From: theller@python.net (Thomas Heller) Date: Thu, 17 Jul 2003 20:25:06 +0200 Subject: [Python-Dev] I've tagged the tree In-Reply-To: <1058465343.7746.54.camel@slothrop.zope.com> (Jeremy Hylton's message of "17 Jul 2003 14:09:03 -0400") References: <1058465343.7746.54.camel@slothrop.zope.com> Message-ID: Jeremy Hylton writes: > Now it really is too late for those last minutes changes. I've tagged > the tree in anticipation of a release tonight. I've just submitted SF 773179 and set the priority to 7 although it's just a very minor and cosmetical issue - only a comment is wrong. Feel free to lower this or ignore this, it can be fixed after 2.3rc1. Thomas From jason@tishler.net Thu Jul 17 21:47:30 2003 From: jason@tishler.net (Jason Tishler) Date: Thu, 17 Jul 2003 16:47:30 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <16150.59520.379317.762429@montanaro.dyndns.org> References: <16150.59520.379317.762429@montanaro.dyndns.org> Message-ID: <20030717204729.GA652@tishler.net> Skip, On Thu, Jul 17, 2003 at 01:18:40PM -0500, Skip Montanaro wrote: > Any suggestions? Not at the moment -- I'm still scratching my head... :,( I get the following: $ ./python.exe -E -tt ../Lib/test/regrtest.py -l -x test_poll \ test_popen test_popen2 test_pty test_queue test_select test_signal \ test_socket test_tempfile test_thread test_grammar [snip] test_zlib 210 tests OK. 4 tests failed: test___all__ test_csv test_netrc test_time 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_ioctl test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 1 skip unexpected on cygwin: test_ioctl Note that the excluded tests above work fine when run separately: $ ./python.exe -E -tt ../Lib/test/regrtest.py -l test_poll \ test_popen test_popen2 test_pty test_queue test_select test_signal \ test_socket test_tempfile test_thread test_poll test_popen test_popen2 test_pty test_queue test_select test_signal test_socket test_tempfile test_thread All 10 tests OK. I appreciate the heads up. I will dig deeper... Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From skip@pobox.com Thu Jul 17 22:47:50 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 17 Jul 2003 16:47:50 -0500 Subject: [Python-Dev] cygwin errors In-Reply-To: <20030717204729.GA652@tishler.net> References: <16150.59520.379317.762429@montanaro.dyndns.org> <20030717204729.GA652@tishler.net> Message-ID: <16151.6534.857633.947253@montanaro.dyndns.org> >> Any suggestions? Jason> Not at the moment -- I'm still scratching my head... :,( Hmmm... Some thoughts which come to my mind: * Do I need a cygwin update? How can I tell if I do or not? * Would having installed mingw and msys the other day have polluted the environment in some way? Skip From jason@tishler.net Thu Jul 17 23:17:59 2003 From: jason@tishler.net (Jason Tishler) Date: Thu, 17 Jul 2003 18:17:59 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <16151.6534.857633.947253@montanaro.dyndns.org> References: <16150.59520.379317.762429@montanaro.dyndns.org> <20030717204729.GA652@tishler.net> <16151.6534.857633.947253@montanaro.dyndns.org> Message-ID: <20030717221759.GA1140@tishler.net> Skip, [Sorry, this post is rushed...] On Thu, Jul 17, 2003 at 04:47:50PM -0500, Skip Montanaro wrote: > Hmmm... Some thoughts which come to my mind: > > * Do I need a cygwin update? Most likely not. > How can I tell if I do or not? You can rerun Cygwin's setup.exe and it will inform you whether or not there are newer packages available. > * Would having installed mingw and msys the other day have > polluted the environment in some way? Very unlike. Note that I'm seeing the same (or at least very similar) behavior on my setup too. BTW, before updating Python's CVS today, I ran the Python regression test against the latest official Cygwin packages, but a fairly stale version of Python CVS. I got a couple of failures but no crashes. Next, I updated to the latest Python CVS, built, and reran the regression test. Then, I started to get crashes like the ones you observed. Maybe the latest Python CVS is tickling some lurking Cygwin bug? I hope to have better information tomorrow. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From skip@pobox.com Thu Jul 17 23:21:14 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 17 Jul 2003 17:21:14 -0500 Subject: [Python-Dev] cygwin errors In-Reply-To: <20030717221759.GA1140@tishler.net> References: <16150.59520.379317.762429@montanaro.dyndns.org> <20030717204729.GA652@tishler.net> <16151.6534.857633.947253@montanaro.dyndns.org> <20030717221759.GA1140@tishler.net> Message-ID: <16151.8538.326572.913605@montanaro.dyndns.org> Jason> Next, I updated to the latest Python CVS, built, and reran the Jason> regression test. Then, I started to get crashes like the ones Jason> you observed. I must have misread your first response. I thought you weren't seeing the problems I encountered. At least the expert is seeing the same problems I am. Skip From martin@v.loewis.de Thu Jul 17 23:49:08 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 18 Jul 2003 00:49:08 +0200 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <20030717145354.GN524@async.com.br> References: <20030715222422.GA3625@async.com.br> <20030716144432.GH782@async.com.br> <1058434206.19479.10.camel@spectrum.inescn.pt> <20030717145354.GN524@async.com.br> Message-ID: Christian Reis writes: > The underlying truth is that locale-represented values will not be > directly convertible to Python's C-locale values. That is not true. locale.atof should allow you to parse the string. > I'm not sure this is correct. If it isn't I suggest two alternatives: > offer an additional float() that *does* support LC_NUMERIC > (float_localized?), or change float() semantics. I think this is unacceptable. In some languages, "." is used as the thousands-separator. Then, should "1.000" be 1e3, or 1e0? > There may be [broken] code that relies on float raising a TypeError if > something like "50,00" is passed to it, however. Other than that it > seems safe as a special-case. That code is not broken: It is a feature that float() accepts exactly the same syntax that you use in source code; see the documentation for string.atof. Regards, Martin From martin@v.loewis.de Thu Jul 17 23:50:54 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 18 Jul 2003 00:50:54 +0200 Subject: [Python-Dev] test_pep277 In-Reply-To: <16150.40252.164820.708110@montanaro.dyndns.org> References: <16150.40252.164820.708110@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > release. However, I wonder why this error with detail.filename not being a > unicode object [...] > isn't seen on Windows? Because Windows uses posixmodule.c:posix_error_with_unicode_filename, and Unix doesn't. Regards, Martin From kiko@async.com.br Thu Jul 17 23:57:30 2003 From: kiko@async.com.br (Christian Reis) Date: Thu, 17 Jul 2003 19:57:30 -0300 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: References: <20030715222422.GA3625@async.com.br> <20030716144432.GH782@async.com.br> <1058434206.19479.10.camel@spectrum.inescn.pt> <20030717145354.GN524@async.com.br> Message-ID: <20030717225730.GB4170@async.com.br> On Fri, Jul 18, 2003 at 12:49:08AM +0200, Martin v. L=F6wis wrote: > Christian Reis writes: >=20 > > The underlying truth is that locale-represented values will not be > > directly convertible to Python's C-locale values. >=20 > That is not true. locale.atof should allow you to parse the string. >=20 > > I'm not sure this is correct. If it isn't I suggest two alternatives: > > offer an additional float() that *does* support LC_NUMERIC > > (float_localized?), or change float() semantics.=20 >=20 > I think this is unacceptable. In some languages, "." is used as the > thousands-separator. Then, should "1.000" be 1e3, or 1e0? Okay, that's a good enough justification for me. We should be all set; I discussed this a bit with Gustavo this morning. The locale-safe versions of float() and str() should live in locale [*], and semantics for float() and str() stay unchanged. [*] Is there a reason why we only have atof() and not float() in locale? I'm asking because we *do* have str(). Would=20 locale.float =3D locale.atof =20 be a good idea, for consistency's sake? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From martin@v.loewis.de Fri Jul 18 00:01:24 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 18 Jul 2003 01:01:24 +0200 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: <20030717172643.GA9305@glacier.arctrix.com> References: <20030717172643.GA9305@glacier.arctrix.com> Message-ID: Neil Schemenauer writes: > It looks like most (maybe all) of those warnings are triggered by > Py_True and Py_False. While it is the case that only those places trigger the warning, the issue goes beyond that. All usages of PyObject* in Python are incorrect, and may result in bad code. > Is there some other way of defining Py_True and > Py_False so that we can avoid those errors? We would have to give up PyObject_HEAD, and make that a structure. > Does this mean that code like: > > void f (PyObject *a, PyDictObject *b) > { > a->ob_refcnt += 1; > b->ob_refcnt -= 1; > } > [...] > f((PyObject *)somedict, somedict); > > is disallowed? Correct. a->ob_refcnt += 1 has undefined behaviour, as 'a' does *not* point to a PyObject, but instead points to, say, a PyDictObject, and PyObject is not a field of PyDictObject. As a result of that, gcc can infer that 'a' and 'b' are different pointers, and it could implement that sequence as tmp1 = a->ob_refcnt; tmp2 = b->ob_refcnt; tmp1 += 1; tmp2 -= 1; a->ob_refcnt = tmp1; b->ob_refcnt = tmp2; The compiler could not use this optimization if we had struct _dictobject { PyObject _o; int ma_fill; int ma_used; int ma_mask; PyDictEntry *ma_table; PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, long hash); PyDictEntry ma_smalltable[PyDict_MINSIZE]; }; Then, of course, we'ld have to write b->_o->ob_refcnt -= 1; Regards, Martin From nas-python@python.ca Fri Jul 18 01:14:25 2003 From: nas-python@python.ca (Neil Schemenauer) Date: Thu, 17 Jul 2003 17:14:25 -0700 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: <20030717172643.GA9305@glacier.arctrix.com> Message-ID: <20030718001425.GA10963@glacier.arctrix.com> Martin v. L?wis wrote: > The compiler could not use this optimization if we had > > struct _dictobject { > PyObject _o; > int ma_fill; > int ma_used; > int ma_mask; > PyDictEntry *ma_table; > PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, long hash); > PyDictEntry ma_smalltable[PyDict_MINSIZE]; > }; That's what I suspected. If Python 3 was implemented using ANSI C, how would you suggest we implement objects? Neil From skip@pobox.com Fri Jul 18 01:19:29 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 17 Jul 2003 19:19:29 -0500 Subject: [Python-Dev] test_pep277 In-Reply-To: References: <16150.40252.164820.708110@montanaro.dyndns.org> Message-ID: <16151.15633.714084.302252@montanaro.dyndns.org> >> I wonder why this error with detail.filename not being a unicode >> object isn't seen on Windows? Martin> Because Windows uses Martin> posixmodule.c:posix_error_with_unicode_filename, and Unix Martin> doesn't. Thanks. I think I'll file a bug report for after 2.3. Skip From zaril@walla.co.il Fri Jul 18 01:42:08 2003 From: zaril@walla.co.il (zaril@walla.co.il) Date: Fri, 18 Jul 2003 03:42:08 +0300 Subject: [Python-Dev] SSL bug in socketmodule Message-ID: <200307180042.h6I0g8U20704@omail2.walla.co.il> --------=_WallaWebMail_38929_6299_Part_1000 Content-Type: text/plain Hi, I recently came across a bug in the SSL code in Modules/socketmodule.c. Most of the SSL functions support python threads, but the the constructor function for the SSL session does not. This can hang a multi threaded application if the SSL_connect stalls / hangs / takes a really long time etc. In my application, for example, this prevented me from cancelling an SSL connection to a badly routed destination, since the GUI hanged. Once I enabled threading support in that function in socketmodule.c, the problem was fixed. Is there any reason for the SSL constructor to be thread unsafe? Just thought I'd let you know. PS: I'm not a subcriber to python-dev, could someone update me if / how this was resolved? ----------------------------------------------------------------------- Walla! Mail, Get Your Private, Free E-mail from Walla! at: http://mail.walla.co.il --------=_WallaWebMail_38929_6299_Part_1000 Content-Type: text/html
Hi,
 
I recently came across a bug in the SSL code in Modules/socketmodule.c.
Most of the SSL functions support python threads, but the the constructor function for the SSL session
does not.
 
This can hang a multi threaded application if the SSL_connect stalls / hangs / takes a really long time etc.
In my application, for example, this prevented me from cancelling an SSL connection to a badly routed destination,
since the GUI hanged.
 
Once I enabled threading support in that function in socketmodule.c, the problem was fixed.
Is there any reason for the SSL constructor to be thread unsafe?
 
Just thought I'd let you know.
 
PS: I'm not a subcriber to python-dev, could someone update me if / how this was resolved?
 

Walla! Mail, Get Your Private, Free E-mail from Walla! at:
http://mail.walla.co.il
--------=_WallaWebMail_38929_6299_Part_1000-- From tim.one@comcast.net Fri Jul 18 01:54:59 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 17 Jul 2003 20:54:59 -0400 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: <20030717172643.GA9305@glacier.arctrix.com> Message-ID: [Neil Schemenauer] > Recently the GCC option -fno-strict-aliasing flag got added. The > intention was to silence GCC warnings like this: > > ../Objects/object.c: In function `PyObject_IsTrue': > ../Objects/object.c:1565: warning: dereferencing type-punned > pointer will break strict-aliasing rules This is strange (according to me). The real point of adding that option would be to prevent bad code generation in the presence of pretty common non-standard C code, but I don't know why a compiler would complain about PyObject_IsTrue: int PyObject_IsTrue(PyObject *v) { int res; if (v == Py_True) THIS IS LINE 1565 FOR ME return 1; if (v == Py_False) return 0; if (v == Py_None) return 0; else if (v->ob_type->tp_as_number != NULL && v->ob_type->tp_as_number->nb_nonzero != NULL) res = (*v->ob_type->tp_as_number->nb_nonzero)(v); else if (v->ob_type->tp_as_mapping != NULL && v->ob_type->tp_as_mapping->mp_length != NULL) res = (*v->ob_type->tp_as_mapping->mp_length)(v); else if (v->ob_type->tp_as_sequence != NULL && v->ob_type->tp_as_sequence->sq_length != NULL) res = (*v->ob_type->tp_as_sequence->sq_length)(v); else return 1; return (res > 0) ? 1 : res; } There are two reasons I'm confused: 1) The indicated line merely compares two addresses -- there's no dereferencing there. 2) There's nothing in the function that alters memory -- it simply doesn't matter whether non-standard aliasing exists in this code. When a warning makes no sense (as it appears to me in this case), trying to rewrite code to shut it up is a poke-and-hope waste of time. If it were pointing out an actual aliasing problem, fine. > It looks like most (maybe all) of those warnings are triggered by > Py_True and Py_False. Is there some other way of defining Py_True and > Py_False so that we can avoid those errors? Maybe it's a lost cause > anyhow, I don't really understand the ANSI spec on this issue. > ... > Does this mean that code like: > > void f (PyObject *a, PyDictObject *b) > { > a->ob_refcnt += 1; > b->ob_refcnt -= 1; > } > [...] > f((PyObject *)somedict, somedict); > > is disallowed? I agree with Martin that it's undefined, but there's nothing "like that" in PyObject_IsTrue. C's pointers are typed, and generally speaking a C compiler is free to assume that the memory areas pointed to by pointers of different types are disjoint. An optimizer can get some good out of that, by reordering loads and stores. A huge exception is made for char* pointers, which are assumed to potentially alias all other pointers. Minor exceptions are made for closely related types (like int* and unsigned int* pointers are assumed to potentially point to overlapping memory, unless the compiler can prove otherwise; but int* and float* pointers are assumed not to point to overlapping bytes). The way in which Python fakes inheritance by hand means there are potential problems all over the place (just about everywhere we cast to or from PyObject*), but very likely very few real problems. If the only ones gcc complains about involve Py_{True,False,None}, it's not being helpful. From tim.one@comcast.net Fri Jul 18 02:16:43 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 17 Jul 2003 21:16:43 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <20030717204729.GA652@tishler.net> Message-ID: [Jason Tishler] > I get the following: > > $ ./python.exe -E -tt ../Lib/test/regrtest.py -l -x test_poll \ > test_popen test_popen2 test_pty test_queue test_select > test_signal \ test_socket test_tempfile test_thread test_grammar > [snip] > test_zlib > 210 tests OK. > 4 tests failed: > test___all__ test_csv test_netrc test_time > 31 tests skipped: > test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl > test_curses test_dbm test_email_codecs test_gl test_imgfile > test_ioctl test_largefile test_linuxaudiodev test_locale > test_macfs test_macostools test_mpz test_nis > test_normalization test_ossaudiodev test_pep277 test_plistlib > test_scriptpackages test_socketserver test_sunaudiodev > test_timeout test_unicode_file test_urllibnet test_winreg > test_winsound 1 skip unexpected on cygwin: > test_ioctl > > Note that the excluded tests above work fine when run separately: > > $ ./python.exe -E -tt ../Lib/test/regrtest.py -l test_poll \ > test_popen test_popen2 test_pty test_queue test_select > test_signal \ test_socket test_tempfile test_thread > test_poll > test_popen > test_popen2 > test_pty > test_queue > test_select > test_signal > test_socket > test_tempfile > test_thread > All 10 tests OK. > > I appreciate the heads up. I will dig deeper... I've got a bad feeling that we may have a wild store (or such like) in 2.3. A day or two ago, Jeremy got a senseless and irreproducible error when running a ZODB test after compiling with 2.3 CVS, and just now I tried running regrtest with -r on Win98SE (-r randomizes test case order). That triggered an error I've never seen before and can't reproduce: test test_time failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. Nothing *screams* "wild store", though. For example, the failure in test_time may be due to some other test mucking with locale but not cleaning up after itself -- I simply don't know, and (worse) don't have time to pour into it. Possible helps: Check out regrtest's -f option (great for doing "binary searches" when a failure depends on running a certain subset of tests in a certain order). Try running the tests under a debug build (pymalloc's debugging armor in 2.3 debug builds catches many problems). If you get a reproducible baffling failure, try disabling cyclic gc (import gc; gc.disable()) to see whether the problem goes away (problems never get pinned on cyclic gc, but cyclic gc is often sensitive to out-of-bounds writes elsewhere). From python@rcn.com Fri Jul 18 02:23:58 2003 From: python@rcn.com (Raymond Hettinger) Date: Thu, 17 Jul 2003 21:23:58 -0400 Subject: [Python-Dev] SSL bug in socketmodule References: <200307180042.h6I0g8U20704@omail2.walla.co.il> Message-ID: <001e01c34ccb$43ebba20$65ba958d@oemcomputer> > I recently came across a bug in the SSL code in Modules/socketmodule.c. > Most of the SSL functions support python threads, but the the constructor function for the SSL session > does not. > > This can hang a multi threaded application if the SSL_connect stalls / hangs / takes a really long time etc. > In my application, for example, this prevented me from cancelling an SSL connection to a badly routed destination, > since the GUI hanged. > > Once I enabled threading support in that function in socketmodule.c, the problem was fixed. > Is there any reason for the SSL constructor to be thread unsafe? > > Just thought I'd let you know. > > PS: I'm not a subcriber to python-dev, could someone update me if / how this was resolved? Thanks for the note. The best way to report this is to use the SourceForge bug tracker. This helps us track it, discuss solutions, prioritize it, assign responsibility and to keep everyone informed about how it gets resolved. In contrast, sending a note to python-dev may result in it getting lost amid a flurry of postings. So, please repost the report at: http://sourceforge.net/tracker/?group_id=5470&atid=105470 Raymond Hettinger From tim.one@comcast.net Fri Jul 18 02:40:38 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 17 Jul 2003 21:40:38 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: Message-ID: Grrr. Here's a minimal failing set on Win98SE: $ python ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test_logging test_time test test_time failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. 2 tests OK. 1 test failed: test_time $ Remove either or both of the first two, and test_time passes. Probably related: swap the order of the first two, and test_strptime fails: $ python ../lib/test/regrtest.py test_logging test_strptime test_logging test_strptime test test_strptime failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_strptime.py", line 96, in test_lang "Setting of lang failed") File "C:\CODE\PYTHON\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: Setting of lang failed 1 test OK. 1 test failed: test_strptime $ These don't smell like wild stores. What happens on your box? If anyone else sees these failures, and can make time to dig, note that 1200 lines in the logging pkg live in logging/__init__.py (easy to overlook! very unusual). Note too that test_logging.py and _strptime.py both muck with locale. From tim@multitalents.net Fri Jul 18 03:37:58 2003 From: tim@multitalents.net (Tim Rice) Date: Thu, 17 Jul 2003 19:37:58 -0700 (PDT) Subject: [Python-Dev] Lib/encodings/rot_13.py Message-ID: In CVS and the release22-maint branch Lib/encodings/rot_13.py has #!/usr/local/bin/python2.1 Is this intentional? -- Tim Rice Multitalents (707) 887-1469 tim@multitalents.net From tim.one@comcast.net Fri Jul 18 03:44:41 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 17 Jul 2003 22:44:41 -0400 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: Message-ID: [python-dev-admin@python.org] > [Neil Schemenauer] >> Recently the GCC option -fno-strict-aliasing flag got added. The >> intention was to silence GCC warnings like this: >> >> ../Objects/object.c: In function `PyObject_IsTrue': >> ../Objects/object.c:1565: warning: dereferencing type-punned >> pointer will break strict-aliasing rules > > This is strange (according to me). The real point of adding that > option would be to prevent bad code generation in the presence of > pretty common non-standard C code, but I don't know why a compiler > would complain about PyObject_IsTrue: > > int > PyObject_IsTrue(PyObject *v) > { > int res; > if (v == Py_True) THIS IS LINE 1565 FOR ME > return 1; > if (v == Py_False) > return 0; > if (v == Py_None) > return 0; > else if (v->ob_type->tp_as_number != NULL && > v->ob_type->tp_as_number->nb_nonzero != NULL) > res = (*v->ob_type->tp_as_number->nb_nonzero)(v); > else if (v->ob_type->tp_as_mapping != NULL && > v->ob_type->tp_as_mapping->mp_length != NULL) > res = (*v->ob_type->tp_as_mapping->mp_length)(v); > else if (v->ob_type->tp_as_sequence != NULL && > v->ob_type->tp_as_sequence->sq_length != NULL) > res = (*v->ob_type->tp_as_sequence->sq_length)(v); > else > return 1; > return (res > 0) ? 1 : res; > } > > There are two reasons I'm confused: > > 1) The indicated line merely compares two addresses -- there's > no dereferencing there. > > 2) There's nothing in the function that alters memory -- it > simply doesn't matter whether non-standard aliasing exists in > this code. > > When a warning makes no sense (as it appears to me in this case), > trying to rewrite code to shut it up is a poke-and-hope waste of > time. If it were pointing out an actual aliasing problem, fine. > >> It looks like most (maybe all) of those warnings are triggered by >> Py_True and Py_False. Is there some other way of defining Py_True >> and Py_False so that we can avoid those errors? Maybe it's a lost >> cause anyhow, I don't really understand the ANSI spec on this issue. > >> ... Here's a short program, illustrating why test_strptime fails if it's run after test_logging, with no other tests between them: """ import locale if 0: locale.setlocale(locale.LC_ALL, '') import _strptime print _strptime.LocaleTime().lang print locale.getdefaultlocale()[0] print locale.getlocale(locale.LC_TIME) """ As-is on my box, it prints en_US en_US (None, None) Change "if 0" to "if 1", and it prints English_United States en_US ['English_United States', '1252'] Your turn . From skip@pobox.com Fri Jul 18 03:47:24 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 17 Jul 2003 21:47:24 -0500 Subject: [Python-Dev] Lib/encodings/rot_13.py In-Reply-To: References: Message-ID: <16151.24508.70635.400306@montanaro.dyndns.org> Tim> In CVS and the release22-maint branch Lib/encodings/rot_13.py has Tim> #!/usr/local/bin/python2.1 Tim> Is this intentional? Almost certainly not. It might make it into 2.3rc1, though I'm not sure of the status of the head branch of the CVS tree (TimP? Jeremy? Fred?). I checked in the obvious fix for the 2.2 maintenance branch, though I'm told the chances of a 2.2.4 release are slim. Skip From skip@pobox.com Fri Jul 18 03:50:41 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 17 Jul 2003 21:50:41 -0500 Subject: [Python-Dev] cygwin errors In-Reply-To: References: Message-ID: <16151.24705.854058.611883@montanaro.dyndns.org> [ failures in test_time, test_strptime, test_logging ] Tim> These don't smell like wild stores. What happens on your box? I've been unable to reproduce any of this on Mac OS X. I built --with-pydebug, tried those combinations you indicated as well as three regrtest -r runs (one with -uall), but saw nothing. I then returned to my build.O6 directory (OPT=-O6, -DNDEBUG), rebuilt and tried again. During the -r -uall -O6 run I got some assertion errors in the bsddb3 thread stuff: Exception in thread writer 0: Traceback (most recent call last): File "/Users/skip/src/python/head/dist/src/Lib/threading.py", line 436, in __bootstrap self.run() File "/Users/skip/src/python/head/dist/src/Lib/threading.py", line 416, in run self.__target(*self.__args, **self.__kwargs) File "/Users/skip/src/python/head/dist/src/Lib/bsddb/test/test_thread.py", line 254, in writerThread self.assertEqual(data, self.makeData(key)) File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: None != '0002-0002-0002-0002-0002' During both -r -uall runs (debug and non-debug builds) I got a warning during the bsddb3 tests: /Users/skip/src/python/head/dist/src/Lib/bsddb/dbutils.py:67: RuntimeWarning: DB_INCOMPLETE: Cache flush was unable to complete return function(*_args, **_kwargs) If the problem is with the locale code, Mac OS X is the wrong place to debug the problem as its locale support is apparently minimal: test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested I'll try some more cygwin tests tomorrow, though those failures looked a lot different than what you're seeing. Skip From jeremy@zope.com Fri Jul 18 04:24:52 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 17 Jul 2003 23:24:52 -0400 Subject: [Python-Dev] 2.3rc1 delayed Message-ID: I've decided to postpone the 2.3 release candidate 1 until Friday. Given the errors reported with current CVS on Cygwin, I don't expect that this release candidate stands much chance of becoming the final release. So I'd rather wait a little and see if anyone can make headway on the Cygwin problems. If we can fix something tomorrow, all the better. If not, we've only lost a day. I also checked in a probable fix for the problem Tim reported when running test_strptime, test_logging, and test_time in that order. I'm not confident that the fix is correct. Basically, it tries to restore the locale to its original value when test_logging finishes. Can someone who understands locales review that change? Please continue to avoid checkins on the head unless the changes are both trivial and critical <0.5 wink>. Jeremy From tim.one@comcast.net Fri Jul 18 04:26:25 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 17 Jul 2003 23:26:25 -0400 Subject: [Python-Dev] RE: [Python-checkins] python/dist/src/Lib/test test_logging.py,1.9,1.10 In-Reply-To: Message-ID: [Jeremy] > Modified Files: > test_logging.py > Log Message: > Restore the locale to "C" on exit. > > If this doesn't happen, it leaves the locale in a state that can cause > other tests to fail. For example, running test_strptime, > test_logging, and test_time in that order. Or test_logging, test_strptime in that order, with no other tests between them. Can someone who understands the intended use of locale (i.e., any non-American <0.5 wink>) figure out the right thing to do here? Or is forcing locale.LC_ALL to "C" at the end of test_logging the right thing already? I kinda doubt it, cuz it seems to bode ill if test_strptime fails "just because" someone changed locale before test_strptime got run. From tim.one@comcast.net Fri Jul 18 04:37:24 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 17 Jul 2003 23:37:24 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <16151.24705.854058.611883@montanaro.dyndns.org> Message-ID: [Skip Montanaro] > [ failures in test_time, test_strptime, test_logging ] > ... > I've been unable to reproduce any of this on Mac OS X. I built > --with-pydebug, tried those combinations you indicated as well as > three regrtest -r runs (one with -uall), but saw nothing. Jeremy saw the problem on Linux too, and checked in a locale hack that may or may not be appropriate. We're not going to do a release tonight. Partly because of this thing, but mostly because we want to give Jason a chance to stare at the Cygwin problems. Jeremy points out (correctly) that if we *expect* to make changes in order to repair the Cygwin woes, there's no real sense in which we could call what we have now a "release candidate". > I then returned to my build.O6 directory (OPT=-O6, -DNDEBUG), rebuilt > and tried again. > > During the -r -uall -O6 run I got some assertion errors in the bsddb3 > thread stuff: > > Exception in thread writer 0: > Traceback (most recent call last): > File "/Users/skip/src/python/head/dist/src/Lib/threading.py", > line 436, in __bootstrap > self.run() > File "/Users/skip/src/python/head/dist/src/Lib/threading.py", > line 416, in run > self.__target(*self.__args, **self.__kwargs) > File > "/Users/skip/src/python/head/dist/src/Lib/bsddb/test/test_thread.py" > , line 254, in writerThread > self.assertEqual(data, self.makeData(key)) > File "/Users/skip/src/python/head/dist/src/Lib/unittest.py", > line 292, in failUnlessEqual > raise self.failureException, \ > AssertionError: None != '0002-0002-0002-0002-0002' So what's the problem? None *isn't* equal to any big string, let alone one with a stuttering disability . OK, I note that writerThread() doesn't do the same thing each time it's run: it branches in two places based on the values random() returns. So it's not obvious to me whether it always should pass. > During both -r -uall runs (debug and non-debug builds) I got a warning > during the bsddb3 tests: > > /Users/skip/src/python/head/dist/src/Lib/bsddb/dbutils.py:67: > RuntimeWarning: DB_INCOMPLETE: Cache flush was unable to complete > return function(*_args, **_kwargs) I stopped worrying about warnings from test_bsddb3 -- but am not sure I should have. > If the problem is with the locale code, Mac OS X is the wrong place > to debug the problem as its locale support is apparently minimal: > > test_locale skipped -- Locale support on MacOSX is minimal and > cannot be tested > > I'll try some more cygwin tests tomorrow, though those failures > looked a lot different than what you're seeing. Yes, very, and I'm much more worried about them, especially to the extent they smell like wild-store kinda things. From python@rcn.com Fri Jul 18 04:36:58 2003 From: python@rcn.com (Raymond Hettinger) Date: Thu, 17 Jul 2003 23:36:58 -0400 Subject: [Python-Dev] 2.3rc1 delayed References: Message-ID: <005f01c34cdd$d7eca740$65ba958d@oemcomputer> From: "Jeremy Hylton" > I also checked in a probable fix for the problem Tim reported when > running test_strptime, test_logging, and test_time in that order. I'm > not confident that the fix is correct. Basically, it tries to restore > the locale to its original value when test_logging finishes. Can > someone who understands locales review that change? Please forgive if I'm stating the obvious, but the failing tests are the ones that should be changed, not the ones that are "polluting" the environment. When I was working on test_warnings.py, I had found that other tests had set warning filters without clearing them. Rather than alter the polluters, I fixed test_warnings so it either worked with existing filters or temporarily set its own -- that way the test would work in any combination with other tests. In a way, the polluters were helpful because they helped flag an unnecessary state dependency in the test_suite. So if test_strptime is going to be locale dependent, it should temporarily set what it expects to find. Raymond Hettinger ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# ################################################################# From tim.one@comcast.net Fri Jul 18 05:14:58 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 18 Jul 2003 00:14:58 -0400 Subject: [Python-Dev] 2.3rc1 delayed In-Reply-To: <005f01c34cdd$d7eca740$65ba958d@oemcomputer> Message-ID: [Raymond Hettinger] > Please forgive if I'm stating the obvious, but the failing tests > are the ones that should be changed, not the ones that are > "polluting" the environment. > > When I was working on test_warnings.py, I had found that other > tests had set warning filters without clearing them. Rather than > alter the polluters, I fixed test_warnings so it either worked with > existing filters or temporarily set its own -- that way the test would > work in any combination with other tests. In a way, the polluters > were helpful because they helped flag an unnecessary state > dependency in the test_suite. > > So if test_strptime is going to be locale dependent, it should > temporarily set what it expects to find. I'm not sure it's as simple as that either. For example, _strptime.py's LocaleTime class's .lang property caches the first value it sees, so that it will continue returning the same thing even if the user changes locale. As an American, I don't know whether that's a feature or a bug. Given all the locale-aware code in _strptime.py, I have to guess that it *intended* to be locale-independent, and it's obvious that the test_strptime.py test that failed is trying like hell not to assume any particular locale is in effect: def test_lang(self): # Make sure lang is set self.failUnless(self.LT_ins.lang in (locale.getdefaultlocale()[0], locale.getlocale(locale.LC_TIME), ''), "Setting of lang failed") Your guess about what that's testing is better than mine . From mhammond@skippinet.com.au Fri Jul 18 08:54:58 2003 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 18 Jul 2003 17:54:58 +1000 Subject: [Python-Dev] 2.3rc1 delayed In-Reply-To: Message-ID: <074c01c34d01$e2e943f0$f502a8c0@eden> > I've decided to postpone the 2.3 release candidate 1 until Friday. > Given the errors reported with current CVS on Cygwin, I don't expect > that this release candidate stands much chance of becoming the final > release. So I'd rather wait a little and see if anyone can make > headway on the Cygwin problems. If we can fix something tomorrow, all > the better. If not, we've only lost a day. In that case, a newly discovered bug that can cause site.py to fail is at http://www.python.org/sf/773476 I believe the patch is trivial and safe - anyone up for it? Mark. From apurv_anand@hotmail.com Fri Jul 18 10:44:11 2003 From: apurv_anand@hotmail.com (Apurv Anand) Date: Fri, 18 Jul 2003 15:14:11 +0530 Subject: [Python-Dev] Mail handeling with Python Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C34D3F.3DF76E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am very new to Python. Need to know if I can achieve this with Python: ~ Read a mail from Outlook 2000 Clinet (or may be from Exchange server = directly; but from the Client machine) ~ The mail will be filtered for certain words in subject / body (I want = to read only one perticular mail I will recieve every week) ~ Find (make code guess) a string within the mail. (Basically its a UNC = path that keeps changing according to the subfolders. The name of the = machine is same so i have to write something which can guess (find) the = UNC path within the mail (Its something like \\fileserver\foo\abc which = can change to \\fileserver\foo\xyx) ~ Open this UNC path and copy the contents to a local folder. Thanks for the help. - apurv ------=_NextPart_000_0005_01C34D3F.3DF76E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am very new to Python.
 
Need to know if I can achieve this with = Python:
~ Read a mail from Outlook 2000 Clinet = (or may be=20 from Exchange server directly; but from the Client machine)
~ The mail will be filtered for certain = words in=20 subject / body (I want to read only one perticular mail I will = recieve=20 every week)
~ Find (make code guess) a string = within the mail.=20 (Basically its a UNC path that keeps changing according to the = subfolders. The=20 name of the machine is same so i have to write something which can guess = (find)=20 the UNC path within the mail (Its something like \\fileserver\foo\abc which can = change to=20 \\fileserver\foo\xyx)
~ Open this UNC path and copy the = contents to a=20 local folder.
 
Thanks for the help.
- apurv
------=_NextPart_000_0005_01C34D3F.3DF76E10-- From python-dev@python.org Fri Jul 18 10:59:09 2003 From: python-dev@python.org (Alex Martelli) Date: Fri, 18 Jul 2003 11:59:09 +0200 Subject: [Python-Dev] Mail handeling with Python In-Reply-To: References: Message-ID: <200307181159.09142.aleaxit@yahoo.com> On Friday 18 July 2003 11:44 am, Apurv Anand wrote: > Hi, > > I am very new to Python. > > Need to know if I can achieve this with Python: > ~ Read a mail from Outlook 2000 Clinet (or may be from Exchange server > directly; but from the Client machine) ~ The mail will be filtered for I have not done this myself, but there are plenty of Google hits that suggest ways to proceed for this purpose. For example, check out http://www.boddie.org.uk/python/COM.html . > certain words in subject / body (I want to read only one perticular mail I > will recieve every week) ~ Find (make code guess) a string within the mail. > (Basically its a UNC path that keeps changing according to the subfolders. > The name of the machine is same so i have to write something which can > guess (find) the UNC path within the mail (Its something like > \\fileserver\foo\abc which can change to \\fileserver\foo\xyx) ~ Open this I'm not sure how you'll go about "guessing" (which seems a very different issue from _finding_) the string. Anyway, once you have the mail in memory you can apply both string searches and regular expressions. If you code a string literal, remember you need to double up backslashes (a syntax issue). > UNC path and copy the contents to a local folder. win32all (which you need to interface to Outlook) should also let you use UNC paths, I believe. Alex From tim@multitalents.net Fri Jul 18 16:27:55 2003 From: tim@multitalents.net (Tim Rice) Date: Fri, 18 Jul 2003 08:27:55 -0700 (PDT) Subject: [Python-Dev] 2.3rc1 delayed In-Reply-To: <074c01c34d01$e2e943f0$f502a8c0@eden> References: <074c01c34d01$e2e943f0$f502a8c0@eden> Message-ID: On Fri, 18 Jul 2003, Mark Hammond wrote: > > I've decided to postpone the 2.3 release candidate 1 until Friday. > > Given the errors reported with current CVS on Cygwin, I don't expect > > that this release candidate stands much chance of becoming the final > > release. So I'd rather wait a little and see if anyone can make > > headway on the Cygwin problems. If we can fix something tomorrow, all > > the better. If not, we've only lost a day. > > In that case, a newly discovered bug that can cause site.py to fail is at > http://www.python.org/sf/773476 > > I believe the patch is trivial and safe - anyone up for it? http://www.python.org/sf/771998 looks quite safe. It would be nice to have http://www.python.org/sf/772077 in too. > > Mark. > -- Tim Rice Multitalents (707) 887-1469 tim@multitalents.net From jeremy@zope.com Fri Jul 18 16:40:13 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 18 Jul 2003 11:40:13 -0400 Subject: [Python-Dev] 2.3rc1 delayed In-Reply-To: References: <074c01c34d01$e2e943f0$f502a8c0@eden> Message-ID: <1058542812.22834.0.camel@slothrop.zope.com> On Fri, 2003-07-18 at 11:27, Tim Rice wrote: > It would be nice to have http://www.python.org/sf/772077 in too. What effect would it have on other platforms? Jeremy From skip@pobox.com Fri Jul 18 17:21:38 2003 From: skip@pobox.com (Skip Montanaro) Date: Fri, 18 Jul 2003 11:21:38 -0500 Subject: [Python-Dev] cygwin errors In-Reply-To: References: Message-ID: <16152.7826.937429.502923@montanaro.dyndns.org> I made a little progress narrowing down the cygwin errors. If I simply run ./python.exe Lib/test/regrtest.py the first test which fails is test_bz2. If I run test_bz2 by itself it succeeds. I created a shell script which just executed pairs of tests, one of the ones which was run before test_bz2 followed by test_bz2. A couple tests caused test_bz2 to fail: test___all__ test_asynchat Here's the error output: C:\cygwin\home\Administrator\src\python\dist\src\python.exe: *** unable to remap C:\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x11B0000) != 0x11C0000 44 [main] python 1476 sync_with_child: child 1532(0x18C) died before initialization with status code 0x1 184 [main] python 1476 sync_with_child: *** child state child loading dlls C:\cygwin\home\Administrator\src\python\dist\src\python.exe: *** unable to remap C:\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x11B0000) != 0x11C0000 61438 [main] python 1476 sync_with_child: child 896(0x150) died before initialization with status code 0x1 61612 [main] python 1476 sync_with_child: *** child state child loading dlls C:\cygwin\home\Administrator\src\python\dist\src\python.exe: *** unable to remap C:\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x11B0000) != 0x11C0000 118777 [main] python 1476 sync_with_child: child 1452(0x114) died before initialization with status code 0x1 118944 [main] python 1476 sync_with_child: *** child state child loading dlls C:\cygwin\home\Administrator\src\python\dist\src\python.exe: *** unable to remap C:\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x11B0000) != 0x11C0000 208810 [main] python 1476 sync_with_child: child 1664(0xDC) died before initialization with status code 0x1 208994 [main] python 1476 sync_with_child: *** child state child loading dlls C:\cygwin\home\Administrator\src\python\dist\src\python.exe: *** unable to remap C:\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x11B0000) != 0x11C0000 294015 [main] python 1476 sync_with_child: child 1584(0xA0) died before initialization with status code 0x1 294200 [main] python 1476 sync_with_child: *** child state child loading dlls C:\cygwin\home\Administrator\src\python\dist\src\python.exe: *** unable to remap C:\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x11B0000) != 0x11C0000 371845 [main] python 1476 sync_with_child: child 1600(0x68) died before initialization with status code 0x1 372041 [main] python 1476 sync_with_child: *** child state child loading dlls test test_bz2 failed -- errors occurred; run in verbose mode for details 1 test OK. 1 test failed: test_bz2 [18388 refs] I then tried the same tactic with another crasher, test_fork1, and discovered these possible culprits: test___all__ test_asynchat test_cgi test_email There's the test_fork1 error output: C:\cygwin\home\Administrator\src\python\dist\src\python.exe: *** unable to remap C:\cygwin\bin\cygssl-0.9.7.dll to same address as parent(0x11B0000) != 0x11C0000 77 [main] python 1504 sync_with_child: child 1452(0x190) died before initialization with status code 0x1 212 [main] python 1504 sync_with_child: *** child state child loading dlls test test_fork1 crashed -- exceptions.OSError: [Errno 11] Resource temporarily unavailable 1 test OK. 1 test failed: test_fork1 [18201 refs] I then went back and tried test_cgi and test_email with test_bz2 (they don't run before test_bz2 in the normal case). Test_bz2 failed when run after either of them. In all cases with both test scenarios, the first test succeeded. I took a quick peek at the code of the possible culprits but didn't see anything which seemed to link them all together. Skip From jason@tishler.net Fri Jul 18 17:44:23 2003 From: jason@tishler.net (Jason Tishler) Date: Fri, 18 Jul 2003 12:44:23 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <16152.7826.937429.502923@montanaro.dyndns.org> References: <16152.7826.937429.502923@montanaro.dyndns.org> Message-ID: <20030718164422.GH1140@tishler.net> Skip, On Fri, Jul 18, 2003 at 11:21:38AM -0500, Skip Montanaro wrote: > I made a little progress narrowing down the cygwin errors. Unfortunately, not. > If I simply run > > ./python.exe Lib/test/regrtest.py > > the first test which fails is test_bz2. If I run test_bz2 by itself > it succeeds. I created a shell script which just executed pairs of > tests, one of the ones which was run before test_bz2 followed by > test_bz2. A couple tests caused test_bz2 to fail: > > test___all__ > test_asynchat > > Here's the error output: > > C:\cygwin\home\Administrator\src\python\dist\src\python.exe: *** > unable to remap C:\cygwin\bin\cygssl-0.9.7.dll to same address as > parent(0x11B0000) != 0x11C0000 The above is due to the dreaded Cygwin fork() problem that requires you to rebase your DLLs. The following are the relevant snippets from the Cygwin Python README: As of Cygwin Python 2.2.2-3, it is assumed that your Cygwin system has been rebased in order to prevent fork() failures due to DLL base address conflicts. Previous versions worked around this issue by building the _socket module statically. This hack no longer works with current Cygwin versions. See the issues section for more details. 3. Due to issues with Cygwin's fork() and DLL base address conflicts, one should rebase their Cygwin system to prevent fork() failures. Use the following procedure to rebase your system: a. install the Cygwin rebase package (if necessary) b. shutdown all Cygwin processes c. start bash (do not use rxvt) d. execute rebaseall (in the bash window) I was going to mention rebasing in a previous post but I didn't see the telltale "remap" error message. Sorry... Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From DavidA@ActiveState.com Fri Jul 18 17:45:03 2003 From: DavidA@ActiveState.com (David Ascher) Date: Fri, 18 Jul 2003 09:45:03 -0700 Subject: [Python-Dev] 2.3rc1 delayed In-Reply-To: References: Message-ID: <3F18240F.1090403@ActiveState.com> Jeremy Hylton wrote: >Please continue to avoid checkins on the head unless the changes are >both trivial and critical <0.5 wink>. > > www.python.org/771998 is trivial. It's probably not critical. Your call. From martin@v.loewis.de Fri Jul 18 18:04:28 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 18 Jul 2003 19:04:28 +0200 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: <20030718001425.GA10963@glacier.arctrix.com> References: <20030717172643.GA9305@glacier.arctrix.com> <20030718001425.GA10963@glacier.arctrix.com> Message-ID: Neil Schemenauer writes: > > The compiler could not use this optimization if we had > > > > struct _dictobject { > > PyObject _o; > > int ma_fill; > > int ma_used; > > int ma_mask; > > PyDictEntry *ma_table; > > PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, long hash); > > PyDictEntry ma_smalltable[PyDict_MINSIZE]; > > }; > > That's what I suspected. If Python 3 was implemented using ANSI C, how > would you suggest we implement objects? Maybe I was not clear enough: The above *is* ANSI C, and that's what I would use. Regards, Martin From martin@v.loewis.de Fri Jul 18 18:08:24 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 18 Jul 2003 19:08:24 +0200 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: Message-ID: "Tim Peters" writes: > This is strange (according to me). The real point of adding that option > would be to prevent bad code generation in the presence of pretty common > non-standard C code, but I don't know why a compiler would complain about > PyObject_IsTrue: [...] > if (v == Py_True) THIS IS LINE 1565 FOR ME Notice that a compiler is allowed to infer that the test is always false. Py_True is #define Py_True ((PyObject *) &_Py_TrueStruct) where _Py_TrueStruct is of type PyIntObject. A PyObject* could never ever possibly point to a PyIntObject. If you still compare the two, you obviously assume the language is not standard C. > The way in which Python fakes inheritance by hand means there are potential > problems all over the place (just about everywhere we cast to or from > PyObject*), but very likely very few real problems. If the only ones gcc > complains about involve Py_{True,False,None}, it's not being helpful. These are the ones that gcc recognizes. It can and will generate bad code all over the place. Regards, Martin From jason@tishler.net Fri Jul 18 18:11:00 2003 From: jason@tishler.net (Jason Tishler) Date: Fri, 18 Jul 2003 13:11:00 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: References: <16151.24705.854058.611883@montanaro.dyndns.org> Message-ID: <20030718171059.GI1140@tishler.net> --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 17, 2003 at 11:37:24PM -0400, Tim Peters wrote: > Partly because of this thing, but mostly because we want to give Jason > a chance to stare at the Cygwin problems. Unfortunately, I don't have that much to report: 1. It appears that Cygwin Python is crashing without even generating the normal Cygwin stackdump file. 2. When run inside of gdb and I get reproducible SEGVs when executing test_poll and test_popen (if test_poll is excluded). The SEGVs are inside of Cygwin so I will have to build a debuggable Cygwin DLL before I can dig deeper. At first glance, it doesn't look like Python is passing garbage into Cygwin. See attached for some backtraces, if interested. 3. I am observing the same (or at least similar) behavior that Tim is seeing with Win32 Python. I will try to do some debugging over the weekend but I may not have more until Monday. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test_poll.out" (gdb) bt #0 0x77f88e63 in ?? () #1 0x77ea9c13 in WaitForMultipleObjects () from /mnt/c/WINNT/system32/KERNEL32.DLL #2 0x6106ca98 in select () from /usr/bin/cygwin1.dll #3 0x6106c223 in select () from /usr/bin/cygwin1.dll #4 0x61059e7d in poll () from /usr/bin/cygwin1.dll #5 0x60d822f5 in poll_poll (self=0xad30658, args=0xa57599c) at /home/jt/src/PythonCvs/Modules/selectmodule.c:482 (gdb) p *self $3 = {_ob_next = 0xadb0178, _ob_prev = 0xadb13f4, ob_refcnt = 2, ob_type = 0x60d85260, dict = 0xadb13f4, ufd_uptodate = 1, ufd_len = 1, ufds = 0xa1d84a8} (gdb) p self->ufd_len $4 = 1 (gdb) p self->ufds $5 = (struct pollfd *) 0xa1d84a8 (gdb) p *self->ufds $6 = {fd = 8, events = 1, revents = 0} --DocE+STaALJfprDB Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="test_popen.out" Content-Transfer-Encoding: 8bit (gdb) bt #0 0x77f88e63 in ?? () #1 0x77ea9c13 in WaitForMultipleObjects () from /mnt/c/WINNT/system32/KERNEL32.DLL #2 0x61005b18 in cygwin1!__assert () from /usr/bin/cygwin1.dll #3 0x610590a3 in cygwin_winpid_to_pid () from /usr/bin/cygwin1.dll #4 0x61016fb5 in cygwin_internal () from /usr/bin/cygwin1.dll #5 0x6107df3d in readv () from /usr/bin/cygwin1.dll #6 0x6107dadc in read () from /usr/bin/cygwin1.dll #7 0x610c6dc6 in wmemset () from /usr/bin/cygwin1.dll #8 0x610c5523 in wmemset () from /usr/bin/cygwin1.dll #9 0x610c2290 in wmemset () from /usr/bin/cygwin1.dll #10 0x610b39e6 in fread () from /usr/bin/cygwin1.dll #11 0x6b261e95 in Py_UniversalNewlineFread (buf=0xab9ad24 "['-c', 'foo', 'bar']\n", 'Ë' ..., n=8192, stream=0xa04229c, fobj=0xadc01e0) at ../Objects/fileobject.c:2326 #12 0x6b25e858 in file_read (f=0xadc01e0, args=0xa045034) at ../Objects/fileobject.c:804 #13 0x6b27e3ab in PyCFunction_Call (func=0xaca06fc, arg=0xa045034, kw=0x0) at ../Objects/methodobject.c:73 #14 0x6b2cca02 in call_function (pp_stack=0x22eb84, oparg=0) at ../Python/ceval.c:3439 #15 0x6b2c8d65 in eval_frame (f=0xa52b864) at ../Python/ceval.c:2116 #16 0x6b2ccd45 in fast_function (func=0xadb9994, pp_stack=0x22ed04, n=2, na=2, nk=0) at ../Python/ceval.c:3518 #17 0x6b2ccb44 in call_function (pp_stack=0x22ed04, oparg=2) at ../Python/ceval.c:3458 #18 0x6b2c8d65 in eval_frame (f=0xa5e15d4) at ../Python/ceval.c:2116 #19 0x6b2ccd45 in fast_function (func=0xadb99e4, pp_stack=0x22ee84, n=0, na=0, nk=0) at ../Python/ceval.c:3518 #20 0x6b2ccb44 in call_function (pp_stack=0x22ee84, oparg=0) at ../Python/ceval.c:3458 #21 0x6b2c8d65 in eval_frame (f=0xbfc479c) at ../Python/ceval.c:2116 #22 0x6b2ccd45 in fast_function (func=0xadb9a34, pp_stack=0x22f004, n=0, na=0, nk=0) at ../Python/ceval.c:3518 #23 0x6b2ccb44 in call_function (pp_stack=0x22f004, oparg=0) at ../Python/ceval.c:3458 #24 0x6b2c8d65 in eval_frame (f=0xa5ed21c) at ../Python/ceval.c:2116 #25 0x6b2cacf4 in PyEval_EvalCodeEx (co=0xadc0290, globals=0xadc3994, locals=0xadc3994, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2663 #26 0x6b2c2d7f in PyEval_EvalCode (co=0xadc0290, globals=0xadc3994, locals=0xadc3994) at ../Python/ceval.c:537 --DocE+STaALJfprDB-- From tim.one@comcast.net Fri Jul 18 18:55:13 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 18 Jul 2003 13:55:13 -0400 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: Message-ID: [Tim] >> This is strange (according to me). The real point of adding that >> option would be to prevent bad code generation in the presence of >> pretty common non-standard C code, but I don't know why a compiler >> would complain about PyObject_IsTrue: > [...] >> if (v == Py_True) THIS IS LINE 1565 FOR ME [martin@v.loewis.de] > Notice that a compiler is allowed to infer that the test is always > false. I don't buy that. I'll buy that the result of the comparison is undefined by C, and that a hostile implementation of C could arbitrarily decide to call all such expressions false -- or arbitrarily decide to call all such expressions true. > Py_True is > > #define Py_True ((PyObject *) &_Py_TrueStruct) > > where _Py_TrueStruct is of type PyIntObject. A PyObject* could never > ever possibly point to a PyIntObject. I don't buy that because C simply doesn't define the result of (PyObject *) &_Py_TrueStruct Since it's undefined, a compiler would be within its rights to create a pointer that happened to (or not to) compare equal to any other particular PyObject *, or to segfault, or whatever. But that's not the point I was trying to make: the text of the warning message Neil quoted warned about dereferencing, but there is no dereferencing going on in the line it's complaining about. > If you still compare the two, you obviously assume the language is not > standard C. Indeed we do. If we had to, we could cast both sides of such comparisons to char* first. The result of that is defined (they have to point to the "lowest-addressed byte of the object", and that's exactly what we intend get compared in these cases). So I'm not worried about the specific things gcc is complaining about -- they could be wormed around with mechanical pain, so are just nuisances. I'm more worried about real problems : >> The way in which Python fakes inheritance by hand means there are >> potential problems all over the place (just about everywhere we cast >> to or from PyObject*), but very likely very few real problems. If >> the only ones gcc complains about involve Py_{True,False,None}, it's >> not being helpful. > These are the ones that gcc recognizes. It can and will generate bad > code all over the place. Has anyone tried running Python compiled without no-strict-aliasing? If so, how bad was it? I expect that Python's call test branch call test branch ... coding style inhibits most reordering optimizations anyway. The other question is whether no-strict-aliasing prevents such optimizations. If it does, then we should probably always use it. programmers-who-want-aggressive-anti-aliasing-assumptions-should- stick-to-fortran-ly y'rs - tim From skip@pobox.com Fri Jul 18 20:30:16 2003 From: skip@pobox.com (Skip Montanaro) Date: Fri, 18 Jul 2003 14:30:16 -0500 Subject: [Python-Dev] cygwin errors In-Reply-To: <16152.7826.937429.502923@montanaro.dyndns.org> References: <16152.7826.937429.502923@montanaro.dyndns.org> Message-ID: <16152.19144.692505.185966@montanaro.dyndns.org> A little more poking around with Google using the error messages I saw led me to Jason's site: http://www.tishler.net/jason/software/rebase/rebase-2.2.README I installed the rebase package and ran "rebaseall -v" after a fresh reboot from a cmd window running bash, then rebuilt python.exe from scratch. That didn't help with the test_bz2 or test_fork1 failures. regrtest.py also still craps out in test_poll (though not if run by itself), so I tried my pairs-o-tests script again with test_poll as the second test. Nada. test_poll always succeeded, regardless of the result of the preceeding test (success, skip, failure). I then tried (unsuccessfully) another tack. I threw all the test names into a file then ran ./python.exe Lib/test/regrtest.py `head $i tests | tail -20` test_poll for $i ranging from 20 to 230 (the number of lines in the file) in steps of 10. This tickled a fork() problem with test_tempfile in one situation which seems like the thing rebaseall was supposed to fix. I never saw it croak in test_poll though. I'm not really equipped to deal with this, so I'm going to leave the debugging to Jason. If the evidence Jason collects suggests Python is tickling a Cygwin bug I think we should forge ahead with the release candidate unless a workaround is immediately obvious. There's a fairly hard deadline for the final release of July 31 so that Python 2.3 gets in the next version of Mac OS X. Jack, Just and the rest of the MacPython gang have put a lot of effort into Python between 2.2 and 2.3. It would be a shame to see it miss Apple's release train. Skip From jeremy@zope.com Fri Jul 18 21:12:43 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 18 Jul 2003 16:12:43 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <16152.19144.692505.185966@montanaro.dyndns.org> References: <16152.7826.937429.502923@montanaro.dyndns.org> <16152.19144.692505.185966@montanaro.dyndns.org> Message-ID: <1058559163.22834.20.camel@slothrop.zope.com> On Fri, 2003-07-18 at 15:30, Skip Montanaro wrote: > I'm not really equipped to deal with this, so I'm going to leave the > debugging to Jason. If the evidence Jason collects suggests Python is > tickling a Cygwin bug I think we should forge ahead with the release > candidate unless a workaround is immediately obvious. There's a fairly hard > deadline for the final release of July 31 so that Python 2.3 gets in the > next version of Mac OS X. Jack, Just and the rest of the MacPython gang > have put a lot of effort into Python between 2.2 and 2.3. It would be a > shame to see it miss Apple's release train. Yeah. We decided not to wait, and the release is almost ready. Jeremy From jeremy@alum.mit.edu Fri Jul 18 22:09:15 2003 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: 18 Jul 2003 17:09:15 -0400 Subject: [Python-Dev] Python 2.3 release candidate 1 Message-ID: <1058562554.22833.38.camel@slothrop.zope.com> I am very happy to announce the release of Python 2.3 release candidate 1. The python-dev crew has fixed almost 50 bugs since the beta release last month. You can find the downloads at the usual place: http://www.python.org/2.3/ All major reported bugs have been fixed for this release. If we do not discover any major bugs in the next week, we will re-release this code as Python 2.3 final. We encourage potential users of Python 2.3 to try the release candidate with their programs and report any bugs as soon as possible. To report a new bug, use the SourceForge bug tracker http://sourceforge.net/bugs/?func=addbug&group_id=5470 This release of Python does not have any big changes, but it does have many small changes that improve the libraries, fix bugs, and increase stability. According to some simple benchmarks, Python 2.3 is 25-30% faster than Python 2.2.3. There are about 15 new or significantly revised standard library modules, and a few new builtins. Andrew Kuchling's What's New in Python 2.3 describes the most visible changes since Python 2.2 in more detail: http://www.python.org/doc/2.3c1/whatsnew/ Have fun! -- Jeremy Hylton From jeremy@zope.com Fri Jul 18 22:15:43 2003 From: jeremy@zope.com (Jeremy Hylton) Date: 18 Jul 2003 17:15:43 -0400 Subject: [Python-Dev] post-release festivities Message-ID: We've done with the 2.3c1 release. Now let's hope those Cygwin bugs aren't our fault, so we don't need to do another release candidate. I wanted to mention, primarily for Jack's benefit, that I never made a CVS branch for this release (what would have been r23c1-branch). I made a -fork tag, but saw the need to make a branch. But I did tag the tree if you need to make a branch from that tag. I also did a post-release tag r23c1, which should be the same as r23rc1-fork. I'm going to be moving this weekend, and I'll have intermittent connectivity next week. So Barry will have to do the final release without me. Jeremy From klm@zope.com Fri Jul 18 22:28:37 2003 From: klm@zope.com (Ken Manheimer) Date: Fri, 18 Jul 2003 17:28:37 -0400 (EDT) Subject: [Python-Dev] Exception masking/chaining In-Reply-To: <200306130015.h5D0FRh16022@oma.cosc.canterbury.ac.nz> Message-ID: On Fri, 13 Jun 2003, Greg Ewing wrote: > > > I'm not keen on the name "cause" for the start of the exception chain. > > > I'm not sure I have a better suggestion. Maybe "antecedent"? ;/ > > > > "reason"? > > That doesn't seem any better than "cause". Maybe "precursor"? +1 -- Ken klm@zope.com From python@rcn.com Fri Jul 18 22:51:37 2003 From: python@rcn.com (Raymond Hettinger) Date: Fri, 18 Jul 2003 17:51:37 -0400 Subject: [Python-Dev] post-release festivities References: Message-ID: <005101c34d76$c38a3440$f7bc2c81@oemcomputer> > We've done with the 2.3c1 release. Oh, yeah! > Now let's hope those Cygwin bugs > aren't our fault, so we don't need to do another release candidate. > > I wanted to mention, primarily for Jack's benefit, that I never made a > CVS branch for this release (what would have been r23c1-branch). I > made a -fork tag, but saw the need to make a branch. But I did tag > the tree if you need to make a branch from that tag. Is it appropriate to load improvements to the docs during this week or is it hands-off for everything except new, critical bugs? Raymond Hettinger From tim.one@comcast.net Fri Jul 18 23:18:00 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 18 Jul 2003 18:18:00 -0400 Subject: [Python-Dev] post-release festivities In-Reply-To: <005101c34d76$c38a3440$f7bc2c81@oemcomputer> Message-ID: [Raymond Hettinger] > Is it appropriate to load improvements to the docs during this > week or is it hands-off for everything except new, critical bugs? In a perfect world, the only thing that would change between 2.3c1 and 2.3 final is the bits of code from which version numbers derive -- stability is the highest priority for a release candidate. It's possible that, e.g., the Cygwin woes will get pinned on the Python core before 2.3 final is released, and then if the fix(es) is(are) at all subtle, we'll have to do another release candidate. If people are eager to check in random improvements, it would be best to make a branch out of the rc1 tag (and random improvements could proceed on the head). From python@rcn.com Fri Jul 18 23:25:35 2003 From: python@rcn.com (Raymond Hettinger) Date: Fri, 18 Jul 2003 18:25:35 -0400 Subject: [Python-Dev] post-release festivities References: Message-ID: <007b01c34d7b$827c3480$f7bc2c81@oemcomputer> > If people are eager to check in random improvements, it would be best to > make a branch out of the rc1 tag (and random improvements could proceed on > the head). In that case, I prefer to leave it alone. All that was being contemplated was fixing some URLs in the docs and adding more examples. That can wait for another day. Raymond Hettinger From tim.one@comcast.net Fri Jul 18 23:36:37 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 18 Jul 2003 18:36:37 -0400 Subject: [Python-Dev] post-release festivities In-Reply-To: <007b01c34d7b$827c3480$f7bc2c81@oemcomputer> Message-ID: [Tim] >> If people are eager to check in random improvements, it would be >> best to make a branch out of the rc1 tag (and random improvements >> could proceed on the head). [Raymond Hettinger] > In that case, I prefer to leave it alone. Well, a branch isn't a big deal, if that's what people want. > All that was being contemplated was fixing some URLs in > the docs and adding more examples. That can wait for another day. All changes have potential to break something, even changes that someone swears will be 100% harmless, and even if everyone else agrees in advance they're going to be 100% harmless. That simply can't be known for sure in advance (maybe adding a character to a URL will provoke a buffer overflow in the stuff generating Emacs info-mode docs -- who knows? that's right, Fred ), and release candidates are our only chance to get a close-as-possible preview of the actual release into the field for user testing. Doc improvements are great, most of the time. From martin@v.loewis.de Sat Jul 19 02:07:47 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 19 Jul 2003 03:07:47 +0200 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: Message-ID: "Tim Peters" writes: > > Notice that a compiler is allowed to infer that the test is always > > false. > > I don't buy that. I'll buy that the result of the comparison is undefined > by C, and that a hostile implementation of C could arbitrarily decide to > call all such expressions false -- or arbitrarily decide to call all such > expressions true. You are right: it is undefined, so an implementation that always gives false might still be conforming. The closest statement to defining behaviour is 6.3.2.3p7: # A pointer to an object or incomplete type may be converted to a # pointer to a different object or incomplete type. If the resulting # pointer is not correctly aligned57) for the pointed-to type, the # behavior is undefined. Otherwise, when converted back again, the # result shall compare equal to the original pointer. So if you convert two pointers to the same PyIntObject to PyObject*, and convert them back, then compare them, you are guaranteed to get true. If you compare them while they are PyObject*, no guarantees are given. > I don't buy that because C simply doesn't define the result of > > (PyObject *) &_Py_TrueStruct Again: agreed. > But that's not the point I was trying to make: the text of the warning > message Neil quoted warned about dereferencing, but there is no > dereferencing going on in the line it's complaining about. So the message is confusing: I agree. > I'm more worried about real problems : But gcc is pointing to a real problem. It is just that it cannot, in general, detect the real problem. As the real problem is wide-spread, it makes a best effort approach in guessing what programs might show undefined behaviour. As it turns out, in the case of Python, the compiler is right: There is undefined behaviour with respect to PyObject*. We could cheat the compiler to fail to recognize our bad cade, but it still would be bad code. > Has anyone tried running Python compiled without no-strict-aliasing? If so, > how bad was it? The current change was primarily triggered by the messages. No single bug was tracked down to gcc generating bad code in such cases. > The other question is whether no-strict-aliasing prevents such > optimizations. It does. gcc then assumes that any pointer may alias with any other. > If it does, then we should probably always use it. We do. Martin From andymac@bullseye.apana.org.au Sat Jul 19 00:57:04 2003 From: andymac@bullseye.apana.org.au (Andrew MacIntyre) Date: Sat, 19 Jul 2003 09:57:04 +1000 (EST) Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: Message-ID: <20030719092642.G86863@bullseye.apana.org.au> On Fri, 18 Jul 2003, Tim Peters wrote: > Has anyone tried running Python compiled without no-strict-aliasing? If so, > how bad was it? I've never used no-strict-aliasing with gcc on the EMX port. With gcc 2.8.1 and 2.95.2 -O3, I've not seen failures that appear to be bad code; with gcc 3.2.1 I see 3 tests (test_codeccallbacks, test_format & test_unicode) that seem to have repeatable failures that are sensitive to optimisation level (-O3 = fail, -O2 = pass) which may be bad code. I'll try -no-stict-aliasing when I get back digging into this. BTW, the following sequence of tests causes a core dump from an assertion failure in test_enumerate on EMX which I haven't been able to replicate on FreeBSD :-( test_importhooks test_re test_glob test_parser test_enumerate I haven't played with all possible permutations, but skipping any one of the precursor tests doesn't exhibit the assertion failure, which is: Assertion failed: gc->gc.gc_refs != 0, file ../../Modules/gcmodule.c, line 231 I also encountered a hang in test_poll on FreeBSD 5.1 (gcc 3.2.2), which I suspect is more likely to be a problem with FreeBSD 5.1's library code (thread codebase instability) than Python. I ran about a dozen full -r runs on FreeBSD 4.8 (gcc 2.95.4) with no sign of anything being amiss (which doesn't mean it isn't, just not readily tripped over). More digging clearly indicated on both EMX issues... -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From tim.one@comcast.net Sat Jul 19 03:18:45 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 18 Jul 2003 22:18:45 -0400 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: <20030719092642.G86863@bullseye.apana.org.au> Message-ID: [Andrew MacIntyre] > I've never used no-strict-aliasing with gcc on the EMX port. With gcc > 2.8.1 and 2.95.2 -O3, I've not seen failures that appear to be bad > code; with gcc 3.2.1 I see 3 tests (test_codeccallbacks, test_format & > test_unicode) that seem to have repeatable failures that are > sensitive to optimisation level (-O3 = fail, -O2 = pass) which may be > bad code. I'll try -no-stict-aliasing when I get back digging into > this. It could also be plain bad code . > BTW, the following sequence of tests causes a core dump from an > assertion failure in test_enumerate on EMX which I haven't been able > to replicate on FreeBSD :-( > > test_importhooks > test_re > test_glob > test_parser > test_enumerate Excellent! I just reproduced this in a debug build on Win98SE. These are sheer hell to track down, btw: > I haven't played with all possible permutations, but skipping any one > of the precursor tests doesn't exhibit the assertion failure, which > is: > > Assertion failed: gc->gc.gc_refs != 0, file ../../Modules/gcmodule.c, > line 231 I'm very familiar with that assertion, partly because I put it in , but mostly because we get these seemingly every week in Zope's C code. There are two possible causes, and they're never gc's fault (gc has determined that there are more pointers to an object than are accounted for by the object's refcount). There are two causes: 1. Somebody forgot to incref. or 2. I've seen this only once: a tp_traverse slot is calling its visit() callback multiple times with the same contained object. In the case I saw last week, code in Zope was trying to pass back each pointer in a linked list, one at a time, but due to a bug the linked list erroneously pointed back to its own interior, causing all the pointers in the list to get passed to visit() over and over again. These can be sheer hell to track down, since gc is detecting a mistake that may have occurred at any time since the Python run started (BTW, Zope suffers more than its share of this because some of its internals lie about the true refcounts, faking weak dicts in a way that predates weak references). In the case above, the assertion triggers while Python is shutting down, during the first call to PyGC_Collect() in Py_Finalize(). gc is traversing a dict, and a dict value is the thing with the too-small refcount; it's an object of _PyClass_Type ... so it's a classic class ... and its name is "ParserError". That's created in parsermodule.c. What appears to be the same assertion on the same object can be triggered earlier by passing -t1 to regrtest.py (this forces gc to run much more often). Then it asserts in the middle of running test_parser.py. But not in isolation! Still seems to need other tests to run before it. > I also encountered a hang in test_poll on FreeBSD 5.1 (gcc 3.2.2), > which I suspect is more likely to be a problem with FreeBSD 5.1's > library code (thread codebase instability) than Python. I ran about > a dozen full -r runs on FreeBSD 4.8 (gcc 2.95.4) with no sign of > anything being amiss (which doesn't mean it isn't, just not readily > tripped over). We had a report on a Zope list today that 2.3b1 on FreeBSD (don't know more about the version) couldn't import fcntl. Doesn't sound like you've bumped into that one. > More digging clearly indicated on both EMX issues... Indeed -- alas. From tim@multitalents.net Sat Jul 19 06:15:37 2003 From: tim@multitalents.net (Tim Rice) Date: Fri, 18 Jul 2003 22:15:37 -0700 (PDT) Subject: [Python-Dev] 2.3rc1 delayed In-Reply-To: <1058542812.22834.0.camel@slothrop.zope.com> References: <074c01c34d01$e2e943f0$f502a8c0@eden> <1058542812.22834.0.camel@slothrop.zope.com> Message-ID: On Fri, 18 Jul 2003, Jeremy Hylton wrote: > On Fri, 2003-07-18 at 11:27, Tim Rice wrote: > > It would be nice to have http://www.python.org/sf/772077 in too. > > What effect would it have on other platforms? > > Jeremy Testing here indicates it would be fine. (doesn't break) UnixWare: Has /usr/ccs/lib, needs -lcurses (the patch adds support for this) Solaris: Has /usr/ccs/lib, doesn't need -lcurses Linux: Doesn't have /usr/ccs/lib, doesn't need -lcurses -- Tim Rice Multitalents (707) 887-1469 tim@multitalents.net From martin@v.loewis.de Sat Jul 19 10:16:42 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 19 Jul 2003 11:16:42 +0200 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: <20030719092642.G86863@bullseye.apana.org.au> References: <20030719092642.G86863@bullseye.apana.org.au> Message-ID: Andrew MacIntyre writes: > I've never used no-strict-aliasing with gcc on the EMX port. With gcc > 2.8.1 and 2.95.2 -O3, I've not seen failures that appear to be bad code; Those compilers either did not support -fno-strict-aliasing at all, or had it turned on by default; it is only gcc 3 which has -fstrict-aliasing as the default for optimization levels >=2. Regards, Martin From ben@algroup.co.uk Sat Jul 19 11:38:15 2003 From: ben@algroup.co.uk (Ben Laurie) Date: Sat, 19 Jul 2003 11:38:15 +0100 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: Message-ID: <3F191F97.5060304@algroup.co.uk> Martin v. Löwis wrote: > "Tim Peters" writes: >>>Notice that a compiler is allowed to infer that the test is always >>>false. >> >>I don't buy that. I'll buy that the result of the comparison is undefined >>by C, and that a hostile implementation of C could arbitrarily decide to >>call all such expressions false -- or arbitrarily decide to call all such >>expressions true. > > > You are right: it is undefined, so an implementation that always gives > false might still be conforming. The closest statement to defining > behaviour is 6.3.2.3p7: > > # A pointer to an object or incomplete type may be converted to a > # pointer to a different object or incomplete type. If the resulting > # pointer is not correctly aligned57) for the pointed-to type, the > # behavior is undefined. Otherwise, when converted back again, the > # result shall compare equal to the original pointer. > > So if you convert two pointers to the same PyIntObject to PyObject*, > and convert them back, then compare them, you are guaranteed to get > true. If you compare them while they are PyObject*, no guarantees are > given. FWIW, K&R 2nd Ed. says in A6.6 that this is only true if the conversion is to a type whose alignment requirement is less or equally strict. It also says that chars have the least strict alignment requirement. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From martin@v.loewis.de Sat Jul 19 12:09:46 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 19 Jul 2003 13:09:46 +0200 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: <3F191F97.5060304@algroup.co.uk> References: <3F191F97.5060304@algroup.co.uk> Message-ID: Ben Laurie writes: > > So if you convert two pointers to the same PyIntObject to PyObject*, > > and convert them back, then compare them, you are guaranteed to get > > true. If you compare them while they are PyObject*, no guarantees are > > given. > > FWIW, K&R 2nd Ed. says in A6.6 that this is only true if the conversion > is to a type whose alignment requirement is less or equally strict. What is "this" in your message? "no guarantees are given", or "you are guaranteed to get true". If the latter: Sure, but 6.2.5p26 says # All pointers to structure types shall have the same representation # and alignment requirements as each other. So all pointers are equal. Regards, Martin From ben@algroup.co.uk Sat Jul 19 14:07:14 2003 From: ben@algroup.co.uk (Ben Laurie) Date: Sat, 19 Jul 2003 14:07:14 +0100 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: <3F191F97.5060304@algroup.co.uk> Message-ID: <3F194282.3070205@algroup.co.uk> Martin v. Löwis wrote: > Ben Laurie writes: > > >>>So if you convert two pointers to the same PyIntObject to PyObject*, >>>and convert them back, then compare them, you are guaranteed to get >>>true. If you compare them while they are PyObject*, no guarantees are >>>given. >> >>FWIW, K&R 2nd Ed. says in A6.6 that this is only true if the conversion >>is to a type whose alignment requirement is less or equally strict. > > > What is "this" in your message? "no guarantees are given", or "you are > guaranteed to get true". If the latter: Sure, but 6.2.5p26 says Sorry, "this" is the conversion to some other pointer type and back yielding the same value. > # All pointers to structure types shall have the same representation > # and alignment requirements as each other. > > So all pointers are equal. All pointers to structures, sure. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From gjc@inescporto.pt Sat Jul 19 14:08:28 2003 From: gjc@inescporto.pt (Gustavo J A M Carneiro) Date: 19 Jul 2003 14:08:28 +0100 Subject: [Python-Dev] LC_NUMERIC and C libraries Message-ID: <1058620108.3395.5.camel@emperor.localdomain> --=-UjU31ROv+4O9JKpq7ZBY Content-Type: text/plain Content-Transfer-Encoding: 7bit Here's the patch. Also 2 new source files: - pystrtod.h goes to Include/ - pystrtod.c goes to Python/ The next step is to ask glib authors for permission to relicense the code. Also, the locale module should be changed, to allow LC_NUMERIC to be changed, etc. Regards. -- Gustavo J. A. M. Carneiro --=-UjU31ROv+4O9JKpq7ZBY Content-Disposition: attachment; filename=numeric.diff Content-Type: text/x-patch; name=numeric.diff; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Only in Python-2.3b2-gjc/Include: pystrtod.h diff -rup Python-2.3b2/Include/Python.h Python-2.3b2-gjc/Include/Python.h --- Python-2.3b2/Include/Python.h 2002-08-12 08:21:56.000000000 +0100 +++ Python-2.3b2-gjc/Include/Python.h 2003-07-17 00:03:47.000000000 +0100 @@ -113,6 +113,8 @@ #include "abstract.h" +#include "pystrtod.h" + /* _Py_Mangle is defined in compile.c */ PyAPI_FUNC(int) _Py_Mangle(char *p, char *name, \ char *buffer, size_t maxlen); diff -rup Python-2.3b2/Makefile.pre.in Python-2.3b2-gjc/Makefile.pre.in --- Python-2.3b2/Makefile.pre.in 2003-06-21 14:26:28.000000000 +0100 +++ Python-2.3b2-gjc/Makefile.pre.in 2003-07-16 23:54:30.000000000 +0100 @@ -244,6 +244,7 @@ PYTHON_OBJS= \ Python/sysmodule.o \ Python/traceback.o \ Python/getopt.o \ + Python/pystrtod.o \ Python/$(DYNLOADFILE) \ $(MACHDEP_OBJS) \ $(THREADOBJ) diff -rup Python-2.3b2/Modules/cPickle.c Python-2.3b2-gjc/Modules/cPickle.c --- Python-2.3b2/Modules/cPickle.c 2003-06-16 21:19:49.000000000 +0100 +++ Python-2.3b2-gjc/Modules/cPickle.c 2003-07-19 12:08:17.000000000 +0100 @@ -3314,7 +3314,7 @@ load_float(Unpicklerobject *self) if (!( s=pystrndup(s,len))) return -1; errno = 0; - d = strtod(s, &endptr); + d = PyOS_strtod(s, &endptr); if (errno || (endptr[0] != '\n') || (endptr[1] != '\0')) { PyErr_SetString(PyExc_ValueError, diff -rup Python-2.3b2/Modules/stropmodule.c Python-2.3b2-gjc/Modules/stropmodule.c --- Python-2.3b2/Modules/stropmodule.c 2002-08-02 03:27:13.000000000 +0100 +++ Python-2.3b2-gjc/Modules/stropmodule.c 2003-07-19 12:08:17.000000000 +0100 @@ -838,7 +838,6 @@ PyDoc_STRVAR(atof__doc__, static PyObject * strop_atof(PyObject *self, PyObject *args) { - extern double strtod(const char *, char **); char *s, *end; double x; char buffer[256]; /* For errors */ @@ -854,7 +853,7 @@ strop_atof(PyObject *self, PyObject *arg } errno = 0; PyFPE_START_PROTECT("strop_atof", return 0) - x = strtod(s, &end); + x = PyOS_strtod(s, &end); PyFPE_END_PROTECT(x) while (*end && isspace(Py_CHARMASK(*end))) end++; diff -rup Python-2.3b2/Objects/complexobject.c Python-2.3b2-gjc/Objects/complexobject.c --- Python-2.3b2/Objects/complexobject.c 2003-06-17 21:22:24.000000000 +0100 +++ Python-2.3b2-gjc/Objects/complexobject.c 2003-07-19 12:56:59.000000000 +0100 @@ -272,13 +272,19 @@ complex_dealloc(PyObject *op) static void complex_to_buf(char *buf, int bufsz, PyComplexObject *v, int precision) { - if (v->cval.real == 0.) - PyOS_snprintf(buf, bufsz, "%.*gj", - precision, v->cval.imag); - else - PyOS_snprintf(buf, bufsz, "(%.*g%+.*gj)", - precision, v->cval.real, - precision, v->cval.imag); + char format[32]; + if (v->cval.real == 0.) { + PyOS_snprintf(format, 32, "%%.%ig", precision); + PyOS_formatd(buf, bufsz, format, v->cval.imag); + strncat(buf, "j", bufsz); + } else { + char re[64], im[64]; + + PyOS_snprintf(format, 32, "%%.%ig", precision); + PyOS_formatd(re, 64, format, v->cval.real); + PyOS_formatd(im, 64, format, v->cval.imag); + PyOS_snprintf(buf, bufsz, "(%s+%sj)", re, im); + } } static int @@ -662,7 +668,6 @@ static PyMemberDef complex_members[] = { static PyObject * complex_subtype_from_string(PyTypeObject *type, PyObject *v) { - extern double strtod(const char *, char **); const char *s, *start; char *end; double x=0.0, y=0.0, z; @@ -774,7 +779,7 @@ complex_subtype_from_string(PyTypeObject } errno = 0; PyFPE_START_PROTECT("strtod", return 0) - z = strtod(s, &end) ; + z = PyOS_strtod(s, &end) ; PyFPE_END_PROTECT(z) if (errno != 0) { PyOS_snprintf(buffer, sizeof(buffer), diff -rup Python-2.3b2/Objects/floatobject.c Python-2.3b2-gjc/Objects/floatobject.c --- Python-2.3b2/Objects/floatobject.c 2003-06-28 21:04:24.000000000 +0100 +++ Python-2.3b2-gjc/Objects/floatobject.c 2003-07-19 12:54:30.000000000 +0100 @@ -142,7 +142,7 @@ PyFloat_FromString(PyObject *v, char **p * key off errno. */ PyFPE_START_PROTECT("strtod", return NULL) - x = strtod(s, (char **)&end); + x = PyOS_strtod(s, (char **)&end); PyFPE_END_PROTECT(x) errno = 0; /* Believe it or not, Solaris 2.6 can move end *beyond* the null @@ -174,7 +174,7 @@ PyFloat_FromString(PyObject *v, char **p /* See above -- may have been strtod being anal about denorms. */ PyFPE_START_PROTECT("atof", return NULL) - x = atof(s); + x = PyOS_atof(s); PyFPE_END_PROTECT(x) errno = 0; /* whether atof ever set errno is undefined */ } @@ -233,6 +233,7 @@ static void format_float(char *buf, size_t buflen, PyFloatObject *v, int precision) { register char *cp; + char format[32]; /* Subroutine for float_repr and float_print. We want float numbers to be recognizable as such, i.e., they should contain a decimal point or an exponent. @@ -240,7 +241,8 @@ format_float(char *buf, size_t buflen, P in such cases, we append ".0" to the string. */ assert(PyFloat_Check(v)); - PyOS_snprintf(buf, buflen, "%.*g", precision, v->ob_fval); + PyOS_snprintf(format, 32, "%%.%ig", precision); + PyOS_formatd(buf, buflen, format, v->ob_fval); cp = buf; if (*cp == '-') cp++; diff -rup Python-2.3b2/Python/compile.c Python-2.3b2-gjc/Python/compile.c --- Python-2.3b2/Python/compile.c 2003-06-20 17:13:17.000000000 +0100 +++ Python-2.3b2-gjc/Python/compile.c 2003-07-19 12:06:56.000000000 +0100 @@ -1286,7 +1286,7 @@ parsenumber(struct compiling *c, char *s Py_complex z; z.real = 0.; PyFPE_START_PROTECT("atof", return 0) - z.imag = atof(s); + z.imag = PyOS_atof(s); PyFPE_END_PROTECT(z) return PyComplex_FromCComplex(z); } @@ -1294,7 +1294,7 @@ parsenumber(struct compiling *c, char *s #endif { PyFPE_START_PROTECT("atof", return 0) - dx = atof(s); + dx = PyOS_atof(s); PyFPE_END_PROTECT(dx) return PyFloat_FromDouble(dx); } diff -rup Python-2.3b2/Python/marshal.c Python-2.3b2-gjc/Python/marshal.c --- Python-2.3b2/Python/marshal.c 2002-07-30 12:44:44.000000000 +0100 +++ Python-2.3b2-gjc/Python/marshal.c 2003-07-19 12:11:08.000000000 +0100 @@ -447,7 +447,7 @@ r_object(RFILE *p) } buf[n] = '\0'; PyFPE_START_PROTECT("atof", return 0) - dx = atof(buf); + dx = PyOS_atof(buf); PyFPE_END_PROTECT(dx) return PyFloat_FromDouble(dx); } @@ -465,7 +465,7 @@ r_object(RFILE *p) } buf[n] = '\0'; PyFPE_START_PROTECT("atof", return 0) - c.real = atof(buf); + c.real = PyOS_atof(buf); PyFPE_END_PROTECT(c) n = r_byte(p); if (r_string(buf, (int)n, p) != n) { @@ -475,7 +475,7 @@ r_object(RFILE *p) } buf[n] = '\0'; PyFPE_START_PROTECT("atof", return 0) - c.imag = atof(buf); + c.imag = PyOS_atof(buf); PyFPE_END_PROTECT(c) return PyComplex_FromCComplex(c); } Only in Python-2.3b2-gjc/Python: pystrtod.c --=-UjU31ROv+4O9JKpq7ZBY Content-Disposition: attachment; filename=pystrtod.c Content-Type: text/x-c; name=pystrtod.c; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit /* -*- Mode: C; c-file-style: "python" -*- */ #include "Python.h" #include #include #include #include #include #include //#define __PYSTRTOD_DEBUG /* Note: glib functions are based on gstrfuncs.c, version 1.94.2.3 */ /* ------------------------------------------ */ /* */ /* glib uses gnu-style indenting/spacing */ /* for compatibility */ #ifdef NDEBUG # define g_return_val_if_fail(condition, value) # define g_return_if_fail(condition) #else # define g_return_val_if_fail(condition, value) \ if (!(condition)) { \ /*give warning here*/; \ return (value); \ } # define g_return_if_fail(condition, value) \ if (!(condition)) { \ /*give warning here*/; \ return; \ } #endif #define g_assert(foo) assert(foo) #define g_malloc(foo) malloc(foo) #define g_free(foo) free(foo) #define _g_snprintf PyOS_snprintf /* ... */ typedef char gchar; typedef short gshort; typedef long glong; typedef int gint; typedef gint gboolean; typedef unsigned char guchar; typedef unsigned short gushort; typedef unsigned long gulong; typedef unsigned int guint; typedef float gfloat; typedef double gdouble; typedef signed char gint8; typedef unsigned char guint8; typedef signed short gint16; typedef unsigned short guint16; typedef signed int gint32; typedef unsigned int guint32; static const guint16 ascii_table_data[256] = { 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x104, 0x104, 0x004, 0x104, 0x104, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x004, 0x140, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x459, 0x459, 0x459, 0x459, 0x459, 0x459, 0x459, 0x459, 0x459, 0x459, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x653, 0x653, 0x653, 0x653, 0x653, 0x653, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x253, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x473, 0x473, 0x473, 0x473, 0x473, 0x473, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x073, 0x0d0, 0x0d0, 0x0d0, 0x0d0, 0x004 /* the upper 128 are all zeroes */ }; const guint16 * const g_ascii_table = ascii_table_data; /* Functions like the ones in that are not affected by locale. */ typedef enum { G_ASCII_ALNUM = 1 << 0, G_ASCII_ALPHA = 1 << 1, G_ASCII_CNTRL = 1 << 2, G_ASCII_DIGIT = 1 << 3, G_ASCII_GRAPH = 1 << 4, G_ASCII_LOWER = 1 << 5, G_ASCII_PRINT = 1 << 6, G_ASCII_PUNCT = 1 << 7, G_ASCII_SPACE = 1 << 8, G_ASCII_UPPER = 1 << 9, G_ASCII_XDIGIT = 1 << 10 } GAsciiType; #define g_ascii_isalnum(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_ALNUM) != 0) #define g_ascii_isalpha(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_ALPHA) != 0) #define g_ascii_iscntrl(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_CNTRL) != 0) #define g_ascii_isdigit(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_DIGIT) != 0) #define g_ascii_isgraph(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_GRAPH) != 0) #define g_ascii_islower(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_LOWER) != 0) #define g_ascii_isprint(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_PRINT) != 0) #define g_ascii_ispunct(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_PUNCT) != 0) #define g_ascii_isspace(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_SPACE) != 0) #define g_ascii_isupper(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_UPPER) != 0) #define g_ascii_isxdigit(c) \ ((g_ascii_table[(guchar) (c)] & G_ASCII_XDIGIT) != 0) /** * g_ascii_strtod: * @nptr: the string to convert to a numeric value. * @endptr: if non-%NULL, it returns the character after * the last character used in the conversion. * * Converts a string to a #gdouble value. * This function behaves like the standard strtod() function * does in the C locale. It does this without actually * changing the current locale, since that would not be * thread-safe. * * This function is typically used when reading configuration * files or other non-user input that should be locale independent. * To handle input from the user you should normally use the * locale-sensitive system strtod() function. * * To convert from a #gdouble to a string in a locale-insensitive * way, use g_ascii_dtostr(). * * If the correct value would cause overflow, plus or minus %HUGE_VAL * is returned (according to the sign of the value), and %ERANGE is * stored in %errno. If the correct value would cause underflow, * zero is returned and %ERANGE is stored in %errno. * * This function resets %errno before calling strtod() so that * you can reliably detect overflow and underflow. * * Return value: the #gdouble value. **/ static gdouble g_ascii_strtod (const gchar *nptr, gchar **endptr) { gchar *fail_pos; gdouble val; struct lconv *locale_data; const char *decimal_point; int decimal_point_len; const char *p, *decimal_point_pos; const char *end = NULL; /* Silence gcc */ g_return_val_if_fail (nptr != NULL, 0); fail_pos = NULL; locale_data = localeconv (); decimal_point = locale_data->decimal_point; decimal_point_len = strlen (decimal_point); g_assert (decimal_point_len != 0); decimal_point_pos = NULL; if (decimal_point[0] != '.' || decimal_point[1] != 0) { p = nptr; /* Skip leading space */ while (g_ascii_isspace (*p)) p++; /* Skip leading optional sign */ if (*p == '+' || *p == '-') p++; if (p[0] == '0' && (p[1] == 'x' || p[1] == 'X')) { p += 2; /* HEX - find the (optional) decimal point */ while (g_ascii_isxdigit (*p)) p++; if (*p == '.') { decimal_point_pos = p++; while (g_ascii_isxdigit (*p)) p++; if (*p == 'p' || *p == 'P') p++; if (*p == '+' || *p == '-') p++; while (g_ascii_isdigit (*p)) p++; end = p; } } else { while (g_ascii_isdigit (*p)) p++; if (*p == '.') { decimal_point_pos = p++; while (g_ascii_isdigit (*p)) p++; if (*p == 'e' || *p == 'E') p++; if (*p == '+' || *p == '-') p++; while (g_ascii_isdigit (*p)) p++; end = p; } } /* For the other cases, we need not convert the decimal point */ } /* Set errno to zero, so that we can distinguish zero results and underflows */ errno = 0; if (decimal_point_pos) { char *copy, *c; /* We need to convert the '.' to the locale specific decimal point */ copy = g_malloc (end - nptr + 1 + decimal_point_len); c = copy; memcpy (c, nptr, decimal_point_pos - nptr); c += decimal_point_pos - nptr; memcpy (c, decimal_point, decimal_point_len); c += decimal_point_len; memcpy (c, decimal_point_pos + 1, end - (decimal_point_pos + 1)); c += end - (decimal_point_pos + 1); *c = 0; val = strtod (copy, &fail_pos); if (fail_pos) { if (fail_pos > decimal_point_pos) fail_pos = (char *)nptr + (fail_pos - copy) - (decimal_point_len - 1); else fail_pos = (char *)nptr + (fail_pos - copy); } g_free (copy); } else val = strtod (nptr, &fail_pos); if (endptr) *endptr = fail_pos; return val; } /** * g_ascii_formatd: * @buffer: A buffer to place the resulting string in * @buf_len: The length of the buffer. * @format: The printf()-style format to use for the * code to use for converting. * @d: The #gdouble to convert * * Converts a #gdouble to a string, using the '.' as * decimal point. To format the number you pass in * a printf()-style format string. Allowed conversion * specifiers are 'e', 'E', 'f', 'F', 'g' and 'G'. * * If you just want to want to serialize the value into a * string, use g_ascii_dtostr(). * * Return value: The pointer to the buffer with the converted string. **/ static gchar * g_ascii_formatd (gchar *buffer, gint buf_len, const gchar *format, gdouble d) { struct lconv *locale_data; const char *decimal_point; int decimal_point_len; gchar *p; int rest_len; gchar format_char; g_return_val_if_fail (buffer != NULL, NULL); g_return_val_if_fail (format[0] == '%', NULL); g_return_val_if_fail (strpbrk (format + 1, "'l%") == NULL, NULL); format_char = format[strlen (format) - 1]; g_return_val_if_fail (format_char == 'e' || format_char == 'E' || format_char == 'f' || format_char == 'F' || format_char == 'g' || format_char == 'G', NULL); if (format[0] != '%') return NULL; if (strpbrk (format + 1, "'l%")) return NULL; if (!(format_char == 'e' || format_char == 'E' || format_char == 'f' || format_char == 'F' || format_char == 'g' || format_char == 'G')) return NULL; _g_snprintf (buffer, buf_len, format, d); locale_data = localeconv (); decimal_point = locale_data->decimal_point; decimal_point_len = strlen (decimal_point); g_assert (decimal_point_len != 0); if (decimal_point[0] != '.' || decimal_point[1] != 0) { p = buffer; if (*p == '+' || *p == '-') p++; while (isdigit ((guchar)*p)) p++; if (strncmp (p, decimal_point, decimal_point_len) == 0) { *p = '.'; p++; if (decimal_point_len > 1) { rest_len = strlen (p + (decimal_point_len-1)); memmove (p, p + (decimal_point_len-1), rest_len); p[rest_len] = 0; } } } return buffer; } /* */ /* ------------------------------------------ */ #ifdef __PYSTRTOD_DEBUG # include #endif double PyOS_strtod(const char *str, char **ptr) { #ifdef __PYSTRTOD_DEBUG fprintf(stderr, ">>>!!! calling g_ascii_strtod('%s')\n", str); #endif return g_ascii_strtod(str, ptr); } double PyOS_atof(const char *str) { #ifdef __PYSTRTOD_DEBUG fprintf(stderr, ">>>!!! calling g_ascii_strtod('%s')\n", str); #endif return g_ascii_strtod(str, NULL); } void PyOS_formatd(char *buffer, int buf_len, const char *format, double d) { #ifdef __PYSTRTOD_DEBUG fprintf(stderr, ">>>!!! calling g_ascii_formatd('%s', %f)\n", format, d); #endif g_ascii_formatd(buffer, buf_len, format, d); #ifdef __PYSTRTOD_DEBUG fprintf(stderr, ">>>!!! g_ascii_formatd: \"%s\"\n", buffer); #endif } --=-UjU31ROv+4O9JKpq7ZBY Content-Disposition: attachment; filename=pystrtod.h Content-Type: text/x-c-header; name=pystrtod.h; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit #ifndef Py_STRTOD_H #define Py_STRTOD_H #ifdef __cplusplus extern "C" { #endif double PyOS_strtod(const char *str, char **ptr); double PyOS_atof(const char *str); void PyOS_formatd(char *buffer, int buf_len, const char *format, double d); #ifdef __cplusplus } #endif #endif /* !Py_STRTOD_H */ --=-UjU31ROv+4O9JKpq7ZBY-- From andymac@bullseye.apana.org.au Sat Jul 19 11:25:56 2003 From: andymac@bullseye.apana.org.au (Andrew MacIntyre) Date: Sat, 19 Jul 2003 20:25:56 +1000 (EST) Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: Message-ID: <20030719200929.G87727@bullseye.apana.org.au> On Fri, 18 Jul 2003, Tim Peters wrote: > [Andrew MacIntyre] > > code; with gcc 3.2.1 I see 3 tests (test_codeccallbacks, test_format & > > test_unicode) that seem to have repeatable failures that are > > sensitive to optimisation level (-O3 = fail, -O2 = pass) which may be > > bad code. I'll try -no-stict-aliasing when I get back digging into > > this. > > It could also be plain bad code . Not impossible... ;-) I'm mindful that gcc 3.x seems to create larger stackframes than earlier versions, which has been a source of annoyance (on FreeBSD more than with EMX). > > BTW, the following sequence of tests causes a core dump from an > > assertion failure in test_enumerate on EMX which I haven't been able > > to replicate on FreeBSD :-( > > > > test_importhooks > > test_re > > test_glob > > test_parser > > test_enumerate > > Excellent! I just reproduced this in a debug build on Win98SE. I'm glad that I'm not alone in the wilderness on this one. {...} > We had a report on a Zope list today that 2.3b1 on FreeBSD (don't know more > about the version) couldn't import fcntl. Doesn't sound like you've bumped > into that one. I did hit it, after I got a FreeBSD 5.1 box running to test on. The issue is specific to FreeBSD 5.x. Patch 763798 was the fix, but wasn't checked in until after 2.3b2. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From martin@v.loewis.de Sat Jul 19 15:31:25 2003 From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 19 Jul 2003 16:31:25 +0200 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <1058620108.3395.5.camel@emperor.localdomain> References: <1058620108.3395.5.camel@emperor.localdomain> Message-ID: <3F19563D.5000909@v.loewis.de> Gustavo J A M Carneiro wrote: > Here's the patch. Also 2 new source files: > - pystrtod.h goes to Include/ > - pystrtod.c goes to Python/ > > The next step is to ask glib authors for permission to relicense the > code. Also, the locale module should be changed, to allow LC_NUMERIC to > be changed, etc. Please don't post patches to python-dev; post them to sf.net/projects/python instead. However, a) it is unlikely that patches are accepted from anybody but the author of the code, and b) it is unlikely that patches are implemented that provide huge chunks of the C library. Regards, Martin From kiko@async.com.br Sat Jul 19 16:45:04 2003 From: kiko@async.com.br (Christian Reis) Date: Sat, 19 Jul 2003 12:45:04 -0300 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <3F19563D.5000909@v.loewis.de> References: <1058620108.3395.5.camel@emperor.localdomain> <3F19563D.5000909@v.loewis.de> Message-ID: <20030719154504.GU1158@async.com.br> On Sat, Jul 19, 2003 at 04:31:25PM +0200, "Martin v. L=F6wis" wrote: > Gustavo J A M Carneiro wrote: > > Here's the patch. Also 2 new source files: >=20 > Please don't post patches to python-dev; post them to=20 > sf.net/projects/python instead. >=20 > However, > a) it is unlikely that patches are accepted from anybody but > the author of the code, and > b) it is unlikely that patches are implemented that provide huge > chunks of the C library. I'm afraid I didn't quite understand these two points: a) Do you mean to say that the patch should be sent *to* the original author of the locale code? The original author of the code that *calls* atof/strtod? Or *by* the original author of the g_ascii_* functions?=20 If the latter I can try and get Alex Larsson to submit the code. Is written permission from the glib team, relicensing the code, not acceptable enough, though? b) I'm unsure as to how we should proceed without offering alternative versions of strtod/formatd (which is what the pystrtod.c file includes); AFAICS, the current situation is *caused* by the libc versions not being LC_NUMERIC-safe. Do you see an alternative? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From tim.one@comcast.net Sat Jul 19 22:02:29 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 19 Jul 2003 17:02:29 -0400 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: Message-ID: [Andrew MacIntyre] >> BTW, the following sequence of tests causes a core dump from an >> assertion failure in test_enumerate on EMX which I haven't been able >> to replicate on FreeBSD :-( >> >> test_importhooks >> test_re >> test_glob >> test_parser >> test_enumerate This one's a bitch. For me on Win98SE, it may or may not be related to that the parser module is in a separate DLL. Here's the start of initparser(): PyMODINIT_FUNC initparser(void) { PyObject *module, *copyreg; PyST_Type.ob_type = &PyType_Type; module = Py_InitModule("parser", parser_functions); if (parser_error == 0) parser_error = PyErr_NewException("parser.ParserError", NULL, NULL); if ((parser_error == 0) || (PyModule_AddObject(module, "ParserError", parser_error) != 0)) { /* caller will check PyErr_Occurred() */ return; } It's skating on the edge a little in "the usual" case: the file static parser_error starts life at NULL, so PyErr_NewException gets called, and PyModule_AddObject *transfers* ownership of the (sole) reference, from the parser_error static to the module dict. This is a little dicey because functions all over parsermodule.c use parser_error, but the module proper doesn't own a reference to parser_error. But that's probably fine so far as it goes, because gc isn't aware of the parser_error file static (so the file static doesn't look like an "extra reference" to it, so far as gc is concerned), and it's hard to imagine how functions in this module could get invoked if the true owner (the module dict) went away. Things go to hell in the sequence of tests that Andrew found, though, because initparser() is called *twice*. It's called once while running test_importhooks, and a second time while running test_parser. The second time it's called, parser_error still has the value it got from PyErr_NewException in the first call. So PyErr_NewException isn't called again, but PyModule_AddObject is, and ownership of the (shared) parser_error object is effectively transferred from the old module dict to the new module dict -- but both dicts still contain it! That's the cause of the gc assertion: more containers point to parser_error than can be accounted for by parser_error->ob_refcnt (which, on the second call to initparser(), starts at and remains 1). The simplest fix is to incref parser_error before calling PyModule_AddObject. Then each module dict created will own its reference, and the file static parser_error will own a reference too. This will make parser_error immortal (as is the case for any module with a file static that owns a reference to an object, and doesn't have a module cleanup function that gets called at the right times). 1. Is that a correct fix? 2. If so, is this important enough to justify another release candidate? I think this release has gotten messy enough that we're going to need a branch. I'll create one. From tim.one@comcast.net Sat Jul 19 22:32:52 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 19 Jul 2003 17:32:52 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: Message-ID: [Tim] > I think this release has gotten messy enough that we're going to need > a branch. I'll create one. I created branch r23c1-branch from the current head. There were changes checked into these files since the r23c1 tag was added: P Doc/whatsnew/whatsnew23.tex P Lib/modulefinder.py P Misc/NEWS P PCbuild/BUILDno.txt P PCbuild/python20.wse I believe we want all these changes in the next 2.3 release stab. I know for a fact that we want the changes in the last 3 files listed. Whoever changed whatsnew23.tex and modulefinder.py should think about them. Changes we want to go into the next 2.3 release stab (probably 2.3c2, alas) should be checked in to the r23c1-branch branch. They'll eventually need to get backported to the head. Ongoing random improvements can be checked into the head alone (they won't affect the next release candidate). > ... > The simplest fix is to incref parser_error before calling > PyModule_AddObject. > > 1. Is that a correct fix? Yes . > 2. If so, is this important enough to justify another release > candidate? I think it is, and I'll check the fix in on the new branch. From Jack.Jansen@cwi.nl Sun Jul 20 00:51:34 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sun, 20 Jul 2003 01:51:34 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: Message-ID: Hi folks, I'm back! On zaterdag, jul 19, 2003, at 23:32 Europe/Amsterdam, Tim Peters wrote: > Changes we want to go into the next 2.3 release stab (probably 2.3c2, > alas) > should be checked in to the r23c1-branch branch. They'll eventually > need to > get backported to the head. Will this make them go into 2.3 final automatically? Because (here comes the bad news:-) I have about 12 bugs on my list that need to be looked into, and that may need to be fixed before 2.3 final. In other words: I'm in a hurry. Luckily most of the bugs are very localized, but some are not: - 5 are PackMan bugs - 2 are bugs in the binary installer - 1 is the test_macostools bugs (which, if it still exists, I can lower in priority) The remaining three, however, are in the build process: 768306, 768068 and 766210. The first two I haven't looked at yet, so I'm not sure how serious they are. I could use help from other people with OSX boxes on these, also just to help decide on fix/don't fix. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From tim.one@comcast.net Sun Jul 20 03:20:04 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 19 Jul 2003 22:20:04 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: Message-ID: [Jack Jansen] > Hi folks, I'm back! While we never left . Welcome back! >> Changes we want to go into the next 2.3 release stab (probably >> 2.3c2, alas) should be checked in to the r23c1-branch branch. >> They'll eventually need to get backported to the head. > Will this make them go into 2.3 final automatically? Checking something in to the r23c1-branch branch is necessary to get it into 2.3 final, but not necessarily sufficient. For example, if a checkin breaks something, it will get backed out. Only critical fixes should be checked in to the new branch, of course -- we're trying to finish 2.3 ASAP. There's more pressure than usual to keep this simple, because Jeremy and Guido are in the midst of moving, and nobody at (what used to be) PLabs can spend work time on this anymore (indeed, I appointed myself interim release manager today because nobody else is reachable!). > Because (here comes the bad news:-) I have about 12 bugs on my > list that need to be looked into, and that may need to be > fixed before 2.3 final. Then we'll need another release candidate for sure (2.3c2). That's OK. > In other words: I'm in a hurry. Nevertheless, don't check in anything on the branch unless it fixes a truly serious problem (crash, major unusability -- serious stuff). > Luckily most of the bugs are very localized, but some are not: > - 5 are PackMan bugs I suppose that means there are Centipede, MissleCommand, and Robotron bugs just waiting to spring . > - 2 are bugs in the binary installer > - 1 is the test_macostools bugs (which, if it still exists, I can > lower in priority) > > The remaining three, however, are in the build process: 768306, 768068 > and 766210. The first two I haven't looked at yet, so I'm not sure how > serious they are. I could use help from other people with OSX boxes on > these, also just to help decide on fix/don't fix. Barry should back from vacation this coming week, and I bet he'll help try things on OS X in his copious spare time. If a question arises without an obvious answer, post it here and I'll make one up (favoring "let it alone for 2.3 final" unless there's an obvious fix to an obvious problem). From skip@pobox.com Sun Jul 20 03:29:14 2003 From: skip@pobox.com (Skip Montanaro) Date: Sat, 19 Jul 2003 21:29:14 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: Message-ID: <16153.65146.706193.595502@montanaro.dyndns.org> Jack> The remaining three, however, are in the build process: 768306, Jack> 768068 and 766210. (Mac OS X 10.2.6.) 1. 768306 works for me. 2. 768068 I submitted and only relates to the case where you build an extension module using a not-yet-installed version of the interpreter. I'm sure it can wait until after the 2.3 release. 3. 766210 I can't help you in a concrete way with this one since I don't have a case-sensitive file system available to test on. It looks like you can change the BUILDPYTHON line in Mac/OSX/Makefile to BUILDPYTHON=$(builddir)/python$(BUILDEXE) if BUILDEXE is set upon entry. Since this is determined by configure though I think you may need to create a Makefile.pre.in which contains ... BUILDEXE= @BUILDEXEEXT@ BUILDPYTHON=$(builddir)/python$(BUILDEXE) ... and tweak the configure process to also create Mac/OSX/Makefile in the build directory. Skip From halley@play-bow.org Sun Jul 20 08:25:51 2003 From: halley@play-bow.org (Bob Halley) Date: 20 Jul 2003 00:25:51 -0700 Subject: [Python-Dev] Recent experiences with socket.inet_aton, socket.inet_{ntop,pton} Message-ID: Firstly, I noticed during the QA work for my most recent release of dnspython that Python 2.3c1 on Windows XP still raises socket.error if you call socket.inet_aton('255.255.255.255'). I added work-around code to my library to avoid triggering it. Patch 756021 addresses this (excuse the pun :)). Do people think this patch is too risky for 2.3 or are there plans to apply it? The other thing I've had to work around is the highly conditionalized support for IPv6 in the socket module. inet_ntop and inet_pton are only provided if the underlying platform supports them, and IPv6 address support is only provided if the platform can actually create an IPv6 socket. My DNS code is IPv6 aware, and must deal with IPv6 addresses, even on platforms which do not implement IPv6 sockets. For example, someone might want to work with a zone containing AAAA records. It would have been nice if the socket module always supported these routines, even if the platform did not. I ended up writing my own inet_ntop/pton in Python. I'm not sure how many other people will have similar needs, but I think it's worth at least asking the question: "Should we always provide these routines, including their IPv6 support?" BIND has long faced the same issues with missing inet_ routines, and has its own C implementations of inet_aton, inet_ntop, and inet_pton. These are under a Historical-style open source license. We could easily integrate them into Python if people thought it to be generally useful. Far too risky for 2.3, but perhaps something for 2.3.1? What do people think? /Bob From martin@v.loewis.de Sun Jul 20 10:50:31 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 20 Jul 2003 11:50:31 +0200 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <20030719154504.GU1158@async.com.br> References: <1058620108.3395.5.camel@emperor.localdomain> <3F19563D.5000909@v.loewis.de> <20030719154504.GU1158@async.com.br> Message-ID: Christian Reis writes: > > a) it is unlikely that patches are accepted from anybody but > > the author of the code, and > > b) it is unlikely that patches are implemented that provide huge > > chunks of the C library. > > I'm afraid I didn't quite understand these two points: > > a) Do you mean to say that the patch should be sent *to* the original > author of the locale code? The original author of the code that *calls* > atof/strtod? No. I said that the original author should send us the patches; we will only accept them from that author. > If the latter I can try and get Alex Larsson to submit the code. Is > written permission from the glib team, relicensing the code, not > acceptable enough, though? We would have to discuss this in the PSF. In general, we want the PSF to be owner of all contributed code, see http://www.python.org/psf/psf-contributor-agreement.html We had bad experience with contributions by non-authors in the past, and had to back out changes that we later found we had no right to distribute. > b) I'm unsure as to how we should proceed without offering alternative > versions of strtod/formatd (which is what the pystrtod.c file includes); > AFAICS, the current situation is *caused* by the libc versions not being > LC_NUMERIC-safe. Do you see an alternative? It might well be unimplementable. However, if you can find platform-specific routines that you can wrap with a small wrapper, falling back to strtod if such routines are not available, that might be a way out. For example, on glibc, you could use __strtod_l. Regards, Martin From martin@v.loewis.de Sun Jul 20 11:02:17 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 20 Jul 2003 12:02:17 +0200 Subject: [Python-Dev] Recent experiences with socket.inet_aton, socket.inet_{ntop,pton} In-Reply-To: References: Message-ID: Bob Halley writes: > Do people think this patch is too risky for > 2.3 or are there plans to apply it? Yes, it is too risky. There is no serious problem I can see that is fixed by bug. inet_aton is a trivial function, and you can easily do def inet_aton(s): if s == '255.255.255.255': return '\xff\xff\xff\xff' return socket.inet_aton(s) > My DNS code is IPv6 aware, and must deal with IPv6 addresses, even on > platforms which do not implement IPv6 sockets. For example, someone > might want to work with a zone containing AAAA records. It would have > been nice if the socket module always supported these routines, even > if the platform did not. I ended up writing my own inet_ntop/pton in > Python. And that's what you should do, since inet_pton/ntop don't expose any system functionality - they are merely there for convenience. > I'm not sure how many other people will have similar needs, but I > think it's worth at least asking the question: "Should we always > provide these routines, including their IPv6 support?" I can't see how this could work, given that the underlying inet_pton implementation might refuse to support IPv6. > BIND has long faced the same issues with missing inet_ routines, and > has its own C implementations of inet_aton, inet_ntop, and inet_pton. > These are under a Historical-style open source license. We could > easily integrate them into Python if people thought it to be generally > useful. Far too risky for 2.3, but perhaps something for 2.3.1? What > do people think? I don't want to include more C code for stuff that is a) trivial, b) provided as a library function on many systems, and c) can be implemented in pure Python Regards, Martin From halley@play-bow.org Sun Jul 20 11:57:32 2003 From: halley@play-bow.org (Bob Halley) Date: 20 Jul 2003 03:57:32 -0700 Subject: [Python-Dev] Recent experiences with socket.inet_aton, socket.inet_{ntop,pton} In-Reply-To: References: Message-ID: martin@v.loewis.de (Martin v. L=C3=B6wis) writes: > > I'm not sure how many other people will have similar needs, but I > > think it's worth at least asking the question: "Should we always > > provide these routines, including their IPv6 support?" >=20 > I can't see how this could work, given that the underlying inet_pton > implementation might refuse to support IPv6. It would only work if Python implemented the routines itself (in Python or in C). > I don't want to include more C code for stuff that is > a) trivial, > b) provided as a library function on many systems, and > c) can be implemented in pure Python inet_ntop and pton are not trivial for IPv6 addresses due to the variety of textual representations required to be accepted as valid input, e.g.: 1080::8:800:200C:417A ffff:0000:0000:ffff:0000:0000:0000:ffff ffff:0:0:ffff::ffff ::1 :: 0:0:0:0:0:0:13.1.68.3 A good implementation must also detect and reject all of the invalid cases, such as improper use of the "::" zero compression syntax. Finally, there is the desire to generate appropriately "minimized" output when converting back to text (the two "ffff" examples above are the same address; the second is the appropriately minimized form). I'm not saying it's rocket science; I'm just saying it's sufficiently nontrivial that you don't want everyone who needs the functions to have to write them themselves. It may be that the right answer is that not enough people care about working with IPv6 addresses on non-IPv6 platforms to make doing anything worthwhile. I don't know who (other than me) might care about the issue, which is why I asked :). /Bob From lists.pythondev@imperialviolet.org Sun Jul 20 12:11:41 2003 From: lists.pythondev@imperialviolet.org (Adam Langley) Date: Sun, 20 Jul 2003 12:11:41 +0100 Subject: [Python-Dev] Cross Compiling Message-ID: <20030720121141.B30653@linuxpower.org> The configure script (for 2.2.3 at least) has defaults for its tests of sizeof(int) and the like which are completely broken for cross compiling. (They are generally values for a 32-bit system). It's quite understandable why this configure code cannot be used with a cross gcc: FILE *f=fopen("conftestval", "w"); if (!f) exit(1); fprintf(f, "%d\n", sizeof(int)); exit(0); So can I suggest a better(?) way of doing this (for systems with a GNU toolchain at least): sizeof.c: #include #include #include #include const __u8 sizeof_int[sizeof(int)]; const __u8 sizeof_long[sizeof(long)]; const __u8 sizeof_voidp[sizeof(void *)]; const __u8 sizeof_char[sizeof(char )]; const __u8 sizeof_short[sizeof(short)]; const __u8 sizeof_float[sizeof(float)]; const __u8 sizeof_double[sizeof(double)]; const __u8 sizeof_long_long[sizeof(long long)]; const __u8 sizeof_off_t[sizeof(off_t)]; const __u8 sizeof_time_t[sizeof(time_t)]; const __u8 sizeof_pthread_t[sizeof(pthread_t)]; % gcc -g -c sizeof.c % objdump -t sizeof.o | grep 'sizeof_[^ ]+$' | awk '{ print $5 " " $1; }' sizeof_int 0000000000000004 sizeof_long 0000000000000008 sizeof_voidp 0000000000000008 sizeof_char 0000000000000001 sizeof_short 0000000000000002 sizeof_float 0000000000000004 sizeof_double 0000000000000008 sizeof_long_long 0000000000000008 sizeof_off_t 0000000000000008 sizeof_time_t 0000000000000008 sizeof_pthread_t 0000000000000008 I'm afraid that I lack the required autoconf-fu to supply a helpfuly patch to configure.in. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 From skip@mojam.com Sun Jul 20 13:00:23 2003 From: skip@mojam.com (Skip Montanaro) Date: Sun, 20 Jul 2003 07:00:23 -0500 Subject: [Python-Dev] Weekly Python Bug/Patch Summary Message-ID: <200307201200.h6KC0Nh09133@manatee.mojam.com> Bug/Patch Summary ----------------- 377 open / 3868 total bugs (+4) 165 open / 2283 total patches (+2) New Bugs -------- incorrect os.path.supports_unicode_filenames (2003-07-08) http://python.org/sf/767645 memory leak in pickle/cPickle [2.2.3] (2003-07-14) http://python.org/sf/770997 pydoc.TextDoc raises for some kinds of objects (2003-07-14) http://python.org/sf/771334 Signals discard one level of exception handling (2003-07-14) http://python.org/sf/771429 pyconfig.h duplicates common defines (2003-07-15) http://python.org/sf/771479 doctest.DocTestSuite does not support __test__ (2003-07-15) http://python.org/sf/772091 digraphs on komment lines / xlib (2003-07-16) http://python.org/sf/772176 right button context 'edit with idle' (2003-07-16) http://python.org/sf/772787 unknown encoding -> MemoryError (2003-07-17) http://python.org/sf/772896 nconsistant results for os.listdir,os.path.isdir on W2k (2003-07-17) http://python.org/sf/773286 Dubious use of Unicode literals in tutorial (2003-07-17) http://python.org/sf/773351 posix needs to generate unicode filenames where necessary (2003-07-17) http://python.org/sf/773356 2.3b2 pimp.py calls non-existent routine (2003-07-17) http://python.org/sf/773450 XP manifest files should be installed (2003-07-19) http://python.org/sf/774188 2.3c1 readme unparseable sentence (2003-07-20) http://python.org/sf/774480 UnicodeError (2003-07-20) http://python.org/sf/774536 New Patches ----------- HTMLParser.py - more robust SCRIPT tag parsing (2003-01-19) http://python.org/sf/670664 test_htmlparser -- more robust SCRIPT tag handling (2003-01-24) http://python.org/sf/674449 Fix for LD_LIBRARY_PATH inheritance on SunOS when -shared (2003-07-15) http://python.org/sf/771998 Make commands.getstatusoutput work on Windows (2003-07-15) http://python.org/sf/772029 small fix for setup.py (2003-07-15) http://python.org/sf/772077 Updated 2.2.3 .spec file. (2003-07-16) http://python.org/sf/772696 update old urls (2003-07-17) http://python.org/sf/773007 pimp.py incorrect dict test (2003-07-17) http://python.org/sf/773448 2.3c1: zipfile.py confused by garbage at the very end of zip (2003-07-19) http://python.org/sf/774221 Add a stream type and a merge type to itertoolsmodule.c (2003-07-19) http://python.org/sf/774414 Closed Bugs ----------- In 2.2, types are callable (2001-08-21) http://python.org/sf/453683 Import statement Index ref. broken (2002-02-17) http://python.org/sf/518989 linuxaudiodev not documented (2002-09-17) http://python.org/sf/610401 expat causes a core dump (2002-10-29) http://python.org/sf/630494 dumbdbm __del__ bug (2003-03-12) http://python.org/sf/702775 weakref: proxy_print and proxy_repr incons. (2003-04-16) http://python.org/sf/722763 Section 13.3: htmllib.HTMLParser constructor definition amen (2003-05-15) http://python.org/sf/738090 Failures in test_macostools (2003-06-30) http://python.org/sf/763708 test_bsddb3 crashes if run after test_locale (2003-07-01) http://python.org/sf/763928 Odd behavior in the file object (2003-07-09) http://python.org/sf/768698 Droplets aren't always recognized as apps in MacPython 2.3b2 (2003-07-10) http://python.org/sf/769406 "make info" croaks (2003-07-11) http://python.org/sf/769861 classmethod(classmethod(foo)) -> SystemError (2003-07-13) http://python.org/sf/770465 Closed Patches -------------- patch for new func. string.findall (2003-01-27) http://python.org/sf/675864 SimpleXMLRPCServer: optional 'encoding' argument (2003-02-03) http://python.org/sf/679392 Describe formation of method objects more accurately (2003-06-04) http://python.org/sf/749012 Using __slots__ with str derived classes can cause segfault (2003-06-20) http://python.org/sf/757997 3 bugs fixed: handling of SyntaxErrors in symbol table build (2003-06-30) http://python.org/sf/763201 Unicode strings in sys.path (2003-07-02) http://python.org/sf/764594 fix fnmatch.__all__ (2003-07-03) http://python.org/sf/765238 Warning 'assignment shadows builtin' __builtins__ fix (2003-07-09) http://python.org/sf/768442 From aahz@pythoncraft.com Sun Jul 20 13:33:10 2003 From: aahz@pythoncraft.com (Aahz) Date: Sun, 20 Jul 2003 08:33:10 -0400 Subject: [Python-Dev] Recent experiences with socket.inet_aton, socket.inet_{ntop,pton} In-Reply-To: References: Message-ID: <20030720123310.GA12702@panix.com> On Sun, Jul 20, 2003, Bob Halley wrote: > > It may be that the right answer is that not enough people care about > working with IPv6 addresses on non-IPv6 platforms to make doing > anything worthwhile. I don't know who (other than me) might care > about the issue, which is why I asked :). I'd say that Python 2.4 is the right timeframe to be really pushing this. (Python patch releases (such as 2.3.1) are intended to be pure bugfix releases. They require BDFL approval to change any features.) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From gjc@inescporto.pt Sun Jul 20 13:57:36 2003 From: gjc@inescporto.pt (Gustavo J A M Carneiro) Date: 20 Jul 2003 13:57:36 +0100 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: References: <1058620108.3395.5.camel@emperor.localdomain> <3F19563D.5000909@v.loewis.de> <20030719154504.GU1158@async.com.br> Message-ID: <1058705856.1165.8.camel@emperor.localdomain> A Dom, 2003-07-20 =E0s 10:50, Martin v. L=F6wis escreveu: > Christian Reis writes: >=20 > > > a) it is unlikely that patches are accepted from anybody but > > > the author of the code, and > > > b) it is unlikely that patches are implemented that provide huge > > > chunks of the C library. > >=20 > > I'm afraid I didn't quite understand these two points: > >=20 > > a) Do you mean to say that the patch should be sent *to* the original > > author of the locale code? The original author of the code that *call= s* > > atof/strtod? >=20 > No. I said that the original author should send us the patches; we > will only accept them from that author. What if the original author isn't the least interested in Python? I am, but I'm not willing reinvent the wheel. >=20 > > If the latter I can try and get Alex Larsson to submit the code. Is > > written permission from the glib team, relicensing the code, not > > acceptable enough, though? >=20 > We would have to discuss this in the PSF. In general, we want the PSF > to be owner of all contributed code, see >=20 > http://www.python.org/psf/psf-contributor-agreement.html >=20 > We had bad experience with contributions by non-authors in the past, > and had to back out changes that we later found we had no right to > distribute. >=20 > > b) I'm unsure as to how we should proceed without offering alternativ= e > > versions of strtod/formatd (which is what the pystrtod.c file include= s); > > AFAICS, the current situation is *caused* by the libc versions not be= ing > > LC_NUMERIC-safe. Do you see an alternative? >=20 > It might well be unimplementable. However, if you can find > platform-specific routines that you can wrap with a small wrapper, > falling back to strtod if such routines are not available, that might > be a way out. For example, on glibc, you could use __strtod_l. Well, *my* glibc (2.3.1) has no such function. Even if it had, I would not use it because of the double underscore prefix. cd /usr/include/ find . -type f -print0 | xargs -0 -e grep -n -e __strtod_l grep exited abnormally with code 123 at Sun Jul 20 13:48:41 Anyway, the code is not that big, and it uses libc's strtod. Regards. --=20 Gustavo J. A. M. Carneiro From skip@pobox.com Sun Jul 20 16:13:47 2003 From: skip@pobox.com (Skip Montanaro) Date: Sun, 20 Jul 2003 10:13:47 -0500 Subject: [Python-Dev] Cross Compiling In-Reply-To: <20030720121141.B30653@linuxpower.org> References: <20030720121141.B30653@linuxpower.org> Message-ID: <16154.45483.60250.541613@montanaro.dyndns.org> Adam> The configure script (for 2.2.3 at least) has defaults for its Adam> tests of sizeof(int) and the like which are completely broken for Adam> cross compiling. (They are generally values for a 32-bit system). ... Adam> So can I suggest a better(?) way of doing this (for systems with a Adam> GNU toolchain at least): ... Adam> I'm afraid that I lack the required autoconf-fu to supply a Adam> helpfuly patch to configure.in. Can you post a patch to SF? Assign it to me if you want (montanaro). We currently have bigger fish to fry with the impending 2.3 release. Thanks, Skip From guido@python.org Sun Jul 20 18:46:58 2003 From: guido@python.org (Guido van Rossum) Date: Sun, 20 Jul 2003 13:46:58 -0400 Subject: [Python-Dev] Recent experiences with socket.inet_aton, socket.inet_{ntop,pton} In-Reply-To: Your message of "Sun, 20 Jul 2003 03:57:32 PDT." References: Message-ID: <200307201746.h6KHkw510955@pcp02138704pcs.reston01.va.comcast.net> > inet_ntop and pton are not trivial for IPv6 addresses due to the > variety of textual representations required to be accepted as > valid input, e.g.: > > 1080::8:800:200C:417A > ffff:0000:0000:ffff:0000:0000:0000:ffff > ffff:0:0:ffff::ffff > ::1 > :: > 0:0:0:0:0:0:13.1.68.3 > > A good implementation must also detect and reject all of the invalid > cases, such as improper use of the "::" zero compression syntax. > > Finally, there is the desire to generate appropriately "minimized" > output when converting back to text (the two "ffff" examples above are > the same address; the second is the appropriately minimized form). > > I'm not saying it's rocket science; I'm just saying it's sufficiently > nontrivial that you don't want everyone who needs the functions to have > to write them themselves. > > It may be that the right answer is that not enough people care about > working with IPv6 addresses on non-IPv6 platforms to make doing > anything worthwhile. I don't know who (other than me) might care > about the issue, which is why I asked :). But the number of people who care will grow. Let's leave 2.3 alone because it's so close to release time, but I trust you (Bob) to come up with a review of the existing socket module and suggest improvements in API that will improve its usability and decrease its maintenance needs. --Guido van Rossum (home page: http://www.python.org/~guido/) From zooko@zooko.com Fri Jul 11 00:58:33 2003 From: zooko@zooko.com (Zooko) Date: 10 Jul 2003 19:58:33 -0400 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: Message from Just van Rossum of "Thu, 10 Jul 2003 23:34:19 +0200." References: Message-ID: I don't know if this helps, but appended is a profile of the current CVS version of Python while my Linux box was doing: while [ 1 ] ; do /usr/local/bin/python -c '' ; done This was produced with oprofile, which works by checking every now and again to see what my Linux system is currently up to. The most frequent thing was that 18827 of the times that it checked, it saw that libc was doing something, and the second most frequent was that 12424 of the times that it checked, it saw that PyDict_Next() was doing something. oprofile even writes out an annotated version of the source code, appended. The left-most number is number of times an instruction corresponding to that line was being processed, and the other number is the percentage. Regards, Zooko :int :PyDict_Next(PyObject *op, int *ppos, PyObject **pkey, PyObject **pvalue) 1639 0.8670 :{ /* PyDict_Next total: 12424 6.5721 */ : int i; : register dictobject *mp; 193 0.1021 : if (!PyDict_Check(op)) : return 0; : mp = (dictobject *)op; 108 0.0571 : i = *ppos; 145 0.0767 : if (i < 0) : return 0; 1375 0.7274 : while (i <= mp->ma_mask && mp->ma_table[i].me_value == NULL) 3209 1.6975 : i++; 3766 1.9922 : *ppos = i+1; 103 0.0545 : if (i > mp->ma_mask) : return 0; 312 0.1650 : if (pkey) 137 0.0725 : *pkey = mp->ma_table[i].me_key; 138 0.0730 : if (pvalue) 385 0.2037 : *pvalue = mp->ma_table[i].me_value; 154 0.0815 : return 1; 760 0.4020 :} CPU: Athlon, speed 1410.24 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 705000 vma samples cum. samples % cum. % linenr info app name symbol name 00000000 18827 18827 9.9592 9.9592 (no location information) libc-2.3.1.so (no symbols) 0806d760 12424 31251 6.5721 16.5313 dictobject.c:674 python PyDict_Next 00007042 9544 40795 5.0486 21.5800 (no location information) ld-2.3.1.so do_lookup_versioned 0806d084 7469 48264 3.9510 25.5310 dictobject.c:312 python lookdict_string 080b33fc 5927 54191 3.1353 28.6663 gcmodule.c:223 python visit_decref 0000dc18 5765 59956 3.0496 31.7159 (no location information) ld-2.3.1.so strcmp 08073d88 5511 65467 2.9152 34.6311 stringobject.c:1142 python string_hash 080b3470 4243 69710 2.2445 36.8756 gcmodule.c:259 python visit_reachable 080c1a24 3693 73403 1.9535 38.8291 acceler.c:65 python fixstate 080941b0 3676 77079 1.9446 40.7737 ceval.c:550 python eval_frame c0236150 3575 80654 1.8911 42.6648 (no location information) vmlinux fast_clear_page c0129ca0 3218 83872 1.7023 44.3671 (no location information) vmlinux file_read_actor 08071de4 3161 87033 1.6721 46.0392 obmalloc.c:701 python PyObject_Free 08071cac 2858 89891 1.5118 47.5511 obmalloc.c:557 python PyObject_Malloc c0149820 2732 92623 1.4452 48.9962 (no location information) vmlinux d_lookup c02361a0 2615 95238 1.3833 50.3795 (no location information) vmlinux fast_copy_page 080789f0 2517 97755 1.3315 51.7110 tupleobject.c:392 python tupletraverse 080b33e0 2394 100149 1.2664 52.9774 gcmodule.c:212 python update_refs 0806f06c 2384 102533 1.2611 54.2385 dictobject.c:1662 python dict_traverse c0140930 2300 104833 1.2167 55.4552 (no location information) vmlinux link_path_walk 080ab6c8 2243 107076 1.1865 56.6417 marshal.c:382 python r_object 08073d40 2099 109175 1.1103 57.7520 stringobject.c:1130 python _PyString_Eq 00006dd7 2067 111242 1.0934 58.8454 (no location information) ld-2.3.1.so _dl_elf_hash 0807265c 1732 112974 0.9162 59.7616 stringobject.c:106 python PyString_FromString 080ab5d0 1613 114587 0.8533 60.6149 marshal.c:327 python r_long 080999fc 1589 116176 0.8406 61.4555 compile.c:334 python optimize_code 0806d3b0 1503 117679 0.7951 62.2505 dictobject.c:483 python PyDict_GetItem 08077dd0 1443 119122 0.7633 63.0138 stringobject.c:4104 python PyString_InternInPlace 0806d1c4 1366 120488 0.7226 63.7364 dictobject.c:369 python insertdict 0806d420 1313 121801 0.6946 64.4310 dictobject.c:509 python PyDict_SetItem 0806d264 1307 123108 0.6914 65.1224 dictobject.c:401 python dictresize 00006aa8 1263 124371 0.6681 65.7905 (no location information) libpthread-0.10.so __pthread_mutex_unlock 080783c8 1137 125508 0.6015 66.3919 tupleobject.c:137 python tupledealloc c01257a0 1102 126610 0.5829 66.9749 (no location information) vmlinux copy_page_range c0107520 1078 127688 0.5702 67.5451 (no location information) vmlinux page_fault 08072560 1067 128755 0.5644 68.1096 stringobject.c:57 python PyString_FromStringAndSize 000068e6 1047 129802 0.5538 68.6634 (no location information) libpthread-0.10.so __pthread_mutex_lock 0806d508 1046 130848 0.5533 69.2167 dictobject.c:555 python PyDict_DelItem 00007aa6 1035 131883 0.5475 69.7642 (no location information) ld-2.3.1.so elf_dynamic_do_rel.7 08072e9c 968 132851 0.5121 70.2763 stringobject.c:499 python string_dealloc 000075cc 959 133810 0.5073 70.7836 (no location information) ld-2.3.1.so elf_machine_rel.0 08064c98 931 134741 0.4925 71.2761 intobject.c:1098 python PyInt_Fini c0126d80 872 135613 0.4613 71.7373 (no location information) vmlinux zap_pte_range 0806d810 838 136451 0.4433 72.1806 dictobject.c:699 python dict_dealloc c012a530 791 137242 0.4184 72.5991 (no location information) vmlinux filemap_nopage 00000000 783 138025 0.4142 73.0133 (no location information) bash (no symbols) 000098c3 773 138798 0.4089 73.4222 (no location information) libpthread-0.10.so __pthread_alt_unlock 00006485 756 139554 0.3999 73.8221 (no location information) ld-2.3.1.so _dl_lookup_versioned_symbol_internal c0129180 729 140283 0.3856 74.2077 (no location information) vmlinux __find_get_page c01304c0 702 140985 0.3713 74.5791 (no location information) vmlinux rmqueue 080ab504 622 141607 0.3290 74.9081 marshal.c:304 python r_string 080c8f58 608 142215 0.3216 75.2297 moduleobject.c:99 python _PyModule_Clear 0807811c 580 142795 0.3068 75.5365 tupleobject.c:28 python PyTuple_New c0235d50 577 143372 0.3052 75.8417 (no location information) vmlinux strncpy_from_user c01278e0 576 143948 0.3047 76.1464 (no location information) vmlinux find_vma c0130240 547 144495 0.2894 76.4358 (no location information) vmlinux __free_pages_ok 080c80d8 543 145038 0.2872 76.7230 funcobject.c:422 python func_traverse c0148ec0 517 145555 0.2735 76.9965 (no location information) vmlinux dput 00000000 506 146061 0.2677 77.2642 (no location information) libstdc++.so.5.0.5 (no symbols) 00006837 499 146560 0.2640 77.5282 (no location information) libpthread-0.10.so __pthread_mutex_trylock 08070984 490 147050 0.2592 77.7874 object.c:1160 python PyObject_Hash c01404d0 484 147534 0.2560 78.0434 (no location information) vmlinux vfs_permission 08099bdc 482 148016 0.2550 78.2984 compile.c:410 python PyCode_New c01072dc 481 148497 0.2544 78.5528 (no location information) vmlinux system_call c012f160 443 148940 0.2343 78.7871 (no location information) vmlinux kmem_cache_free_one 0809950c 443 149383 0.2343 79.0215 compile.c:159 python code_dealloc 080a4b28 442 149825 0.2338 79.2553 getargs.c:121 python vgetargs1 00006e48 431 150256 0.2280 79.4833 (no location information) ld-2.3.1.so do_lookup 08073bc0 427 150683 0.2259 79.7092 stringobject.c:1067 python string_richcompare c0123a40 416 151099 0.2201 79.9292 (no location information) vmlinux supplemental_group_member 000096bf 414 151513 0.2190 80.1482 (no location information) libpthread-0.10.so __pthread_alt_lock 08070de8 405 151918 0.2142 80.3625 object.c:1358 python PyObject_GenericGetAttr c0126910 387 152305 0.2047 80.5672 (no location information) vmlinux do_no_page 08099918 378 152683 0.2000 80.7671 compile.c:293 python all_name_chars c0114010 370 153053 0.1957 80.9629 (no location information) vmlinux do_page_fault 080b34dc 363 153416 0.1920 81.1549 gcmodule.c:310 python move_unreachable c0125680 351 153767 0.1857 81.3406 (no location information) vmlinux __free_pte 08097fa8 351 154118 0.1857 81.5262 ceval.c:3409 python call_function 0807a0ec 344 154462 0.1820 81.7082 typeobject.c:794 python PyType_IsSubtype 08099978 339 154801 0.1793 81.8875 compile.c:311 python intern_strings 08072774 329 155130 0.1740 82.0616 stringobject.c:160 python PyString_FromFormatV 00009070 326 155456 0.1724 82.2340 (no location information) ld-2.3.1.so fixup 080a81fc 315 155771 0.1666 82.4006 import.c:1050 python find_module 000089d3 315 156086 0.1666 82.5673 (no location information) libpthread-0.10.so libc_internal_tsd_address 00006eac 301 156387 0.1592 82.7265 (no location information) libpthread-0.10.so __pthread_alt_trylock 000089bc 297 156684 0.1571 82.8836 (no location information) libpthread-0.10.so libc_internal_tsd_get c012f070 294 156978 0.1555 83.0391 (no location information) vmlinux __kmem_cache_alloc c01310c0 293 157271 0.1550 83.1941 (no location information) vmlinux free_page_and_swap_cache 080b4064 292 157563 0.1545 83.3486 gcmodule.c:1030 python PyObject_GC_UnTrack 00000000 267 157830 0.1412 83.4898 (no location information) xemacs-21.4.13-nomule (no symbols) 00008a08 267 158097 0.1412 83.6311 (no location information) libpthread-0.10.so thread_self c0129020 264 158361 0.1397 83.7707 (no location information) vmlinux unlock_page 080a541c 252 158613 0.1333 83.9040 getargs.c:459 python convertsimple c01295c0 251 158864 0.1328 84.0368 (no location information) vmlinux do_generic_file_read 08078288 245 159109 0.1296 84.1664 tupleobject.c:98 python PyTuple_GetItem 08070614 245 159354 0.1296 84.2960 object.c:974 python PyObject_RichCompare c011ac10 244 159598 0.1291 84.4251 (no location information) vmlinux session_of_pgrp 080b40a0 238 159836 0.1259 84.5510 gcmodule.c:1047 python _PyObject_GC_Malloc 0000938c 235 160071 0.1243 84.6753 (no location information) libpthread-0.10.so __pthread_lock 080634e4 234 160305 0.1238 84.7991 intobject.c:59 python fill_free_list 080ac6f8 233 160538 0.1233 84.9223 modsupport.c:106 python countformat c0126ac0 222 160760 0.1174 85.0398 (no location information) vmlinux handle_mm_fault 0806dd7c 219 160979 0.1158 85.1556 dictobject.c:883 python dict_keys c0131550 216 161195 0.1143 85.2699 (no location information) vmlinux remove_exclusive_swap_page 080c6ed8 216 161411 0.1143 85.3841 frameobject.c:539 python PyFrame_New c011b090 200 161611 0.1058 85.4899 (no location information) vmlinux exit_notify c0107325 199 161810 0.1053 85.5952 (no location information) vmlinux restore_all 080c8770 193 162003 0.1021 85.6973 methodobject.c:64 python PyCFunction_Call c010b9a0 186 162189 0.0984 85.7957 (no location information) vmlinux mask_and_ack_8259A 080c7720 184 162373 0.0973 85.8930 funcobject.c:11 python PyFunction_New 0806f31c 178 162551 0.0942 85.9872 dictobject.c:1969 python PyDict_SetItemString 08053b28 176 162727 0.0931 86.0803 (no location information) python anonymous symbol from section .plt 080c895c 175 162902 0.0926 86.1728 methodobject.c:151 python meth_traverse 080b343c 174 163076 0.0920 86.2649 gcmodule.c:245 python subtract_refs c0135da0 173 163249 0.0915 86.3564 (no location information) vmlinux get_unused_fd 0806570c 173 163422 0.0915 86.4479 listobject.c:203 python list_dealloc 080c7f14 171 163593 0.0905 86.5384 funcobject.c:395 python func_dealloc 0806f2cc 171 163764 0.0905 86.6288 dictobject.c:1957 python PyDict_GetItemString 08078240 169 163933 0.0894 86.7182 tupleobject.c:87 python PyTuple_Size 00000780 168 164101 0.0889 86.8071 (no location information) ne2k-pci.o ne2k_pci_block_output 0805af70 167 164268 0.0883 86.8954 classobject.c:406 python class_traverse 08081f94 166 164434 0.0878 86.9832 typeobject.c:5339 python add_operators 00006dda 164 164598 0.0868 87.0700 (no location information) libpthread-0.10.so thread_self c010ca50 163 164761 0.0862 87.1562 (no location information) vmlinux timer_interrupt 080c6900 163 164924 0.0862 87.2425 frameobject.c:383 python frame_dealloc 000094fb 162 165086 0.0857 87.3281 (no location information) libpthread-0.10.so __pthread_unlock c01073cc 161 165247 0.0852 87.4133 (no location information) vmlinux error_code 08097dd8 161 165408 0.0852 87.4985 ceval.c:3328 python PyEval_CallObjectWithKeywords c0126820 160 165568 0.0846 87.5831 (no location information) vmlinux do_anonymous_page 080c5810 159 165727 0.0841 87.6672 descrobject.c:378 python descr_traverse 08070af4 157 165884 0.0831 87.7503 object.c:1217 python PyObject_GetAttr 00004bd3 152 166036 0.0804 87.8307 (no location information) libpthread-0.10.so _pthread_cleanup_pop_restore c0127270 151 166187 0.0799 87.9106 (no location information) vmlinux do_mmap_pgoff c0137830 150 166337 0.0793 87.9899 (no location information) vmlinux fput 080b41dc 149 166486 0.0788 88.0687 gcmodule.c:1101 python PyObject_GC_Del 080a5304 148 166634 0.0783 88.1470 getargs.c:394 python convertitem c01262f0 147 166781 0.0778 88.2248 (no location information) vmlinux do_wp_page c012eac0 143 166924 0.0756 88.3004 (no location information) vmlinux kmem_cache_free c01405e0 142 167066 0.0751 88.3755 (no location information) vmlinux permission 0805a81c 142 167208 0.0751 88.4507 classobject.c:187 python class_lookup 000072c2 140 167348 0.0741 88.5247 (no location information) ld-2.3.1.so _dl_name_match_p c0129420 137 167485 0.0725 88.5972 (no location information) vmlinux generic_file_readahead c01406b0 136 167621 0.0719 88.6691 (no location information) vmlinux cached_lookup c0141500 134 167755 0.0709 88.7400 (no location information) vmlinux open_namei 00004b89 133 167888 0.0704 88.8104 (no location information) libpthread-0.10.so _pthread_cleanup_push_defer 0806e5e4 130 168018 0.0688 88.8791 dictobject.c:1224 python PyDict_Copy 080aca7c 128 168146 0.0677 88.9468 modsupport.c:265 python do_mkvalue 080732e8 128 168274 0.0677 89.0146 stringobject.c:703 python PyString_AsString 08096a40 127 168401 0.0672 89.0817 ceval.c:2443 python PyEval_EvalCodeEx 08070798 127 168528 0.0672 89.1489 object.c:1051 python PyObject_RichCompareBool c012f310 126 168654 0.0667 89.2156 (no location information) vmlinux lru_cache_add c0132660 125 168779 0.0661 89.2817 (no location information) vmlinux swap_duplicate 0806cdc4 125 168904 0.0661 89.3478 dictobject.c:157 python PyDict_New 0807c148 121 169025 0.0640 89.4118 typeobject.c:2205 python type_is_gc 08065574 121 169146 0.0640 89.4758 listobject.c:144 python ins1 c0235e30 119 169265 0.0629 89.5388 (no location information) vmlinux strnlen_user c012f370 118 169383 0.0624 89.6012 (no location information) vmlinux __lru_cache_del 08067b9c 115 169498 0.0608 89.6620 listobject.c:1901 python list_traverse 000039e7 115 169613 0.0608 89.7229 (no location information) ld-2.3.1.so _dl_map_object_from_fd c0123a80 114 169727 0.0603 89.7832 (no location information) vmlinux in_group_p 00008b33 111 169838 0.0587 89.8419 (no location information) libpthread-0.10.so __funlockfile c0140400 109 169947 0.0577 89.8995 (no location information) vmlinux getname c0129590 109 170056 0.0577 89.9572 (no location information) vmlinux mark_page_accessed c0127060 108 170164 0.0571 90.0143 (no location information) vmlinux find_vma_prepare 080c863c 108 170272 0.0571 90.0715 methodobject.c:11 python PyCFunction_NewEx 08081a44 107 170379 0.0566 90.1281 typeobject.c:5017 python slotptr 00004cb1 107 170486 0.0566 90.1847 (no location information) libpthread-0.10.so thread_self c0131310 106 170592 0.0561 90.2407 (no location information) vmlinux swap_info_get c0125940 105 170697 0.0555 90.2963 (no location information) vmlinux zap_page_range 08098180 105 170802 0.0555 90.3518 ceval.c:3486 python fast_function 08097d24 105 170907 0.0555 90.4074 ceval.c:3272 python PyEval_GetRestricted 080ac9ac 104 171011 0.0550 90.4624 modsupport.c:237 python do_mktuple 08074174 104 171115 0.0550 90.5174 stringobject.c:1348 python string_split 080b4150 103 171218 0.0545 90.5719 gcmodule.c:1078 python _PyObject_GC_NewVar 080652ec 103 171321 0.0545 90.6264 listobject.c:57 python PyList_New 00007a42 102 171423 0.0540 90.6803 (no location information) ld-2.3.1.so elf_machine_lazy_rel.4 c01368f0 101 171524 0.0534 90.7338 (no location information) vmlinux sys_read 00008b10 100 171624 0.0529 90.7867 (no location information) libpthread-0.10.so __flockfile 00008a70 99 171723 0.0524 90.8390 (no location information) libpthread-0.10.so __errno_location 080c2094 98 171821 0.0518 90.8909 parser.c:138 python classify 080b3324 97 171918 0.0513 90.9422 gcmodule.c:153 python gc_list_remove 080667e8 97 172015 0.0513 90.9935 listobject.c:857 python binarysort 0000df04 97 172112 0.0513 91.0448 (no location information) ld-2.3.1.so memset c011ac60 96 172208 0.0508 91.0956 (no location information) vmlinux will_become_orphaned_pgrp 0808ef90 96 172304 0.0508 91.1464 bltinmodule.c:739 python builtin_map 00000550 96 172400 0.0508 91.1971 (no location information) oprofile.o do_hash c0131640 92 172492 0.0487 91.2458 (no location information) vmlinux free_swap_and_cache c0141180 91 172583 0.0481 91.2940 (no location information) vmlinux path_init c0236820 89 172672 0.0471 91.3410 (no location information) vmlinux number 00008374 89 172761 0.0471 91.3881 (no location information) ld-2.3.1.so _dl_map_object_deps_internal 00005cfb 89 172850 0.0471 91.4352 (no location information) ld-2.3.1.so _dl_cache_libcmp 00000000 88 172938 0.0466 91.4817 (no location information) libcrypto.so.0.9.7 (no symbols) 08074408 86 173024 0.0455 91.5272 stringobject.c:1420 python string_join c0135f10 84 173108 0.0444 91.5717 (no location information) vmlinux sys_open 080a49d0 84 173192 0.0444 91.6161 getargs.c:46 python PyArg_ParseTuple 0807ddbc 84 173276 0.0444 91.6605 typeobject.c:3084 python PyType_Ready 080719bc 84 173360 0.0444 91.7050 object.c:2100 python PyMem_Malloc c013deb0 83 173443 0.0439 91.7489 (no location information) vmlinux sys_fstat64 080c8898 83 173526 0.0439 91.7928 methodobject.c:124 python meth_dealloc 08079b9c 82 173608 0.0434 91.8362 typeobject.c:440 python PyType_GenericAlloc c01277c0 80 173688 0.0423 91.8785 (no location information) vmlinux get_unmapped_area 080732ac 79 173767 0.0418 91.9203 stringobject.c:695 python PyString_Size 0805a230 78 173845 0.0413 91.9615 abstract.c:2183 python PyIter_Next 080b4128 77 173922 0.0407 92.0023 gcmodule.c:1069 python _PyObject_GC_New 080598dc 77 173999 0.0407 92.0430 abstract.c:1751 python PyObject_Call 08078fa0 76 174075 0.0402 92.0832 tupleobject.c:718 python PyTuple_Fini 080654a4 75 174150 0.0397 92.1229 listobject.c:121 python PyList_SetItem 080a9010 74 174224 0.0391 92.1620 import.c:1948 python import_module_ex 080782f0 74 174298 0.0391 92.2012 tupleobject.c:112 python PyTuple_SetItem 080a6510 73 174371 0.0386 92.2398 getargs.c:1159 python vgetargskeywords 080a37ec 73 174444 0.0386 92.2784 errors.c:27 python PyErr_Restore c0137a40 72 174516 0.0381 92.3165 (no location information) vmlinux __constant_c_and_count_memset c0130b30 72 174588 0.0381 92.3546 (no location information) vmlinux nr_free_pages c0128210 72 174660 0.0381 92.3927 (no location information) vmlinux exit_mmap 080a9208 72 174732 0.0381 92.4307 import.c:2010 python get_parent 08073f4c 72 174804 0.0381 92.4688 stringobject.c:1217 python string_buffer_getreadbuf c0127cc0 71 174875 0.0376 92.5064 (no location information) vmlinux do_munmap c0136060 70 174945 0.0370 92.5434 (no location information) vmlinux sys_close c0126be0 70 175015 0.0370 92.5804 (no location information) vmlinux pte_alloc 080c2138 70 175085 0.0370 92.6175 parser.c:204 python PyParser_AddToken 080ac4f8 70 175155 0.0370 92.6545 modsupport.c:35 python Py_InitModule4 080a9394 70 175225 0.0370 92.6915 import.c:2078 python load_next 0805a278 70 175295 0.0370 92.7286 classobject.c:23 python PyClass_New 00005fff 70 175365 0.0370 92.7656 (no location information) ld-2.3.1.so _dl_lookup_symbol_internal 08098c68 69 175434 0.0365 92.8021 ceval.c:3905 python import_all_from 00008aa9 69 175503 0.0365 92.8386 (no location information) libpthread-0.10.so thread_self 080a391c 68 175571 0.0360 92.8746 errors.c:77 python PyErr_Occurred 08098b64 68 175639 0.0360 92.9105 ceval.c:3858 python cmp_outcome 08063540 68 175707 0.0360 92.9465 intobject.c:97 python PyInt_FromLong 00004c22 67 175774 0.0354 92.9819 (no location information) ld-2.3.1.so _dl_map_object_internal c0141140 65 175839 0.0344 93.0163 (no location information) vmlinux path_lookup c0130af0 65 175904 0.0344 93.0507 (no location information) vmlinux __free_pages c01308e0 65 175969 0.0344 93.0851 (no location information) vmlinux __alloc_pages c01485f0 63 176032 0.0333 93.1184 (no location information) vmlinux locks_remove_posix c013dfb0 63 176095 0.0333 93.1518 (no location information) vmlinux __constant_copy_to_user c0135be0 63 176158 0.0333 93.1851 (no location information) vmlinux dentry_open c013e220 62 176220 0.0328 93.2179 (no location information) vmlinux copy_strings 080b330c 62 176282 0.0328 93.2507 gcmodule.c:144 python gc_list_append 000092d0 62 176344 0.0328 93.2835 (no location information) ld-2.3.1.so _dl_runtime_resolve 080572ec 61 176405 0.0323 93.3157 abstract.c:114 python PyObject_SetItem 0000a41b 61 176466 0.0323 93.3480 (no location information) ld-2.3.1.so _dl_check_map_versions_internal c0129d40 60 176526 0.0317 93.3797 (no location information) vmlinux generic_file_read c0114e60 60 176586 0.0317 93.4115 (no location information) vmlinux schedule c010d6a0 60 176646 0.0317 93.4432 (no location information) vmlinux kernel_fpu_begin c0107314 59 176705 0.0312 93.4744 (no location information) vmlinux ret_from_sys_call 0807d268 59 176764 0.0312 93.5056 typeobject.c:2912 python inherit_slots 0000795b 59 176823 0.0312 93.5369 (no location information) libpthread-0.10.so pthread_self 08071218 58 176881 0.0307 93.5675 object.c:1565 python PyObject_IsTrue c0126f40 57 176938 0.0302 93.5977 (no location information) vmlinux sys_brk 08093808 57 176995 0.0302 93.6278 exceptions.c:1727 python _PyExc_Init c0125700 56 177051 0.0296 93.6575 (no location information) vmlinux clear_page_tables 080ad858 56 177107 0.0296 93.6871 pystate.c:252 python PyThreadState_Get 080656b8 56 177163 0.0296 93.7167 listobject.c:190 python PyList_Append 08058cb0 56 177219 0.0296 93.7463 abstract.c:1157 python PySequence_GetItem c014b480 55 177274 0.0291 93.7754 (no location information) vmlinux update_atime 0806d608 55 177329 0.0291 93.8045 dictobject.c:590 python PyDict_Clear 08057628 55 177384 0.0291 93.8336 abstract.c:229 python PyObject_CheckReadBuffer 00000000 55 177439 0.0291 93.8627 (no location information) libgklayout.so (no symbols) 080a4abc 54 177493 0.0286 93.8913 getargs.c:105 python cleanreturn c01285a0 53 177546 0.0280 93.9193 (no location information) vmlinux set_page_dirty 00000000 53 177599 0.0280 93.9473 (no location information) XFree86 (no symbols) 00127710 53 177652 0.0280 93.9754 (no location information) nvidia.o __nvsym00429 0000899d 53 177705 0.0280 94.0034 (no location information) libpthread-0.10.so libc_internal_tsd_set c0236000 52 177757 0.0275 94.0309 (no location information) vmlinux _mmx_memcpy 0808e5d8 52 177809 0.0275 94.0584 bltinmodule.c:257 python builtin_chr c0137680 51 177860 0.0270 94.0854 (no location information) vmlinux get_empty_filp c0127940 51 177911 0.0270 94.1124 (no location information) vmlinux find_vma_prev c01173e0 51 177962 0.0270 94.1394 (no location information) vmlinux dup_mmap 080a80a0 51 178013 0.0270 94.1663 import.c:965 python is_builtin 0809733c 51 178064 0.0270 94.1933 ceval.c:2792 python reset_exc_info c0236bd0 50 178114 0.0264 94.2198 (no location information) vmlinux vsnprintf c01313e0 50 178164 0.0264 94.2462 (no location information) vmlinux swap_entry_free 08077f14 50 178214 0.0264 94.2727 stringobject.c:4163 python PyString_InternFromString c010ce80 49 178263 0.0259 94.2986 (no location information) vmlinux old_mmap 080a982c 49 178312 0.0259 94.3245 import.c:2250 python import_submodule 08071e78 47 178359 0.0249 94.3494 obmalloc.c:785 python PyObject_Realloc 0000a0b8 47 178406 0.0249 94.3742 (no location information) ld-2.3.1.so match_symbol c013dc90 46 178452 0.0243 94.3986 (no location information) vmlinux cp_new_stat64 c0127fb0 46 178498 0.0243 94.4229 (no location information) vmlinux do_brk 080a8b78 45 178543 0.0238 94.4467 import.c:1679 python load_module 00006b5f 45 178588 0.0238 94.4705 (no location information) libpthread-0.10.so __pthread_mutexattr_setkind_np c0135b70 44 178632 0.0233 94.4938 (no location information) vmlinux filp_open 080c8cfc 44 178676 0.0233 94.5171 moduleobject.c:19 python PyModule_New 080c19e8 44 178720 0.0233 94.5403 acceler.c:55 python fixdfa 080577e0 44 178764 0.0233 94.5636 abstract.c:350 python binary_op1 00000000 44 178808 0.0233 94.5869 (no location information) libdl-2.3.1.so (no symbols) c010b8d0 43 178851 0.0227 94.6096 (no location information) vmlinux enable_8259A_irq 080c5838 43 178894 0.0227 94.6324 descrobject.c:583 python descr_new 0805b8c0 43 178937 0.0227 94.6551 classobject.c:801 python instance_setattr c0153f90 42 178979 0.0222 94.6773 (no location information) vmlinux proc_lookup 080c5294 42 179021 0.0222 94.6996 descrobject.c:120 python method_get 080ad414 42 179063 0.0222 94.7218 pystate.c:126 python threadstate_getframe 0808e064 42 179105 0.0222 94.7440 bltinmodule.c:36 python builtin___import__ 0805e2dc 42 179147 0.0222 94.7662 classobject.c:2099 python PyMethod_New 080a70ec 41 179188 0.0217 94.7879 import.c:326 python PyImport_GetModuleDict 08097d0c 41 179229 0.0217 94.8096 ceval.c:3265 python PyEval_GetFrame 000053cb 41 179270 0.0217 94.8313 (no location information) ld-2.3.1.so _dl_name_match_p c014c980 40 179310 0.0212 94.8524 (no location information) vmlinux lookup_mnt c0143690 40 179350 0.0212 94.8736 (no location information) vmlinux __vfs_follow_link 080c1984 40 179390 0.0212 94.8948 acceler.c:36 python PyGrammar_RemoveAccelerators 0809ffac 40 179430 0.0212 94.9159 compile.c:4284 python jcompile 08098490 40 179470 0.0212 94.9371 ceval.c:3604 python load_args 08073fa4 40 179510 0.0212 94.9582 stringobject.c:1237 python string_buffer_getsegcount 08070bfc 40 179550 0.0212 94.9794 object.c:1264 python PyObject_SetAttr c013df30 39 179589 0.0206 95.0000 (no location information) vmlinux __constant_c_and_count_memset 080a78a8 39 179628 0.0206 95.0207 import.c:593 python PyImport_ExecCodeModuleEx 080767f8 39 179667 0.0206 95.0413 stringobject.c:3309 python _PyString_Resize c02362a0 38 179705 0.0201 95.0614 (no location information) vmlinux mmx_clear_page c015e630 38 179743 0.0201 95.0815 (no location information) vmlinux ext2_follow_link c013ddb0 38 179781 0.0201 95.1016 (no location information) vmlinux sys_stat64 c0116af0 38 179819 0.0201 95.1217 (no location information) vmlinux do_fork 080c7354 38 179857 0.0201 95.1418 frameobject.c:722 python PyFrame_FastToLocals 080a7120 38 179895 0.0201 95.1619 import.c:355 python PyImport_Cleanup 08068828 38 179933 0.0201 95.1820 listobject.c:2442 python listiter_next 08056720 38 179971 0.0201 95.2021 tokenizer.c:999 python tok_get 0000732c 38 180009 0.0201 95.2222 (no location information) ld-2.3.1.so _dl_new_object c01314e0 37 180046 0.0196 95.2418 (no location information) vmlinux can_share_swap_page c0127ac0 37 180083 0.0196 95.2613 (no location information) vmlinux unmap_fixup 080ac018 37 180120 0.0196 95.2809 marshal.c:687 python PyMarshal_ReadLastObjectFromFile 080a91a0 37 180157 0.0196 95.3005 import.c:1995 python PyImport_ImportModuleEx 08078728 37 180194 0.0196 95.3201 tupleobject.c:264 python tuplecontains 080592d0 37 180231 0.0196 95.3396 abstract.c:1429 python PySequence_List 00000000 37 180268 0.0196 95.3592 (no location information) libX11.so.6.2 (no symbols) c01270d0 36 180304 0.0190 95.3783 (no location information) vmlinux __vma_link 0807ce58 36 180340 0.0190 95.3973 typeobject.c:2758 python add_methods c01167d0 35 180375 0.0185 95.4158 (no location information) vmlinux copy_files 08079a74 35 180410 0.0185 95.4343 typeobject.c:404 python type_call 08066418 35 180445 0.0185 95.4528 listobject.c:652 python listappend 08055144 35 180480 0.0185 95.4714 parsetok.c:104 python parsetok 00008efd 35 180515 0.0185 95.4899 (no location information) libpthread-0.10.so __new_sem_post 0807a8b4 34 180549 0.0180 95.5079 typeobject.c:1184 python mro_implementation 0805a88c 34 180583 0.0180 95.5258 classobject.c:208 python class_getattr 0000809b 34 180617 0.0180 95.5438 (no location information) libpthread-0.10.so thread_self c0237700 33 180650 0.0175 95.5613 (no location information) vmlinux rb_insert_color 08068708 33 180683 0.0175 95.5787 listobject.c:2407 python list_iter 080663b0 33 180716 0.0175 95.5962 listobject.c:633 python ins 0805b1f8 33 180749 0.0175 95.6136 classobject.c:548 python PyInstance_New 080571e4 33 180782 0.0175 95.6311 abstract.c:86 python PyObject_GetItem 00001191 33 180815 0.0175 95.6486 (no location information) ld-2.3.1.so dl_main c0126ec0 32 180847 0.0169 95.6655 (no location information) vmlinux vm_enough_memory c0122010 32 180879 0.0169 95.6824 (no location information) vmlinux do_sigaction 080acccc 32 180911 0.0169 95.6993 modsupport.c:435 python Py_VaBuildValue 0805b460 32 180943 0.0169 95.7163 classobject.c:626 python instance_dealloc 00007d72 32 180975 0.0169 95.7332 (no location information) ld-2.3.1.so _dl_relocate_object_internal 080c1e84 31 181006 0.0164 95.7496 node.c:126 python freechildren 080c1d64 31 181037 0.0164 95.7660 node.c:80 python PyNode_AddChild 080b3854 31 181068 0.0164 95.7824 gcmodule.c:532 python collect 08098e80 31 181099 0.0164 95.7988 ceval.c:3962 python build_class 080984d0 31 181130 0.0164 95.8152 ceval.c:3619 python do_call 08065414 31 181161 0.0164 95.8316 listobject.c:103 python PyList_GetItem 080652cc 31 181192 0.0164 95.8480 listobject.c:13 python roundupsize 0805b6f4 31 181223 0.0164 95.8644 classobject.c:719 python instance_getattr2 00000000 31 181254 0.0164 95.8808 (no location information) libxml2.so.2.5.7 (no symbols) 00005724 31 181285 0.0164 95.8972 (no location information) ld-2.3.1.so _dl_load_cache_lookup c018b7c0 30 181315 0.0159 95.9131 (no location information) vmlinux tty_ioctl c01502d0 30 181345 0.0159 95.9289 (no location information) vmlinux load_elf_binary c01413c0 30 181375 0.0159 95.9448 (no location information) vmlinux __user_walk 080b01d0 30 181405 0.0159 95.9607 sysmodule.c:50 python PySys_GetObject 080accb8 30 181435 0.0159 95.9765 modsupport.c:424 python Py_BuildValue 080709dc 30 181465 0.0159 95.9924 object.c:1174 python PyObject_GetAttrString 00000000 30 181495 0.0159 96.0083 (no location information) libxpcom.so (no symbols) 00000000 30 181525 0.0159 96.0241 (no location information) libglib-2.0.so.0.200.2 (no symbols) 00000000 30 181555 0.0159 96.0400 (no location information) libgdk-x11-2.0.so.0.200.1 (no symbols) 00000420 30 181585 0.0159 96.0559 (no location information) oprofile.o wind_dentries_2_4 000067e6 30 181615 0.0159 96.0718 (no location information) libpthread-0.10.so __pthread_mutex_destroy 080c5124 29 181644 0.0153 96.0871 descrobject.c:61 python descr_check 0806707c 29 181673 0.0153 96.1024 listobject.c:1389 python merge_hi 000098bc 29 181702 0.0153 96.1178 (no location information) ld-2.3.1.so _dl_fini c0235dc0 28 181730 0.0148 96.1326 (no location information) vmlinux clear_user 080c81c4 28 181758 0.0148 96.1474 funcobject.c:469 python function_call 080b2274 28 181786 0.0148 96.1622 thread_pthread.h:272 python PyThread_get_thread_ident 080a8d90 28 181814 0.0148 96.1770 import.c:1817 python find_frozen 080a184c 28 181842 0.0148 96.1918 compile.c:5247 python symtable_node 08067580 28 181870 0.0148 96.2066 listobject.c:1666 python listsort c014c530 27 181897 0.0143 96.2209 (no location information) vmlinux dnotify_flush 0807d098 27 181924 0.0143 96.2352 typeobject.c:2833 python inherit_special 0807a74c 27 181951 0.0143 96.2495 typeobject.c:1114 python pmerge 08075a60 27 181978 0.0143 96.2638 stringobject.c:2391 python string_startswith 0805a0ac 27 182005 0.0143 96.2781 abstract.c:2107 python PyObject_IsSubclass 08059944 27 182032 0.0143 96.2923 abstract.c:1769 python PyObject_CallFunction 00000000 27 182059 0.0143 96.3066 (no location information) libgobject-2.0.so.0.200.2 (no symbols) 00000000 27 182086 0.0143 96.3209 (no location information) xterm (no symbols) c01433b0 26 182112 0.0138 96.3347 (no location information) vmlinux follow_dotdot 080c8dd8 26 182138 0.0138 96.3484 moduleobject.c:45 python PyModule_GetDict 080b400c 26 182164 0.0138 96.3622 gcmodule.c:1017 python PyObject_GC_Track 080ac164 26 182190 0.0138 96.3759 marshal.c:743 python PyMarshal_ReadObjectFromString 080a7d98 26 182216 0.0138 96.3897 import.c:850 python load_source_module 08065ab4 26 182242 0.0138 96.4034 listobject.c:337 python list_item c02379a0 25 182267 0.0132 96.4167 (no location information) vmlinux rb_erase c0235ca0 25 182292 0.0132 96.4299 (no location information) vmlinux __generic_copy_from_user c0235c40 25 182317 0.0132 96.4431 (no location information) vmlinux __generic_copy_to_user 080a79fc 25 182342 0.0132 96.4563 import.c:646 python make_compiled_pathname 080826bc 25 182367 0.0132 96.4695 weakrefobject.c:79 python gc_traverse 08067944 25 182392 0.0132 96.4828 listobject.c:1806 python PyList_AsTuple 0805e8b0 25 182417 0.0132 96.4960 classobject.c:2314 python instancemethod_traverse 00000000 25 182442 0.0132 96.5092 (no location information) screen (no symbols) 00008269 25 182467 0.0132 96.5224 (no location information) libpthread-0.10.so sigaction c01379c0 24 182491 0.0127 96.5351 (no location information) vmlinux file_move c01350d0 24 182515 0.0127 96.5478 (no location information) vmlinux fd_install c011b610 24 182539 0.0127 96.5605 (no location information) vmlinux sys_wait4 080ace24 24 182563 0.0127 96.5732 modsupport.c:515 python PyModule_AddObject 080a6fa0 24 182587 0.0127 96.5859 import.c:245 python lock_import 080a53cc 24 182611 0.0127 96.5986 getargs.c:440 python float_argument_error 080a0390 24 182635 0.0127 96.6113 compile.c:4387 python PyCode_Addr2Line 0809418c 24 182659 0.0127 96.6240 ceval.c:535 python PyEval_EvalCode 08077f44 24 182683 0.0127 96.6367 stringobject.c:4173 python PyString_Fini 08063598 24 182707 0.0127 96.6494 intobject.c:126 python int_dealloc 0805eb60 24 182731 0.0127 96.6621 classobject.c:2439 python instancemethod_descr_get 080596a0 24 182755 0.0127 96.6748 abstract.c:1618 python PySequence_Contains 0804e07c 24 182779 0.0127 96.6875 op_fileio.c:223 oprofiled op_get_line 00003670 24 182803 0.0127 96.7002 (no location information) oprofile.o my_old_mmap 00003db4 24 182827 0.0127 96.7129 (no location information) libpthread-0.10.so anonymous symbol from section .plt c0135fe0 23 182850 0.0122 96.7250 (no location information) vmlinux filp_close c012c630 23 182873 0.0122 96.7372 (no location information) vmlinux change_pte_range c010af20 23 182896 0.0122 96.7494 (no location information) vmlinux IRQ0x00_interrupt 080c2030 23 182919 0.0122 96.7615 parser.c:121 python push 080b2be4 23 182942 0.0122 96.7737 getpath.c:357 python calculate_path 080a392c 23 182965 0.0122 96.7859 errors.c:86 python PyErr_GivenExceptionMatches 080635e4 23 182988 0.0122 96.7980 intobject.c:144 python PyInt_AsLong 0000dab0 23 183011 0.0122 96.8102 (no location information) ld-2.3.1.so index c0137950 22 183033 0.0116 96.8219 (no location information) vmlinux fget 080c9214 22 183055 0.0116 96.8335 moduleobject.c:203 python find_builtin_names 080b8a70 22 183077 0.0116 96.8451 posixmodule.c:6725 python setup_confname_table 080a3e18 22 183099 0.0116 96.8568 errors.c:529 python PyErr_NewException 080a3dd0 22 183121 0.0116 96.8684 errors.c:509 python PyErr_Format 080a0c64 22 183143 0.0116 96.8800 compile.c:4761 python symtable_load_symbols 080653cc 22 183165 0.0116 96.8917 listobject.c:90 python PyList_Size 0805a18c 22 183187 0.0116 96.9033 abstract.c:2148 python PyObject_GetIter 0805603c 22 183209 0.0116 96.9150 tokenizer.c:658 python tok_nextc 00000000 22 183231 0.0116 96.9266 (no location information) libXt.so.6.0 (no symbols) 0000462d 22 183253 0.0116 96.9382 (no location information) ld-2.3.1.so open_verify c0148750 21 183274 0.0111 96.9493 (no location information) vmlinux locks_remove_flock 080b8a54 21 183295 0.0111 96.9604 posixmodule.c:6713 python cmp_constdefs 080b4a5c 21 183316 0.0111 96.9716 signalmodule.c:315 python initsignal 080a80f4 21 183337 0.0111 96.9827 import.c:990 python get_path_importer 080a6af0 21 183358 0.0111 96.9938 getargs.c:1507 python PyArg_UnpackTuple 0807e174 21 183379 0.0111 97.0049 typeobject.c:3243 python add_subclass 0807aa50 21 183400 0.0111 97.0160 typeobject.c:1265 python mro_internal 08076e10 21 183421 0.0111 97.0271 stringobject.c:3651 python PyString_Format 0806dd54 21 183442 0.0111 97.0382 dictobject.c:868 python dict_ass_sub 0806ce84 21 183463 0.0111 97.0493 dictobject.c:201 python lookdict 0805e52c 21 183484 0.0111 97.0604 classobject.c:2217 python instancemethod_dealloc 0805803c 21 183505 0.0111 97.0715 abstract.c:609 python PyNumber_Add 00000000 21 183526 0.0111 97.0826 (no location information) libgcc_s.so.1 (no symbols) 0000d5e0 21 183547 0.0111 97.0938 (no location information) ld-2.3.1.so __mmap 0000b778 21 183568 0.0111 97.1049 (no location information) ld-2.3.1.so _dl_sysdep_start c0140fb0 20 183588 0.0106 97.1154 (no location information) vmlinux path_walk c012a7e0 20 183608 0.0106 97.1260 (no location information) vmlinux generic_file_mmap c0127190 20 183628 0.0106 97.1366 (no location information) vmlinux vma_merge c01227a0 20 183648 0.0106 97.1472 (no location information) vmlinux __constant_copy_to_user c01223b0 20 183668 0.0106 97.1578 (no location information) vmlinux sys_rt_sigaction 080a3a04 20 183688 0.0106 97.1683 errors.c:127 python PyErr_NormalizeException 08079018 20 183708 0.0106 97.1789 tupleobject.c:750 python tuple_iter 08073b68 20 183728 0.0106 97.1895 stringobject.c:1045 python string_item 0805a704 20 183748 0.0106 97.2001 classobject.c:174 python class_dealloc 08059120 20 183768 0.0106 97.2107 abstract.c:1356 python PySequence_Tuple 0004020c 20 183788 0.0106 97.2212 (no location information) nvidia.o __nvsym01306 0000c114 20 183808 0.0106 97.2318 (no location information) ld-2.3.1.so __libc_memalign 0000a8bb 20 183828 0.0106 97.2424 (no location information) ld-2.3.1.so _dl_name_match_p c01453f0 19 183847 0.0101 97.2524 (no location information) vmlinux do_select c01306e0 19 183866 0.0101 97.2625 (no location information) vmlinux _alloc_pages c01219c0 19 183885 0.0101 97.2725 (no location information) vmlinux sys_rt_sigprocmask 080c9414 19 183904 0.0101 97.2826 moduleobject.c:271 python module_traverse 080adb88 19 183923 0.0101 97.2927 pythonrun.c:111 python Py_Initialize 080abfc4 19 183942 0.0101 97.3027 marshal.c:660 python PyMarshal_ReadLongFromFile 080a9be8 19 183961 0.0101 97.3128 import.c:2375 python PyImport_Import 0808d544 19 183980 0.0101 97.3228 unicodeobject.c:6801 python _PyUnicodeUCS2_Fini 08079138 19 183999 0.0101 97.3329 tupleobject.c:785 python tupleiter_next 08073724 19 184018 0.0101 97.3429 stringobject.c:892 python string_concat 0805b01c 19 184037 0.0101 97.3530 classobject.c:485 python PyClass_IsSubclass 0804c8b0 19 184056 0.0101 97.3630 db_insert.c:20 oprofiled odb_insert 000067ac 19 184075 0.0101 97.3731 (no location information) libpthread-0.10.so __pthread_mutex_init 0000bc4e 19 184094 0.0101 97.3831 (no location information) ld-2.3.1.so _dl_important_hwcaps c0140670 18 184112 0.0095 97.3926 (no location information) vmlinux path_release c012c210 18 184130 0.0095 97.4022 (no location information) vmlinux mprotect_fixup 080b0250 18 184148 0.0095 97.4117 sysmodule.c:72 python PySys_SetObject 080786a0 18 184166 0.0095 97.4212 tupleobject.c:238 python tuplehash 0805b77c 18 184184 0.0095 97.4307 classobject.c:745 python instance_getattr 08058194 18 184202 0.0095 97.4402 abstract.c:671 python PyNumber_Multiply 000229a0 18 184220 0.0095 97.4498 (no location information) nvidia.o __nvsym01479 000215a4 18 184238 0.0095 97.4593 (no location information) nvidia.o __nvsym01436 00008d01 18 184256 0.0095 97.4688 (no location information) libpthread-0.10.so __new_sem_wait 00006b42 18 184274 0.0095 97.4783 (no location information) libpthread-0.10.so __pthread_mutexattr_init c012c440 17 184291 0.0090 97.4873 (no location information) vmlinux sys_mprotect c0127f40 17 184308 0.0090 97.4963 (no location information) vmlinux sys_munmap c01123c0 17 184325 0.0090 97.5053 (no location information) vmlinux smp_apic_timer_interrupt c010b7f0 17 184342 0.0090 97.5143 (no location information) vmlinux apic_timer_interrupt 080ca134 17 184359 0.0090 97.5233 structmember.c:55 python PyMember_GetOne 080c7514 17 184376 0.0090 97.5323 frameobject.c:766 python PyFrame_LocalsToFast 080c6b78 17 184393 0.0090 97.5413 frameobject.c:424 python frame_traverse 080a6474 17 184410 0.0090 97.5503 getargs.c:1136 python PyArg_ParseTupleAndKeywords 080a3bec 17 184427 0.0090 97.5593 errors.c:213 python PyErr_Fetch 080a38a0 17 184444 0.0090 97.5683 errors.c:54 python PyErr_SetObject 08083bbc 17 184461 0.0090 97.5772 weakrefobject.c:596 python PyWeakref_NewRef 08081cb8 17 184478 0.0090 97.5862 typeobject.c:5178 python slotdef_cmp 08071358 17 184495 0.0090 97.5952 object.c:1655 python PyCallable_Check 0805b620 17 184512 0.0090 97.6042 classobject.c:690 python instance_getattr1 c015a280 16 184528 0.0085 97.6127 (no location information) vmlinux ext2_release_file c0124360 16 184544 0.0085 97.6212 (no location information) vmlinux __constant_copy_to_user c011acf0 16 184560 0.0085 97.6296 (no location information) vmlinux put_files_struct c0105ae0 16 184576 0.0085 97.6381 (no location information) vmlinux __switch_to 080bfc00 16 184592 0.0085 97.6465 zipimport.c:64 python zipimporter_init 080b54a8 16 184608 0.0085 97.6550 signalmodule.c:559 python finisignal 080afef0 16 184624 0.0085 97.6635 symtable.c:23 python PySymtableEntry_New 0809716c 16 184640 0.0085 97.6719 ceval.c:2746 python set_exc_info 08081cec 16 184656 0.0085 97.6804 typeobject.c:5191 python init_slotdefs 08065d90 16 184672 0.0085 97.6889 listobject.c:457 python list_ass_slice 0805a6bc 16 184688 0.0085 97.6973 classobject.c:160 python class_new 0804a350 16 184704 0.0085 97.7058 opd_proc.c:304 oprofiled opd_lookup_maps 0003aa48 16 184720 0.0085 97.7143 (no location information) nvidia.o __nvsym01888 000175b8 16 184736 0.0085 97.7227 (no location information) nvidia.o __nvsym00655 00009541 16 184752 0.0085 97.7312 (no location information) ld-2.3.1.so _dl_catch_error_internal 00006b04 16 184768 0.0085 97.7396 (no location information) ld-2.3.1.so _dl_setup_hash c0144600 15 184783 0.0079 97.7476 (no location information) vmlinux sys_ioctl c0120170 15 184798 0.0079 97.7555 (no location information) vmlinux update_one_process 00003254 15 184813 0.0079 97.7634 stropmodule.c:1208 strop.so initstrop 080c1f48 15 184828 0.0079 97.7714 parser.c:73 python PyParser_New 080a9584 15 184843 0.0079 97.7793 import.c:2149 python ensure_fromlist 0809a204 15 184858 0.0079 97.7873 compile.c:739 python com_init 08097cac 15 184873 0.0079 97.7952 ceval.c:3235 python PyEval_GetBuiltins 0805ea24 15 184888 0.0079 97.8031 classobject.c:2380 python instancemethod_call 0805bee4 15 184903 0.0079 97.8111 classobject.c:979 python instance_traverse 08054840 15 184918 0.0079 97.8190 main.c:125 python Py_Main 0804a4a8 15 184933 0.0079 97.8269 opd_proc.c:359 oprofiled opd_put_sample 00044894 15 184948 0.0079 97.8349 (no location information) nvidia.o __nvsym01327 0000d660 15 184963 0.0079 97.8428 (no location information) ld-2.3.1.so __mprotect 000082b4 15 184978 0.0079 97.8507 (no location information) ld-2.3.1.so openaux c0122830 14 184992 0.0074 97.8581 (no location information) vmlinux __constant_copy_from_user c01208e0 14 185006 0.0074 97.8655 (no location information) vmlinux run_timer_list c010d440 14 185020 0.0074 97.8729 (no location information) vmlinux __constant_copy_from_user 080c7904 14 185034 0.0074 97.8804 funcobject.c:97 python PyFunction_SetDefaults 080ac8c0 14 185048 0.0074 97.8878 modsupport.c:198 python do_mklist 080a77e4 14 185062 0.0074 97.8952 import.c:562 python PyImport_AddModule 0807ef24 14 185076 0.0074 97.9026 typeobject.c:3869 python add_tp_new_wrapper 0807af7c 14 185090 0.0074 97.9100 typeobject.c:1533 python type_new 08068de4 14 185104 0.0074 97.9174 longobject.c:337 python _PyLong_FromByteArray 08066430 14 185118 0.0074 97.9248 listobject.c:658 python listextend_internal 0805719c 14 185132 0.0074 97.9322 abstract.c:61 python PyObject_Size 00000000 14 185146 0.0074 97.9396 (no location information) libgfx_gtk.so (no symbols) 00127220 14 185160 0.0074 97.9470 (no location information) nvidia.o __nvsym04966 00022a10 14 185174 0.0074 97.9544 (no location information) nvidia.o __nvsym01439 000010e0 14 185188 0.0074 97.9618 (no location information) 8390.o NS8390_trigger_send 00000000 14 185202 0.0074 97.9692 (no location information) libutil-2.3.1.so (no symbols) 00000000 14 185216 0.0074 97.9766 (no location information) libm-2.3.1.so (no symbols) 0000d150 14 185230 0.0074 97.9840 (no location information) ld-2.3.1.so __read 0000a830 14 185244 0.0074 97.9914 (no location information) ld-2.3.1.so find_needed c012c140 13 185257 0.0069 97.9983 (no location information) vmlinux change_protection c010af78 13 185270 0.0069 98.0052 (no location information) vmlinux IRQ0x0b_interrupt 080c7204 13 185283 0.0069 98.0121 frameobject.c:664 python PyFrame_BlockPop 080c5938 13 185296 0.0069 98.0189 descrobject.c:649 python PyDescr_NewWrapper 080b9184 13 185309 0.0069 98.0258 posixmodule.c:7404 python initposix 080a7030 13 185322 0.0069 98.0327 import.c:267 python unlock_import 08090c84 13 185335 0.0069 98.0396 bltinmodule.c:2080 python _PyBuiltin_Init 0808f678 13 185348 0.0069 98.0465 bltinmodule.c:1068 python builtin_len 0807871c 13 185361 0.0069 98.0533 tupleobject.c:258 python tuplelength 08073dec 13 185374 0.0069 98.0602 stringobject.c:1163 python string_subscript 0806f4e4 13 185387 0.0069 98.0671 object.c:155 python PyObject_Init 08058b08 13 185400 0.0069 98.0740 abstract.c:1067 python PySequence_Size 08058ae0 13 185413 0.0069 98.0808 abstract.c:1060 python PySequence_Check 080553fc 13 185426 0.0069 98.0877 tokenizer.c:106 python tok_new 000e07f0 13 185439 0.0069 98.0946 (no location information) nvidia.o __nvsym00544 000db9d8 13 185452 0.0069 98.1015 (no location information) nvidia.o __nvsym03991 0001754c 13 185465 0.0069 98.1083 (no location information) nvidia.o __nvsym00731 0000dfc4 13 185478 0.0069 98.1152 (no location information) ld-2.3.1.so memcpy 0000286c 13 185491 0.0069 98.1221 (no location information) ld-2.3.1.so process_envvars 00001176 13 185504 0.0069 98.1290 (no location information) ld-2.3.1.so startup_error_tsd c0149be0 12 185516 0.0063 98.1353 (no location information) vmlinux __d_path c0127c10 12 185528 0.0063 98.1417 (no location information) vmlinux free_pgtables 080c96ec 12 185540 0.0063 98.1480 rangeobject.c:250 python rangeiter_next 080c1c74 12 185552 0.0063 98.1544 grammar1.c:13 python PyGrammar_FindDFA 080b2618 12 185564 0.0063 98.1607 getpath.c:131 python reduce 080b191c 12 185576 0.0063 98.1671 traceback.c:107 python newtracebackobject 080b00f4 12 185588 0.0063 98.1734 symtable.c:115 python ste_dealloc 0809ac4c 12 185600 0.0063 98.1798 compile.c:1092 python com_addop_varname 0809a90c 12 185612 0.0063 98.1861 compile.c:968 python com_add 0808ee78 12 185624 0.0063 98.1925 bltinmodule.c:687 python builtin_hasattr 0808d4c8 12 185636 0.0063 98.1988 unicodeobject.c:6783 python _PyUnicodeUCS2_Init 08071014 12 185648 0.0063 98.2052 object.c:1476 python PyObject_GenericSetAttr 0806de10 12 185660 0.0063 98.2115 dictobject.c:912 python dict_values 0806a680 12 185672 0.0063 98.2178 longobject.c:1490 python long_dealloc 0806689c 12 185684 0.0063 98.2242 listobject.c:922 python count_run 000073cd 12 185696 0.0063 98.2305 (no location information) libpthread-0.10.so pthread_initialize 0000cf18 12 185708 0.0063 98.2369 (no location information) ld-2.3.1.so ___fxstat64 c01594f0 11 185719 0.0058 98.2427 (no location information) vmlinux ext2_readdir c0120dd0 11 185730 0.0058 98.2485 (no location information) vmlinux collect_signal c0120c70 11 185741 0.0058 98.2543 (no location information) vmlinux flush_signal_handlers c011ec20 11 185752 0.0058 98.2602 (no location information) vmlinux sysctl_string c010739f 11 185763 0.0058 98.2660 (no location information) vmlinux ret_from_exception 080c25ac 11 185774 0.0058 98.2718 boolobject.c:37 python PyBool_FromLong 080ad220 11 185785 0.0058 98.2776 pystate.c:75 python PyInterpreterState_Clear 080a7b00 11 185796 0.0058 98.2834 import.c:706 python read_compiled_module 080a1018 11 185807 0.0058 98.2893 compile.c:4882 python symtable_init 080825c8 11 185818 0.0058 98.2951 weakrefobject.c:24 python new_weakref 08070a84 11 185829 0.0058 98.3009 object.c:1201 python PyObject_SetAttrString 08064c4c 11 185840 0.0058 98.3067 intobject.c:1078 python _PyInt_Init 08063e3c 11 185851 0.0058 98.3125 intobject.c:453 python int_mul 08059a1c 11 185862 0.0058 98.3184 abstract.c:1806 python PyObject_CallMethod 08058dc0 11 185873 0.0058 98.3242 abstract.c:1199 python PySequence_GetSlice 00000000 11 185884 0.0058 98.3300 (no location information) libgkview.so (no symbols) 00003380 11 185895 0.0058 98.3358 (no location information) oprofile.o oprof_output_map 000016a0 11 185906 0.0058 98.3416 (no location information) oprofile.o __constant_memcpy 000008f0 11 185917 0.0058 98.3474 (no location information) 8390.o ei_receive 00009324 11 185928 0.0058 98.3533 (no location information) libpthread-0.10.so thread_self 00009688 11 185939 0.0058 98.3591 (no location information) ld-2.3.1.so call_init c014b210 10 185949 0.0053 98.3644 (no location information) vmlinux iput c014ada0 10 185959 0.0053 98.3697 (no location information) vmlinux find_inode 080c9fcc 10 185969 0.0053 98.3750 getmtime.c:11 python PyOS_GetLastModificationTime 080c9e24 10 185979 0.0053 98.3802 structseq.c:347 python PyStructSequence_InitType 080c9160 10 185989 0.0053 98.3855 moduleobject.c:173 python module_dealloc 080c71b8 10 185999 0.0053 98.3908 frameobject.c:652 python PyFrame_BlockSetup 080b2768 10 186009 0.0053 98.3961 getpath.c:200 python joinpath 080b19ac 10 186019 0.0053 98.4014 traceback.c:130 python PyTraceBack_Here 080adb48 10 186029 0.0053 98.4067 pythonrun.c:82 python Py_IsInitialized 080abfdc 10 186039 0.0053 98.4120 marshal.c:670 python getfilesize 080a39e8 10 186049 0.0053 98.4173 errors.c:117 python PyErr_ExceptionMatches 0809a674 10 186059 0.0053 98.4226 compile.c:852 python com_addbyte 08091a2c 10 186069 0.0053 98.4279 exceptions.c:252 python Exception__init__ 0807879c 10 186079 0.0053 98.4331 tupleobject.c:286 python tupleslice 08064ffc 10 186089 0.0053 98.4384 iterobject.c:48 python iter_iternext 08059eac 10 186099 0.0053 98.4437 abstract.c:2040 python PyObject_IsInstance 00126b44 10 186109 0.0053 98.4490 (no location information) nvidia.o __nvsym04955 000f2870 10 186119 0.0053 98.4543 (no location information) nvidia.o __nvsym04336 00044808 10 186129 0.0053 98.4596 (no location information) nvidia.o __nvsym01609 0003dc54 10 186139 0.0053 98.4649 (no location information) nvidia.o __nvsym01494 000216e0 10 186149 0.0053 98.4702 (no location information) nvidia.o __nvsym01442 00008ea6 10 186159 0.0053 98.4755 (no location information) libpthread-0.10.so __new_sem_trywait 00009779 10 186169 0.0053 98.4808 (no location information) ld-2.3.1.so _dl_init_internal 000081ba 10 186179 0.0053 98.4860 (no location information) ld-2.3.1.so elf_machine_runtime_setup 000035e9 10 186189 0.0053 98.4913 (no location information) ld-2.3.1.so _dl_init_paths c0232180 9 186198 0.0048 98.4961 (no location information) vmlinux unix_poll c014fea0 9 186207 0.0048 98.5009 (no location information) vmlinux load_elf_interp c0145620 9 186216 0.0048 98.5056 (no location information) vmlinux sys_select c01313d0 9 186225 0.0048 98.5104 (no location information) vmlinux swap_info_put c0120380 9 186234 0.0048 98.5151 (no location information) vmlinux timer_bh c011cc50 9 186243 0.0048 98.5199 (no location information) vmlinux __tasklet_hi_schedule c011b370 9 186252 0.0048 98.5247 (no location information) vmlinux do_exit c0116050 9 186261 0.0048 98.5294 (no location information) vmlinux try_to_wake_up 080c8cac 9 186270 0.0048 98.5342 methodobject.c:354 python PyCFunction_Fini 080c832c 9 186279 0.0048 98.5389 funcobject.c:520 python func_descr_get 080b5770 9 186288 0.0048 98.5437 posixmodule.c:319 python convertenviron 080b22e4 9 186297 0.0048 98.5485 thread_pthread.h:342 python PyThread_allocate_lock 080af670 9 186306 0.0048 98.5532 pythonrun.c:1130 python PyRun_StringFlags 080a8fc4 9 186315 0.0048 98.5580 import.c:1922 python PyImport_ImportModule 080a8cd4 9 186324 0.0048 98.5627 import.c:1785 python init_builtin 080a8a60 9 186333 0.0048 98.5675 import.c:1430 python case_ok 080a7684 9 186342 0.0048 98.5723 import.c:505 python _PyImport_FixupExtension 080a26ac 9 186351 0.0048 98.5770 codecs.c:54 python normalizestring 080a164c 9 186360 0.0048 98.5818 compile.c:5163 python symtable_add_def_o 080a1098 9 186369 0.0048 98.5866 compile.c:4908 python PySymtable_Free 080a0a3c 9 186378 0.0048 98.5913 compile.c:4647 python symtable_freevar_offsets 080a059c 9 186387 0.0048 98.5961 compile.c:4471 python symtable_build 0809fd28 9 186396 0.0048 98.6008 compile.c:4164 python compile_node 0809d5f8 9 186405 0.0048 98.6056 compile.c:2569 python com_list 08098568 9 186414 0.0048 98.6104 ceval.c:3655 python ext_do_call 080752c8 9 186423 0.0048 98.6151 stringobject.c:2052 python string_translate 0807097c 9 186432 0.0048 98.6199 object.c:1137 python _Py_HashPointer 0806f8a4 9 186441 0.0048 98.6246 object.c:327 python PyObject_Str 080687b0 9 186450 0.0048 98.6294 listobject.c:2426 python listiter_dealloc 08060d88 9 186459 0.0048 98.6342 fileobject.c:1855 python file_new 08054f88 9 186468 0.0048 98.6389 parsetok.c:30 python PyParser_ParseStringFlags 000004c0 9 186477 0.0048 98.6437 (no location information) oprofile.o do_path_hash_2_4 000004b0 9 186486 0.0048 98.6484 (no location information) 8390.o ei_interrupt_Rb93d8fa5 00006b55 9 186495 0.0048 98.6532 (no location information) libpthread-0.10.so __pthread_mutexattr_destroy 0000c1f6 9 186504 0.0048 98.6580 (no location information) ld-2.3.1.so malloc 00007c24 9 186513 0.0048 98.6627 (no location information) ld-2.3.1.so elf_dynamic_do_rela.8 00000c09 9 186522 0.0048 98.6675 (no location information) ld-2.3.1.so elf_dynamic_do_rel.4 c02377f0 8 186530 0.0042 98.6717 (no location information) vmlinux __rb_erase_color c0144090 8 186538 0.0042 98.6759 (no location information) vmlinux sys_fcntl64 c013e900 8 186546 0.0042 98.6802 (no location information) vmlinux flush_old_exec c013e540 8 186554 0.0042 98.6844 (no location information) vmlinux setup_arg_pages c013e1e0 8 186562 0.0042 98.6886 (no location information) vmlinux count c01161c0 8 186570 0.0042 98.6929 (no location information) vmlinux add_wait_queue c01151a0 8 186578 0.0042 98.6971 (no location information) vmlinux __wake_up c0108a00 8 186586 0.0042 98.7013 (no location information) vmlinux do_IRQ 080c1e58 8 186594 0.0042 98.7056 node.c:117 python PyNode_Free 080c1cfc 8 186602 0.0042 98.7098 node.c:9 python PyNode_New 080bec74 8 186610 0.0042 98.7140 _sre.c:3124 python init_sre 080b23a4 8 186618 0.0042 98.7183 thread_pthread.h:397 python PyThread_acquire_lock 080b1e60 8 186626 0.0042 98.7225 getopt.c:35 python _PyOS_GetOpt 080afe74 8 186634 0.0042 98.7267 pythonrun.c:1571 python PyOS_getsig 080a1478 8 186642 0.0042 98.7310 compile.c:5088 python symtable_enter_scope 0809f4a0 8 186650 0.0042 98.7352 compile.c:3817 python com_node 0809bc20 8 186658 0.0042 98.7394 compile.c:1628 python com_atom 0809a3bc 8 186666 0.0042 98.7437 compile.c:793 python com_free 08093b54 8 186674 0.0042 98.7479 exceptions.c:1823 python _PyExc_Fini 080918f8 8 186682 0.0042 98.7521 exceptions.c:176 python make_class 080917e8 8 186690 0.0042 98.7564 exceptions.c:128 python populate_methods 08083b34 8 186698 0.0042 98.7606 weakrefobject.c:551 python get_basic_refs 0807bc8c 8 186706 0.0042 98.7648 typeobject.c:1941 python _PyType_Lookup 08070a40 8 186714 0.0042 98.7691 object.c:1189 python PyObject_HasAttrString 0806fc3c 8 186722 0.0042 98.7733 object.c:482 python try_rich_compare 0805b84c 8 186730 0.0042 98.7775 classobject.c:785 python instance_setattr1 080558a8 8 186738 0.0042 98.7817 tokenizer.c:303 python check_bom 00000000 8 186746 0.0042 98.7860 (no location information) less (no symbols) 000008f0 8 186754 0.0042 98.7902 (no location information) oprofile.o __oprof_put_note 00126d98 8 186762 0.0042 98.7944 (no location information) nvidia.o __nvsym04964 000216a0 8 186770 0.0042 98.7987 (no location information) nvidia.o __nvsym01476 000181d0 8 186778 0.0042 98.8029 (no location information) nvidia.o rm_isr 000016c2 8 186786 0.0042 98.8071 (no location information) nvidia.o nv_kern_isr 00000610 8 186794 0.0042 98.8114 (no location information) ne2k-pci.o ne2k_pci_block_input 00000d19 8 186802 0.0042 98.8156 (no location information) ld-2.3.1.so _dl_start 00000b45 8 186810 0.0042 98.8198 (no location information) ld-2.3.1.so _dl_start_final c0155ea0 7 186817 0.0037 98.8235 (no location information) vmlinux meminfo_read_proc c013e420 7 186824 0.0037 98.8272 (no location information) vmlinux copy_strings_kernel c0136100 7 186831 0.0037 98.8309 (no location information) vmlinux generic_file_open c0120f90 7 186838 0.0037 98.8346 (no location information) vmlinux rm_from_queue c011d750 7 186845 0.0037 98.8383 (no location information) vmlinux parse_table c011cb00 7 186852 0.0037 98.8421 (no location information) vmlinux do_softirq 080c3190 7 186859 0.0037 98.8458 cobject.c:21 python PyCObject_FromVoidPtr 080bcfa0 7 186866 0.0037 98.8495 _sre.c:1796 python pattern_dealloc 080b3b2c 7 186873 0.0037 98.8532 gcmodule.c:664 python collect_generations 080b3640 7 186880 0.0037 98.8569 gcmodule.c:425 python move_finalizer_reachable 080b358c 7 186887 0.0037 98.8606 gcmodule.c:387 python move_finalizers 080b0b24 7 186894 0.0037 98.8643 sysmodule.c:781 python PySys_ResetWarnOptions 080b0a50 7 186901 0.0037 98.8680 sysmodule.c:752 python list_builtin_module_names 080af9b8 7 186908 0.0037 98.8717 pythonrun.c:1271 python PyParser_SimpleParseStringFlags 080ac774 7 186915 0.0037 98.8754 modsupport.c:156 python do_mkdict 080a9788 7 186922 0.0037 98.8791 import.c:2217 python add_submodule 080a7edc 7 186929 0.0037 98.8828 import.c:912 python load_package 080a7a50 7 186936 0.0037 98.8865 import.c:674 python check_compiled_module 080a7754 7 186943 0.0037 98.8902 import.c:532 python _PyImport_FindExtension 080a3c28 7 186950 0.0037 98.8939 errors.c:227 python PyErr_Clear 080a2740 7 186957 0.0037 98.8976 codecs.c:96 python _PyCodec_Lookup 0809d464 7 186964 0.0037 98.9013 compile.c:2525 python com_test 0807cf78 7 186971 0.0037 98.9050 typeobject.c:2794 python add_members 080790c0 7 186978 0.0037 98.9087 tupleobject.c:769 python tupleiter_dealloc 080738a8 7 186985 0.0037 98.9124 stringobject.c:934 python string_repeat 080719f4 7 186992 0.0037 98.9161 object.c:2112 python PyMem_Free 080718b0 7 186999 0.0037 98.9198 object.c:1962 python _Py_ReadyTypes 080712a8 7 187006 0.0037 98.9235 object.c:1609 python PyNumber_CoerceEx 080705ac 7 187013 0.0037 98.9272 object.c:956 python do_richcmp 08068b70 7 187020 0.0037 98.9309 longobject.c:188 python PyLong_AsLong 08064a04 7 187027 0.0037 98.9346 intobject.c:904 python int_new 0805b0f0 7 187034 0.0037 98.9383 classobject.c:514 python PyInstance_NewRaw 080584b8 7 187041 0.0037 98.9420 abstract.c:794 python PyNumber_InPlaceAdd 080580ec 7 187048 0.0037 98.9457 abstract.c:627 python sequence_repeat 08055dec 7 187055 0.0037 98.9494 tokenizer.c:555 python decode_str 080556a0 7 187062 0.0037 98.9531 tokenizer.c:209 python get_coding_spec 0804a2e8 7 187069 0.0037 98.9568 opd_proc.c:274 oprofiled opd_put_image_sample 00000000 7 187076 0.0037 98.9605 (no location information) libgkgfx.so (no symbols) 00003bb0 7 187083 0.0037 98.9642 (no location information) oprofile.o __constant_copy_from_user 00125f60 7 187090 0.0037 98.9679 (no location information) nvidia.o __nvsym01671 000dbb2c 7 187097 0.0037 98.9717 (no location information) nvidia.o __nvsym04010 0003e114 7 187104 0.0037 98.9754 (no location information) nvidia.o __nvsym01871 0003020c 7 187111 0.0037 98.9791 (no location information) nvidia.o __nvsym01719 000217a0 7 187118 0.0037 98.9828 (no location information) nvidia.o __nvsym01481 0000b86c 7 187125 0.0037 98.9865 (no location information) libpthread-0.10.so __do_global_ctors_aux 00008c2c 7 187132 0.0037 98.9902 (no location information) libpthread-0.10.so __new_sem_init 00000000 7 187139 0.0037 98.9939 (no location information) libncurses.so.5.3 (no symbols) 0000d0d0 7 187146 0.0037 98.9976 (no location information) ld-2.3.1.so __open 0000a7ce 7 187153 0.0037 99.0013 (no location information) ld-2.3.1.so _dl_check_all_versions c0237680 6 187159 0.0032 99.0044 (no location information) vmlinux __rb_rotate_left c0235eac 6 187165 0.0032 99.0076 (no location information) vmlinux __get_user_4 c018f940 6 187171 0.0032 99.0108 (no location information) vmlinux __constant_copy_to_user c018f3f0 6 187177 0.0032 99.0140 (no location information) vmlinux n_tty_ioctl c014a1c0 6 187183 0.0032 99.0171 (no location information) vmlinux alloc_inode c0144eb0 6 187189 0.0032 99.0203 (no location information) vmlinux filldir64 c01325e0 6 187195 0.0032 99.0235 (no location information) vmlinux si_swapinfo c012be90 6 187201 0.0032 99.0267 (no location information) vmlinux __read_cache_page c0120280 6 187207 0.0032 99.0298 (no location information) vmlinux update_process_times c0120130 6 187213 0.0032 99.0330 (no location information) vmlinux update_wall_time c0113b00 6 187219 0.0032 99.0362 (no location information) vmlinux do_check_pgt_cache c01068c0 6 187225 0.0032 99.0394 (no location information) vmlinux setup_frame 00000000 6 187231 0.0032 99.0425 (no location information) sshd (no symbols) 000033a8 6 187237 0.0032 99.0457 (no location information) strop.so __do_global_ctors_aux 0000118c 6 187243 0.0032 99.0489 (no location information) strop.so __do_global_dtors_aux 080c8348 6 187249 0.0032 99.0521 funcobject.c:595 python cm_dealloc 080c194c 6 187255 0.0032 99.0552 acceler.c:25 python PyGrammar_AddAccelerators 080b8c38 6 187261 0.0032 99.0584 posixmodule.c:7184 python all_ins 080a4fcc 6 187267 0.0032 99.0616 getargs.c:270 python seterror 0809fee8 6 187273 0.0032 99.0648 compile.c:4240 python PyNode_CompileFlags 0809d2bc 6 187279 0.0032 99.0679 compile.c:2464 python com_and_test 0809ceb4 6 187285 0.0032 99.0711 compile.c:2300 python com_xor_expr 0809a5b0 6 187291 0.0032 99.0743 compile.c:811 python com_push 08091e7c 6 187297 0.0032 99.0774 exceptions.c:470 python EnvironmentError__init__ 0808f6bc 6 187303 0.0032 99.0806 bltinmodule.c:1101 python min_max 0808e998 6 187309 0.0032 99.0838 bltinmodule.c:460 python builtin_eval 08084098 6 187315 0.0032 99.0870 unicodeobject.c:175 python _PyUnicode_New 0807e7a4 6 187321 0.0032 99.0901 typeobject.c:3537 python wrap_delslice 0807a508 6 187327 0.0032 99.0933 typeobject.c:1046 python check_duplicates 08078a2c 6 187333 0.0032 99.0965 tupleobject.c:409 python tuplerichcompare 08073718 6 187339 0.0032 99.0997 stringobject.c:886 python string_length 08071b94 6 187345 0.0032 99.1028 obmalloc.c:427 python new_arena 0806f388 6 187351 0.0032 99.1060 dictobject.c:1983 python PyDict_DelItemString 08068938 6 187357 0.0032 99.1092 longobject.c:86 python PyLong_FromLong 08066618 6 187363 0.0032 99.1124 listobject.c:743 python listpop 08065a68 6 187369 0.0032 99.1155 listobject.c:317 python list_length 080648cc 6 187375 0.0032 99.1187 intobject.c:838 python int_coerce 0806458c 6 187381 0.0032 99.1219 intobject.c:746 python int_nonzero 0805f0b0 6 187387 0.0032 99.1251 fileobject.c:336 python file_dealloc 080594a0 6 187393 0.0032 99.1282 abstract.c:1502 python PySequence_Fast 080570bc 6 187399 0.0032 99.1314 tokenizer.c:1413 python PyTokenizer_Get 08055eec 6 187405 0.0032 99.1346 tokenizer.c:603 python PyTokenizer_FromString 080557cc 6 187411 0.0032 99.1378 tokenizer.c:257 python check_coding_spec 08054fa8 6 187417 0.0032 99.1409 parsetok.c:39 python PyParser_ParseStringFlagsFilename 00003490 6 187423 0.0032 99.1441 (no location information) oprofile.o my_sys_execve 001266e8 6 187429 0.0032 99.1473 (no location information) nvidia.o __nvsym04965 0003aa98 6 187435 0.0032 99.1504 (no location information) nvidia.o __nvsym02417 00000550 6 187441 0.0032 99.1536 (no location information) ne2k-pci.o ne2k_pci_get_8390_hdr 00006c17 6 187447 0.0032 99.1568 (no location information) libpthread-0.10.so __pthread_once 0000c218 6 187453 0.0032 99.1600 (no location information) ld-2.3.1.so calloc 00009c5c 6 187459 0.0032 99.1631 (no location information) ld-2.3.1.so _dl_sysdep_read_whole_file c02362f0 5 187464 0.0026 99.1658 (no location information) vmlinux mmx_copy_page c02102a0 5 187469 0.0026 99.1684 (no location information) vmlinux tcp_transmit_skb c0204800 5 187474 0.0026 99.1711 (no location information) vmlinux tcp_poll c018e390 5 187479 0.0026 99.1737 (no location information) vmlinux normal_poll c0186b00 5 187484 0.0026 99.1764 (no location information) vmlinux sem_exit c0155060 5 187489 0.0026 99.1790 (no location information) vmlinux proc_pid_maps_get_line c014bba0 5 187494 0.0026 99.1817 (no location information) vmlinux expand_fd_array c014ae60 5 187499 0.0026 99.1843 (no location information) vmlinux get_new_inode c0149d40 5 187504 0.0026 99.1869 (no location information) vmlinux sys_getcwd c013f570 5 187509 0.0026 99.1896 (no location information) vmlinux __constant_c_and_count_memset c013eff0 5 187514 0.0026 99.1922 (no location information) vmlinux do_execve c013ee70 5 187519 0.0026 99.1949 (no location information) vmlinux search_binary_handler c013ec80 5 187524 0.0026 99.1975 (no location information) vmlinux compute_creds c013e470 5 187529 0.0026 99.2002 (no location information) vmlinux put_dirty_page c013dbd0 5 187534 0.0026 99.2028 (no location information) vmlinux sys_readlink c0126f30 5 187539 0.0026 99.2055 (no location information) vmlinux unlock_vma_mappings c01225b0 5 187544 0.0026 99.2081 (no location information) vmlinux __constant_memcpy c0120450 5 187549 0.0026 99.2108 (no location information) vmlinux do_timer c0120080 5 187554 0.0026 99.2134 (no location information) vmlinux update_wall_time_one_tick c011cd10 5 187559 0.0026 99.2160 (no location information) vmlinux tasklet_hi_action c011ba10 5 187564 0.0026 99.2187 (no location information) vmlinux unhash_process c0117350 5 187569 0.0026 99.2213 (no location information) vmlinux __constant_c_and_count_memset c0117250 5 187574 0.0026 99.2240 (no location information) vmlinux __constant_memcpy c0116570 5 187579 0.0026 99.2266 (no location information) vmlinux mm_release c01164d0 5 187584 0.0026 99.2293 (no location information) vmlinux mmput c0116260 5 187589 0.0026 99.2319 (no location information) vmlinux get_pid c010b860 5 187594 0.0026 99.2346 (no location information) vmlinux end_8259A_irq c0106ea0 5 187599 0.0026 99.2372 (no location information) vmlinux do_signal c0105d60 5 187604 0.0026 99.2398 (no location information) vmlinux __constant_memcpy 080c9394 5 187609 0.0026 99.2425 moduleobject.c:250 python module_setattr 080c58e8 5 187614 0.0026 99.2451 descrobject.c:625 python PyDescr_NewMember 080c5898 5 187619 0.0026 99.2478 descrobject.c:601 python PyDescr_NewMethod 080c530c 5 187624 0.0026 99.2504 descrobject.c:140 python getset_get 080c1efc 5 187629 0.0026 99.2531 parser.c:39 python s_push 080b5c88 5 187634 0.0026 99.2557 posixmodule.c:915 python posix_do_stat 080b3714 5 187639 0.0026 99.2584 gcmodule.c:474 python handle_finalizers 080b1f70 5 187644 0.0026 99.2610 dynload_shlib.c:71 python _PyImport_GetDynLoadFunc 080b17d0 5 187649 0.0026 99.2637 traceback.c:37 python tb_dealloc 080b1464 5 187654 0.0026 99.2663 sysmodule.c:1141 python PySys_SetArgv 080b13d4 5 187659 0.0026 99.2689 sysmodule.c:1100 python makeargvobject 080b0c20 5 187664 0.0026 99.2716 sysmodule.c:901 python _PySys_Init 080afdcc 5 187669 0.0026 99.2742 pythonrun.c:1488 python initsigs 080af774 5 187674 0.0026 99.2769 pythonrun.c:1167 python run_node 080ae1c8 5 187679 0.0026 99.2795 pythonrun.c:463 python Py_SetProgramName 080aa708 5 187684 0.0026 99.2822 importdl.c:23 python _PyImport_LoadDynamicModule 080a4958 5 187689 0.0026 99.2848 future.c:244 python PyNode_Future 080a3674 5 187694 0.0026 99.2875 codecs.c:737 python _PyCodecRegistry_Init 080a2dc8 5 187699 0.0026 99.2901 codecs.c:397 python PyCodec_RegisterError 080a263c 5 187704 0.0026 99.2927 codecs.c:30 python PyCodec_Register 0809a604 5 187709 0.0026 99.2954 compile.c:834 python com_done 0809888c 5 187714 0.0026 99.2980 ceval.c:3798 python apply_slice 08097cf4 5 187719 0.0026 99.3007 ceval.c:3255 python PyEval_GetGlobals 08091c00 5 187724 0.0026 99.3033 exceptions.c:344 python make_Exception 080919f0 5 187729 0.0026 99.3060 exceptions.c:216 python get_self 0808d334 5 187734 0.0026 99.3086 unicodeobject.c:6679 python unicode_new 0807ff74 5 187739 0.0026 99.3113 typeobject.c:4181 python slot_nb_nonzero 0807e2e4 5 187744 0.0026 99.3139 typeobject.c:3325 python wrap_binaryfunc_l 0807d008 5 187749 0.0026 99.3166 typeobject.c:2813 python add_getset 0807c158 5 187754 0.0026 99.3192 typeobject.c:2259 python object_init 0807a458 5 187759 0.0026 99.3218 typeobject.c:1015 python tail_contains 08079c6c 5 187764 0.0026 99.3245 typeobject.c:470 python PyType_GenericNew 08078ba8 5 187769 0.0026 99.3271 tupleobject.c:485 python tuple_new 08074788 5 187774 0.0026 99.3298 stringobject.c:1533 python string_adjust_indices 08073a14 5 187779 0.0026 99.3324 stringobject.c:992 python string_slice 08070504 5 187784 0.0026 99.3351 object.c:914 python convert_3way_to_object 0806fe68 5 187789 0.0026 99.3377 object.c:577 python try_3way_compare 0806f9b0 5 187794 0.0026 99.3404 object.c:366 python PyObject_Unicode 080645b4 5 187799 0.0026 99.3430 intobject.c:758 python int_lshift 08063cc4 5 187804 0.0026 99.3456 intobject.c:387 python int_hash 0805f044 5 187809 0.0026 99.3483 fileobject.c:313 python PyFile_SetEncoding 0805ef44 5 187814 0.0026 99.3509 fileobject.c:254 python PyFile_FromFile 08059728 5 187819 0.0026 99.3536 abstract.c:1652 python PyMapping_Size 080587bc 5 187824 0.0026 99.3562 abstract.c:943 python PyNumber_Int 080553c4 5 187829 0.0026 99.3589 parsetok.c:214 python initerr 0804a26c 5 187834 0.0026 99.3615 opd_proc.c:227 oprofiled opd_get_proc 0003e094 5 187839 0.0026 99.3642 (no location information) nvidia.o __nvsym01553 0003dd84 5 187844 0.0026 99.3668 (no location information) nvidia.o __nvsym02273 0002dfc4 5 187849 0.0026 99.3694 (no location information) nvidia.o __nvsym01711 0002232c 5 187854 0.0026 99.3721 (no location information) nvidia.o __nvsym01482 000222a8 5 187859 0.0026 99.3747 (no location information) nvidia.o __nvsym01427 000001d0 5 187864 0.0026 99.3774 (no location information) 8390.o ei_start_xmit 0000a623 5 187869 0.0026 99.3800 (no location information) libpthread-0.10.so pthread_rwlock_rdlock 00006f89 5 187874 0.0026 99.3827 (no location information) libpthread-0.10.so __pthread_atfork 00005301 5 187879 0.0026 99.3853 (no location information) libpthread-0.10.so pthread_cond_broadcast 0000df48 5 187884 0.0026 99.3880 (no location information) ld-2.3.1.so mempcpy c02376c0 4 187888 0.0021 99.3901 (no location information) vmlinux __rb_rotate_right c02367e0 4 187892 0.0021 99.3922 (no location information) vmlinux skip_atoi c0231c20 4 187896 0.0021 99.3943 (no location information) vmlinux unix_stream_recvmsg c01e00b0 4 187900 0.0021 99.3964 (no location information) vmlinux rh_send_irq c01a8670 4 187904 0.0021 99.3985 (no location information) vmlinux ide_inb c0155240 4 187908 0.0021 99.4007 (no location information) vmlinux proc_pid_read_maps c01522c0 4 187912 0.0021 99.4028 (no location information) vmlinux proc_root_lookup c014fbb0 4 187916 0.0021 99.4049 (no location information) vmlinux create_elf_tables c014fb40 4 187920 0.0021 99.4070 (no location information) vmlinux set_brk c01495c0 4 187924 0.0021 99.4091 (no location information) vmlinux d_alloc c0143e00 4 187928 0.0021 99.4112 (no location information) vmlinux do_fcntl c013fc60 4 187932 0.0021 99.4134 (no location information) vmlinux pipe_poll c013e7f0 4 187936 0.0021 99.4155 (no location information) vmlinux exec_mmap c012eaf0 4 187940 0.0021 99.4176 (no location information) vmlinux kfree c0128340 4 187944 0.0021 99.4197 (no location information) vmlinux __insert_vm_struct c01226b0 4 187948 0.0021 99.4218 (no location information) vmlinux sigorsets c0120ec0 4 187952 0.0021 99.4239 (no location information) vmlinux dequeue_signal c0120530 4 187956 0.0021 99.4261 (no location information) vmlinux sys_getpid c011ce20 4 187960 0.0021 99.4282 (no location information) vmlinux bh_action c011b5f0 4 187964 0.0021 99.4303 (no location information) vmlinux sys_exit c010d870 4 187968 0.0021 99.4324 (no location information) vmlinux save_i387 c010c7c0 4 187972 0.0021 99.4345 (no location information) vmlinux do_gettimeofday c0108870 4 187976 0.0021 99.4366 (no location information) vmlinux handle_IRQ_event c0106790 4 187980 0.0021 99.4387 (no location information) vmlinux setup_sigcontext c0106440 4 187984 0.0021 99.4409 (no location information) vmlinux restore_sigcontext 000033dc 4 187988 0.0021 99.4430 (no location information) strop.so _fini 080ca644 4 187992 0.0021 99.4451 (no location information) python __do_global_ctors_aux 080c9754 4 187996 0.0021 99.4472 structseq.c:42 python structseq_dealloc 080c930c 4 188000 0.0021 99.4493 moduleobject.c:230 python shadows_builtin 080c7a78 4 188004 0.0021 99.4514 funcobject.c:168 python restricted 080c723c 4 188008 0.0021 99.4536 frameobject.c:677 python map_to_dict 080bfe04 4 188012 0.0021 99.4557 zipimport.c:184 python zipimporter_dealloc 080bc8c0 4 188016 0.0021 99.4578 _sre.c:1434 python _compile 080b32fc 4 188020 0.0021 99.4599 gcmodule.c:138 python gc_list_is_empty 080b32ec 4 188024 0.0021 99.4620 gcmodule.c:131 python gc_list_init 080b286c 4 188028 0.0021 99.4641 getpath.c:248 python search_for_prefix 080afdf0 4 188032 0.0021 99.4663 pythonrun.c:1524 python Py_FdIsInteractive 080af75c 4 188036 0.0021 99.4684 pythonrun.c:1158 python run_err_node 080adf14 4 188040 0.0021 99.4705 pythonrun.c:238 python Py_Finalize 080ad50c 4 188044 0.0021 99.4726 pystate.c:176 python PyThreadState_Clear 080a6c40 4 188048 0.0021 99.4747 import.c:112 python _PyImport_Init 080a6c08 4 188052 0.0021 99.4768 getversion.c:10 python Py_GetVersion 080a475c 4 188056 0.0021 99.4789 future.c:93 python future_parse 080a2e30 4 188060 0.0021 99.4811 codecs.c:413 python PyCodec_LookupError 080a157c 4 188064 0.0021 99.4832 compile.c:5136 python symtable_add_def 0809eeec 4 188068 0.0021 99.4853 compile.c:3598 python get_docstring 0809dc14 4 188072 0.0021 99.4874 compile.c:2843 python com_expr_stmt 0809cf58 4 188076 0.0021 99.4895 compile.c:2322 python com_expr 0809cd64 4 188080 0.0021 99.4916 compile.c:2252 python com_shift_expr 0809a738 4 188084 0.0021 99.4938 compile.c:888 python com_set_lineno 0809875c 4 188088 0.0021 99.4959 ceval.c:3736 python _PyEval_SliceIndex 08093f7c 4 188092 0.0021 99.4980 ceval.c:368 python PyEval_SaveThread 08093c38 4 188096 0.0021 99.5001 ceval.c:163 python gen_new 0808ee68 4 188100 0.0021 99.5022 bltinmodule.c:671 python builtin_globals 0808e228 4 188104 0.0021 99.5043 bltinmodule.c:123 python builtin_callable 08083b9c 4 188108 0.0021 99.5065 weakrefobject.c:583 python insert_head 08074abc 4 188112 0.0021 99.5086 stringobject.c:1672 python do_xstrip 08073324 4 188116 0.0021 99.5107 stringobject.c:713 python PyString_AsStringAndSize 08070558 4 188120 0.0021 99.5128 object.c:937 python try_3way_to_rich_compare 0806e6b0 4 188124 0.0021 99.5149 dictobject.c:1256 python PyDict_Size 0806de9c 4 188128 0.0021 99.5170 dictobject.c:941 python dict_items 0806dcec 4 188132 0.0021 99.5192 dictobject.c:848 python dict_subscript 0806dce0 4 188136 0.0021 99.5213 dictobject.c:842 python dict_length 0806ca74 4 188140 0.0021 99.5234 longobject.c:2679 python long_coerce 08069368 4 188144 0.0021 99.5255 longobject.c:663 python PyLong_FromVoidPtr 0806781c 4 188148 0.0021 99.5276 listobject.c:1769 python PyList_Sort 08067474 4 188152 0.0021 99.5297 listobject.c:1593 python merge_collapse 08066b4c 4 188156 0.0021 99.5318 listobject.c:1068 python gallop_right 08066994 4 188160 0.0021 99.5340 listobject.c:977 python gallop_left 08065cc4 4 188164 0.0021 99.5361 listobject.c:419 python list_repeat 08065b14 4 188168 0.0021 99.5382 listobject.c:351 python list_slice 08065650 4 188172 0.0021 99.5403 listobject.c:180 python PyList_Insert 08062ce8 4 188176 0.0021 99.5424 floatobject.c:866 python PyFloat_Fini 0805bcd8 4 188180 0.0021 99.5445 classobject.c:922 python instance_hash 08055f90 4 188184 0.0021 99.5467 tokenizer.c:641 python PyTokenizer_Free 08054720 4 188188 0.0021 99.5488 (no location information) python __do_global_dtors_aux 080546d8 4 188192 0.0021 99.5509 (no location information) python _start 0804c47c 4 188196 0.0021 99.5530 db_manage.c:73 oprofiled odb_hash_add_node 0804af3c 4 188200 0.0021 99.5551 opd_mapping.c:171 oprofiled opd_handle_mapping 00000000 4 188204 0.0021 99.5572 (no location information) libwidget_gtk2.so (no symbols) 00000000 4 188208 0.0021 99.5594 (no location information) libnspr4.so (no symbols) 00003710 4 188212 0.0021 99.5615 (no location information) oprofile.o my_sys_fork 00126f6c 4 188216 0.0021 99.5636 (no location information) nvidia.o __nvsym04958 0003fff0 4 188220 0.0021 99.5657 (no location information) nvidia.o __nvsym01321 0003ff5c 4 188224 0.0021 99.5678 (no location information) nvidia.o __nvsym01474 0003df64 4 188228 0.0021 99.5699 (no location information) nvidia.o __nvsym02128 0003deb4 4 188232 0.0021 99.5721 (no location information) nvidia.o __nvsym02376 0003dd04 4 188236 0.0021 99.5742 (no location information) nvidia.o __nvsym02168 0002de10 4 188240 0.0021 99.5763 (no location information) nvidia.o __nvsym01721 00021720 4 188244 0.0021 99.5784 (no location information) nvidia.o __nvsym01478 00002537 4 188248 0.0021 99.5805 (no location information) nvidia.o nv_lock_rm 0000ac2e 4 188252 0.0021 99.5826 (no location information) libpthread-0.10.so pthread_rwlock_unlock 000085a8 4 188256 0.0021 99.5847 (no location information) libpthread-0.10.so __pthread_key_create 00005cb0 4 188260 0.0021 99.5869 (no location information) ld-2.3.1.so _dl_unload_cache_internal 00002f47 4 188264 0.0021 99.5890 (no location information) ld-2.3.1.so elf_machine_runtime_setup c0235a44 3 188267 0.0016 99.5906 (no location information) vmlinux csum_partial_copy_generic c0216930 3 188270 0.0016 99.5922 (no location information) vmlinux tcp_v4_rcv c0205e00 3 188273 0.0016 99.5937 (no location information) vmlinux tcp_sendmsg c01f6a30 3 188276 0.0016 99.5953 (no location information) vmlinux dev_watchdog c01e0ca0 3 188279 0.0016 99.5969 (no location information) vmlinux uhci_interrupt c01e0170 3 188282 0.0016 99.5985 (no location information) vmlinux rh_int_timer_do c01a86e0 3 188285 0.0016 99.6001 (no location information) vmlinux ide_outb c01a12d0 3 188288 0.0016 99.6017 (no location information) vmlinux handle_scancode c019a700 3 188291 0.0016 99.6033 (no location information) vmlinux con_chars_in_buffer c018ca20 3 188294 0.0016 99.6048 (no location information) vmlinux n_tty_chars_in_buffer c018c660 3 188297 0.0016 99.6064 (no location information) vmlinux __constant_copy_to_user c018b560 3 188300 0.0016 99.6080 (no location information) vmlinux tiocspgrp c0189690 3 188303 0.0016 99.6096 (no location information) vmlinux tty_check_change c0153b50 3 188306 0.0016 99.6112 (no location information) vmlinux proc_file_read c01520e0 3 188309 0.0016 99.6128 (no location information) vmlinux proc_get_inode c014bad0 3 188312 0.0016 99.6144 (no location information) vmlinux is_bad_inode c014b0b0 3 188315 0.0016 99.6160 (no location information) vmlinux iget4 c01431e0 3 188318 0.0016 99.6175 (no location information) vmlinux vfs_follow_link c0140720 3 188321 0.0016 99.6191 (no location information) vmlinux real_lookup c013e770 3 188324 0.0016 99.6207 (no location information) vmlinux kernel_read c013e680 3 188327 0.0016 99.6223 (no location information) vmlinux open_exec c0138390 3 188330 0.0016 99.6239 (no location information) vmlinux inode_has_buffers c0130a50 3 188333 0.0016 99.6255 (no location information) vmlinux __get_free_pages c012f3e0 3 188336 0.0016 99.6271 (no location information) vmlinux lru_cache_del c012ea70 3 188339 0.0016 99.6287 (no location information) vmlinux kmalloc c0126f20 3 188342 0.0016 99.6302 (no location information) vmlinux lock_vma_mappings c0123d10 3 188345 0.0016 99.6318 (no location information) vmlinux sys_getrlimit c0123ae0 3 188348 0.0016 99.6334 (no location information) vmlinux sys_newuname c01218e0 3 188351 0.0016 99.6350 (no location information) vmlinux do_notify_parent c01211f0 3 188354 0.0016 99.6366 (no location information) vmlinux send_signal c0120ba0 3 188357 0.0016 99.6382 (no location information) vmlinux flush_sigqueue c011fd80 3 188360 0.0016 99.6398 (no location information) vmlinux del_timer c011fce0 3 188363 0.0016 99.6413 (no location information) vmlinux add_timer c011bd00 3 188366 0.0016 99.6429 (no location information) vmlinux do_setitimer c011ab40 3 188369 0.0016 99.6445 (no location information) vmlinux release_task c01163b0 3 188372 0.0016 99.6461 (no location information) vmlinux mm_init c0116220 3 188375 0.0016 99.6477 (no location information) vmlinux remove_wait_queue c0106580 3 188378 0.0016 99.6493 (no location information) vmlinux sys_sigreturn c01053a0 3 188381 0.0016 99.6509 (no location information) vmlinux default_idle 00001168 3 188384 0.0016 99.6525 (no location information) strop.so call_gmon_start 080ca09c 3 188387 0.0016 99.6540 structmember.c:33 python PyMember_Get 080c9718 3 188390 0.0016 99.6556 structseq.c:31 python PyStructSequence_New 080c83a8 3 188393 0.0016 99.6572 funcobject.c:603 python cm_traverse 080c52d0 3 188396 0.0016 99.6588 descrobject.c:130 python member_get 080c2000 3 188399 0.0016 99.6604 parser.c:109 python shift 080c1228 3 188402 0.0016 99.6620 zipimport.c:1138 python initzipimport 080bfbe0 3 188405 0.0016 99.6636 _codecsmodule.c:814 python init_codecs 080b7198 3 188408 0.0016 99.6652 posixmodule.c:4327 python posix_popen 080b6110 3 188411 0.0016 99.6667 posixmodule.c:1344 python posix_listdir 080b5b1c 3 188414 0.0016 99.6683 posixmodule.c:823 python fill_time 080b37b0 3 188417 0.0016 99.6699 gcmodule.c:501 python delete_garbage 080b2424 3 188420 0.0016 99.6715 thread_pthread.h:425 python PyThread_release_lock 080b2388 3 188423 0.0016 99.6731 thread_pthread.h:391 python fix_status 080ae2d8 3 188426 0.0016 99.6747 pythonrun.c:514 python initsite 080ad984 3 188429 0.0016 99.6763 pystate.c:385 python _PyGILState_Init 080ad188 3 188432 0.0016 99.6778 pystate.c:43 python PyInterpreterState_New 080ad148 3 188435 0.0016 99.6794 mysnprintf.c:43 python PyOS_snprintf 080acee8 3 188438 0.0016 99.6810 modsupport.c:543 python PyModule_AddIntConstant 080a6d48 3 188441 0.0016 99.6826 import.c:157 python _PyImportHooks_Init 080a2a40 3 188444 0.0016 99.6842 codecs.c:231 python PyCodec_Encoder 0809f9d0 3 188447 0.0016 99.6858 compile.c:4062 python com_file_input 0809db4c 3 188450 0.0016 99.6874 compile.c:2808 python com_augassign 0809d274 3 188453 0.0016 99.6890 compile.c:2451 python com_not_test 0809ce10 3 188456 0.0016 99.6905 compile.c:2278 python com_and_expr 0809ccb8 3 188459 0.0016 99.6921 compile.c:2226 python com_arith_expr 0809aa5c 3 188462 0.0016 99.6937 compile.c:1012 python _Py_Mangle 0809a5d8 3 188465 0.0016 99.6953 compile.c:825 python com_pop 080989e0 3 188468 0.0016 99.6969 ceval.c:3825 python assign_slice 080974ac 3 188471 0.0016 99.6985 ceval.c:2830 python do_raise 08092450 3 188474 0.0016 99.7001 exceptions.c:681 python SyntaxError__classinit__ 08088a10 3 188477 0.0016 99.7017 unicodeobject.c:3437 python PyUnicodeUCS2_EncodeDecimal 08084a8c 3 188480 0.0016 99.7032 unicodeobject.c:662 python PyUnicodeUCS2_GetDefaultEncoding 080845a0 3 188483 0.0016 99.7048 unicodeobject.c:453 python PyUnicodeUCS2_FromEncodedObject 0807e7fc 3 188486 0.0016 99.7064 typeobject.c:3553 python wrap_objobjproc 0807e748 3 188489 0.0016 99.7080 typeobject.c:3521 python wrap_intintobjargproc 08075ba0 3 188492 0.0016 99.7096 stringobject.c:2442 python string_endswith 08074a54 3 188495 0.0016 99.7112 stringobject.c:1642 python string_rfind 08070d94 3 188498 0.0016 99.7128 object.c:1322 python _PyObject_GetDictPtr 0806f52c 3 188501 0.0016 99.7143 object.c:178 python _PyObject_New 0806f504 3 188504 0.0016 99.7159 object.c:166 python PyObject_InitVar 0806f170 3 188507 0.0016 99.7175 dictobject.c:1819 python dict_contains 0806ed3c 3 188510 0.0016 99.7191 dictobject.c:1498 python dict_get 08069778 3 188513 0.0016 99.7207 longobject.c:906 python v_isub 080693cc 3 188516 0.0016 99.7223 longobject.c:732 python PyLong_FromLongLong 0806737c 3 188519 0.0016 99.7239 listobject.c:1526 python merge_at 08066d08 3 188522 0.0016 99.7255 listobject.c:1202 python merge_init 08064eec 3 188525 0.0016 99.7270 iterobject.c:13 python PySeqIter_New 08064770 3 188528 0.0016 99.7286 intobject.c:811 python int_and 08063480 3 188531 0.0016 99.7302 intobject.c:9 python PyInt_GetMax 0805ecf8 3 188534 0.0016 99.7318 fileobject.c:112 python fill_file_fields 0805ec7c 3 188537 0.0016 99.7334 fileobject.c:87 python dircheck 08056488 3 188540 0.0016 99.7350 tokenizer.c:813 python tok_backup 08055d4c 3 188543 0.0016 99.7366 tokenizer.c:514 python buf_getc 08054788 3 188546 0.0016 99.7382 python.c:11 python main 0804e4bc 3 188549 0.0016 99.7397 (no location information) oprofiled xmalloc 0804abac 3 188552 0.0016 99.7413 opd_image.c:261 oprofiled opd_find_image 08049f40 3 188555 0.0016 99.7429 opd_kernel.c:419 oprofiled opd_eip_is_kernel 00000000 3 188558 0.0016 99.7445 (no location information) libimglib2.so (no symbols) 00000000 3 188561 0.0016 99.7461 (no location information) insmod (no symbols) 00003400 3 188564 0.0016 99.7477 (no location information) oprofile.o oprof_output_maps 000b842c 3 188567 0.0016 99.7493 (no location information) nvidia.o __nvsym03786 0003dfe4 3 188570 0.0016 99.7508 (no location information) nvidia.o __nvsym02079 0003de34 3 188573 0.0016 99.7524 (no location information) nvidia.o __nvsym02434 00000710 3 188576 0.0016 99.7540 (no location information) 8390.o ei_tx_intr 0000a3ec 3 188579 0.0016 99.7556 (no location information) libpthread-0.10.so rwlock_is_in_list 00007b64 3 188582 0.0016 99.7572 (no location information) libpthread-0.10.so pthread_onexit_process 0000451c 3 188585 0.0016 99.7588 (no location information) libpthread-0.10.so frame_dummy 0000c060 3 188588 0.0016 99.7604 (no location information) ld-2.3.1.so _dl_next_ld_env_entry 00000b07 3 188591 0.0016 99.7620 (no location information) ld-2.3.1.so _dl_start_user 00000b00 3 188594 0.0016 99.7635 (no location information) ld-2.3.1.so _start c0237050 2 188596 0.0011 99.7646 (no location information) vmlinux vsprintf c0235924 2 188598 0.0011 99.7657 (no location information) vmlinux csum_partial c02316c0 2 188600 0.0011 99.7667 (no location information) vmlinux unix_stream_sendmsg c0210ed0 2 188602 0.0011 99.7678 (no location information) vmlinux tcp_write_xmit c0200600 2 188604 0.0011 99.7688 (no location information) vmlinux ip_output c01fb0e0 2 188606 0.0011 99.7699 (no location information) vmlinux ip_route_input c01ea7e0 2 188608 0.0011 99.7709 (no location information) vmlinux alloc_skb c01e7850 2 188610 0.0011 99.7720 (no location information) vmlinux sock_poll c01a2540 2 188612 0.0011 99.7731 (no location information) vmlinux handle_kbd_event c018b230 2 188614 0.0011 99.7741 (no location information) vmlinux tiocgwinsz c018b000 2 188616 0.0011 99.7752 (no location information) vmlinux tty_poll c0189dd0 2 188618 0.0011 99.7762 (no location information) vmlinux tty_read c0151f40 2 188620 0.0011 99.7773 (no location information) vmlinux proc_read_inode c0151ef0 2 188622 0.0011 99.7784 (no location information) vmlinux proc_delete_inode c014dc90 2 188624 0.0011 99.7794 (no location information) vmlinux copy_namespace c014a450 2 188626 0.0011 99.7805 (no location information) vmlinux __mark_inode_dirty c0149a50 2 188628 0.0011 99.7815 (no location information) vmlinux d_rehash c0149760 2 188630 0.0011 99.7826 (no location information) vmlinux d_instantiate c0145200 2 188632 0.0011 99.7836 (no location information) vmlinux poll_freewait c0145100 2 188634 0.0011 99.7847 (no location information) vmlinux __constant_copy_to_user c013f5f0 2 188636 0.0011 99.7858 (no location information) vmlinux flush_old_files c013eb40 2 188638 0.0011 99.7868 (no location information) vmlinux prepare_binprm c013de30 2 188640 0.0011 99.7879 (no location information) vmlinux sys_lstat64 c01389f0 2 188642 0.0011 99.7889 (no location information) vmlinux __refile_buffer c0136a20 2 188644 0.0011 99.7900 (no location information) vmlinux sys_write c012ea60 2 188646 0.0011 99.7911 (no location information) vmlinux kmem_cache_alloc c012b460 2 188648 0.0011 99.7921 (no location information) vmlinux read_cache_page c01283d0 2 188650 0.0011 99.7932 (no location information) vmlinux insert_vm_struct c01281b0 2 188652 0.0011 99.7942 (no location information) vmlinux build_mmap_rb c01229f0 2 188654 0.0011 99.7953 (no location information) vmlinux sys_ni_syscall c0121380 2 188656 0.0011 99.7963 (no location information) vmlinux send_sig_info c0121000 2 188658 0.0011 99.7974 (no location information) vmlinux rm_sig_from_queue c0120a40 2 188660 0.0011 99.7985 (no location information) vmlinux free_uid c0120830 2 188662 0.0011 99.7995 (no location information) vmlinux internal_add_timer c011be00 2 188664 0.0011 99.8006 (no location information) vmlinux sys_setitimer c01191d0 2 188666 0.0011 99.8016 (no location information) vmlinux try_inc_mod_count c01167a0 2 188668 0.0011 99.8027 (no location information) vmlinux count_open_files c01165a0 2 188670 0.0011 99.8037 (no location information) vmlinux copy_mm c0114cd0 2 188672 0.0011 99.8048 (no location information) vmlinux reschedule_idle c010af00 2 188674 0.0011 99.8059 (no location information) vmlinux common_interrupt c01084c0 2 188676 0.0011 99.8069 (no location information) vmlinux set_ldt_desc c0106d80 2 188678 0.0011 99.8080 (no location information) vmlinux handle_signal c0105e60 2 188680 0.0011 99.8090 (no location information) vmlinux __constant_c_and_count_memset c0105720 2 188682 0.0011 99.8101 (no location information) vmlinux release_segments 080ca5f4 2 188684 0.0011 99.8112 (no location information) python stat64 080c9688 2 188686 0.0011 99.8122 rangeobject.c:231 python range_iter 080c9508 2 188688 0.0011 99.8133 rangeobject.c:80 python range_new 080c9434 2 188690 0.0011 99.8143 rangeobject.c:14 python PyRange_New 080c8454 2 188692 0.0011 99.8154 funcobject.c:637 python cm_init 080c5bac 2 188694 0.0011 99.8164 descrobject.c:877 python PyDictProxy_New 080bfbac 2 188696 0.0011 99.8175 _codecsmodule.c:756 python lookup_error 080bed88 2 188698 0.0011 99.8186 _codecsmodule.c:51 python codecregister 080b8c2c 2 188700 0.0011 99.8196 posixmodule.c:7125 python ins 080b6a1c 2 188702 0.0011 99.8207 posixmodule.c:2078 python posix_execve 080b5b84 2 188704 0.0011 99.8217 posixmodule.c:844 python _pystat_fromstructstat 080b4190 2 188706 0.0011 99.8228 gcmodule.c:1088 python _PyObject_GC_Resize 080b3340 2 188708 0.0011 99.8238 gcmodule.c:162 python gc_list_merge 080b32cc 2 188710 0.0011 99.8249 getpath.c:646 python Py_GetProgramFullPath 080b2680 2 188712 0.0011 99.8260 getpath.c:153 python ismodule 080b250c 2 188714 0.0011 99.8270 thread.c:194 python PyThread_delete_key 080b24e4 2 188716 0.0011 99.8281 thread.c:187 python PyThread_create_key 080b2198 2 188718 0.0011 99.8291 thread.c:69 python PyThread_init_thread 080b1298 2 188720 0.0011 99.8302 sysmodule.c:1056 python makepathobject 080b03e4 2 188722 0.0011 99.8313 sysmodule.c:150 python sys_exc_info 080afccc 2 188724 0.0011 99.8323 pythonrun.c:1443 python call_sys_exitfunc 080aea14 2 188726 0.0011 99.8334 pythonrun.c:792 python PyRun_SimpleStringFlags 080ae22c 2 188728 0.0011 99.8344 pythonrun.c:495 python initmain 080ad420 2 188730 0.0011 99.8355 pystate.c:132 python PyThreadState_New 080acf48 2 188732 0.0011 99.8365 mystrtoul.c:39 python PyOS_strtoul 080acf18 2 188734 0.0011 99.8376 modsupport.c:549 python PyModule_AddStringConstant 080a8a6c 2 188736 0.0011 99.8387 import.c:1594 python find_init_module 080a3d30 2 188738 0.0011 99.8397 errors.c:342 python PyErr_SetFromErrnoWithFilename 080a38d8 2 188740 0.0011 99.8408 errors.c:68 python PyErr_SetString 080a063c 2 188742 0.0011 99.8418 compile.c:4490 python symtable_init_compiling_symbols 080a03e8 2 188744 0.0011 99.8429 compile.c:4408 python get_ref_type 0809cbe4 2 188746 0.0011 99.8439 compile.c:2191 python com_term 0809a654 2 188748 0.0011 99.8450 compile.c:843 python com_check_size 08098424 2 188750 0.0011 99.8461 ceval.c:3580 python update_star_args 08097d74 2 188752 0.0011 99.8471 ceval.c:3302 python Py_FlushLine 0808f8ac 2 188754 0.0011 99.8482 bltinmodule.c:1200 python builtin_ord 0808f83c 2 188756 0.0011 99.8492 bltinmodule.c:1152 python builtin_min 0808e920 2 188758 0.0011 99.8503 bltinmodule.c:421 python builtin_dir 08074d98 2 188760 0.0011 99.8514 stringobject.c:1817 python string_rstrip 08074c28 2 188762 0.0011 99.8524 stringobject.c:1735 python do_argstrip 080747d4 2 188764 0.0011 99.8535 stringobject.c:1548 python string_find_internal 080715e4 2 188766 0.0011 99.8545 object.c:1775 python PyObject_Dir 0806fb38 2 188768 0.0011 99.8556 object.c:435 python adjust_tp_compare 0806e700 2 188770 0.0011 99.8566 dictobject.c:1266 python PyDict_Keys 0806cafc 2 188772 0.0011 99.8577 longobject.c:2702 python long_int 08069880 2 188774 0.0011 99.8588 longobject.c:963 python inplace_divrem1 080688bc 2 188776 0.0011 99.8598 longobject.c:59 python _PyLong_New 08068878 2 188778 0.0011 99.8609 longobject.c:43 python long_normalize 08063ca4 2 188780 0.0011 99.8619 intobject.c:379 python int_compare 08063a40 2 188782 0.0011 99.8630 intobject.c:277 python PyInt_FromString 0805ebc4 2 188784 0.0011 99.8641 classobject.c:2509 python PyMethod_Fini 0805abb8 2 188786 0.0011 99.8651 classobject.c:314 python class_setattr 08057fb0 2 188788 0.0011 99.8662 abstract.c:601 python PyNumber_Lshift 08057f94 2 188790 0.0011 99.8672 abstract.c:600 python PyNumber_And 0805475c 2 188792 0.0011 99.8683 (no location information) python frame_dummy 0804db20 2 188794 0.0011 99.8693 op_file.c:65 oprofiled op_get_mtime 0804c024 2 188796 0.0011 99.8704 oprofiled.c:520 oprofiled opd_do_samples 0804b004 2 188798 0.0011 99.8715 opd_parse_proc.c:45 oprofiled opd_add_ascii_map 0804ad88 2 188800 0.0011 99.8725 opd_mapping.c:96 oprofiled opd_add_mapping 08049a78 2 188802 0.0011 99.8736 opd_kernel.c:165 oprofiled opd_get_module_info 00000000 2 188804 0.0011 99.8746 (no location information) libgtk-x11-2.0.so.0.200.1 (no symbols) 00000000 2 188806 0.0011 99.8757 (no location information) gawk (no symbols) 00000000 2 188808 0.0011 99.8767 (no location information) ximcp.so.2 (no symbols) 000008d0 2 188810 0.0011 99.8778 (no location information) oprofile.o is_ready 00000cd0 2 188812 0.0011 99.8789 (no location information) ip_conntrack.o ip_conntrack_find_get_Rb2ef83ad 00000870 2 188814 0.0011 99.8799 (no location information) ip_conntrack.o hash_conntrack 000db9f4 2 188816 0.0011 99.8810 (no location information) nvidia.o __nvsym04022 000baa70 2 188818 0.0011 99.8820 (no location information) nvidia.o __nvsym03801 000b83d0 2 188820 0.0011 99.8831 (no location information) nvidia.o __nvsym03788 00017680 2 188822 0.0011 99.8842 (no location information) nvidia.o __nvsym00742 000073bb 2 188824 0.0011 99.8852 (no location information) libpthread-0.10.so __libc_dl_error_tsd 00004b23 2 188826 0.0011 99.8863 (no location information) libpthread-0.10.so _pthread_cleanup_push 000044b4 2 188828 0.0011 99.8873 (no location information) libpthread-0.10.so __do_global_dtors_aux 0000d6a0 2 188830 0.0011 99.8884 (no location information) ld-2.3.1.so uname 0000d110 2 188832 0.0011 99.8894 (no location information) ld-2.3.1.so __libc_close 0000c70c 2 188834 0.0011 99.8905 (no location information) ld-2.3.1.so sbrk 0000c6c0 2 188836 0.0011 99.8916 (no location information) ld-2.3.1.so __brk 00009c54 2 188838 0.0011 99.8926 (no location information) ld-2.3.1.so _dl_debug_state_internal 00009c10 2 188840 0.0011 99.8937 (no location information) ld-2.3.1.so _dl_debug_initialize 00005dbd 2 188842 0.0011 99.8947 (no location information) ld-2.3.1.so _dl_string_platform 000010c0 2 188844 0.0011 99.8958 (no location information) ld-2.3.1.so version_check_doit c0237080 1 188845 5.3e-04 99.8963 (no location information) vmlinux sprintf c0213980 1 188846 5.3e-04 99.8968 (no location information) vmlinux tcp_write_timer c0211130 1 188847 5.3e-04 99.8974 (no location information) vmlinux __tcp_select_window c020e7c0 1 188848 5.3e-04 99.8979 (no location information) vmlinux tcp_rcv_established c020c4b0 1 188849 5.3e-04 99.8984 (no location information) vmlinux tcp_ack c0209e90 1 188850 5.3e-04 99.8990 (no location information) vmlinux tcp_event_data_recv c02073f0 1 188851 5.3e-04 99.8995 (no location information) vmlinux tcp_recvmsg c0202640 1 188852 5.3e-04 99.9000 (no location information) vmlinux ip_finish_output2 c01fda00 1 188853 5.3e-04 99.9006 (no location information) vmlinux ip_rcv_finish c01fd690 1 188854 5.3e-04 99.9011 (no location information) vmlinux ip_rcv c01f8f30 1 188855 5.3e-04 99.9016 (no location information) vmlinux rt_check_expire c01f6d20 1 188856 5.3e-04 99.9021 (no location information) vmlinux pfifo_fast_dequeue c01f6940 1 188857 5.3e-04 99.9027 (no location information) vmlinux qdisc_restart c01efab0 1 188858 5.3e-04 99.9032 (no location information) vmlinux net_rx_action c01ef500 1 188859 5.3e-04 99.9037 (no location information) vmlinux get_sample_stats c01ec5e0 1 188860 5.3e-04 99.9043 (no location information) vmlinux memcpy_toiovec c01ec2f0 1 188861 5.3e-04 99.9048 (no location information) vmlinux __constant_memcpy c01ebd10 1 188862 5.3e-04 99.9053 (no location information) vmlinux skb_checksum c01eab10 1 188863 5.3e-04 99.9058 (no location information) vmlinux __kfree_skb c01ea380 1 188864 5.3e-04 99.9064 (no location information) vmlinux sock_def_readable c01e9f00 1 188865 5.3e-04 99.9069 (no location information) vmlinux __release_sock c01e99f0 1 188866 5.3e-04 99.9074 (no location information) vmlinux sock_wfree c01e76b0 1 188867 5.3e-04 99.9080 (no location information) vmlinux sock_readv_writev c01e7570 1 188868 5.3e-04 99.9085 (no location information) vmlinux sock_write c01e74c0 1 188869 5.3e-04 99.9090 (no location information) vmlinux sock_read c01e7320 1 188870 5.3e-04 99.9095 (no location information) vmlinux sock_sendmsg c01e0bb0 1 188871 5.3e-04 99.9101 (no location information) vmlinux uhci_finish_completion c01e02e0 1 188872 5.3e-04 99.9106 (no location information) vmlinux rh_init_int_timer c01a4bb0 1 188873 5.3e-04 99.9111 (no location information) vmlinux __make_request c01a25f0 1 188874 5.3e-04 99.9117 (no location information) vmlinux keyboard_interrupt c019c980 1 188875 5.3e-04 99.9122 (no location information) vmlinux rs_timer c019a0e0 1 188876 5.3e-04 99.9127 (no location information) vmlinux console_callback c01911b0 1 188877 5.3e-04 99.9132 (no location information) vmlinux batch_entropy_store c01910e0 1 188878 5.3e-04 99.9138 (no location information) vmlinux add_entropy_words c018e190 1 188879 5.3e-04 99.9143 (no location information) vmlinux write_chan c018cc10 1 188880 5.3e-04 99.9148 (no location information) vmlinux opost_block c018c790 1 188881 5.3e-04 99.9154 (no location information) vmlinux do_tty_write c018a020 1 188882 5.3e-04 99.9159 (no location information) vmlinux init_dev c0181af0 1 188883 5.3e-04 99.9164 (no location information) vmlinux __constant_c_and_count_memset c0180d10 1 188884 5.3e-04 99.9169 (no location information) vmlinux reiserfs_prepare_for_journal c017e150 1 188885 5.3e-04 99.9175 (no location information) vmlinux remove_journal_hash c017e0a0 1 188886 5.3e-04 99.9180 (no location information) vmlinux reiserfs_journal_kupdate c0177ab0 1 188887 5.3e-04 99.9185 (no location information) vmlinux is_leaf c01671e0 1 188888 5.3e-04 99.9191 (no location information) vmlinux reiserfs_get_block c015e600 1 188889 5.3e-04 99.9196 (no location information) vmlinux ext2_readlink c015bf90 1 188890 5.3e-04 99.9201 (no location information) vmlinux ext2_update_inode c0153f80 1 188891 5.3e-04 99.9207 (no location information) vmlinux proc_delete_dentry c0151e80 1 188892 5.3e-04 99.9212 (no location information) vmlinux de_put c014e770 1 188893 5.3e-04 99.9217 (no location information) vmlinux seq_read c014bb00 1 188894 5.3e-04 99.9222 (no location information) vmlinux alloc_fd_array c014b570 1 188895 5.3e-04 99.9228 (no location information) vmlinux __sync_one c014b4f0 1 188896 5.3e-04 99.9233 (no location information) vmlinux __constant_c_and_count_memset c0145310 1 188897 5.3e-04 99.9238 (no location information) vmlinux max_select_fd c0145080 1 188898 5.3e-04 99.9244 (no location information) vmlinux __constant_c_and_count_memset c01447c0 1 188899 5.3e-04 99.9249 (no location information) vmlinux vfs_readdir c0144250 1 188900 5.3e-04 99.9254 (no location information) vmlinux send_sigio c0140640 1 188901 5.3e-04 99.9259 (no location information) vmlinux deny_write_access c013f210 1 188902 5.3e-04 99.9265 (no location information) vmlinux set_binfmt c013a9e0 1 188903 5.3e-04 99.9270 (no location information) vmlinux grow_buffers c01353f0 1 188904 5.3e-04 99.9275 (no location information) vmlinux sys_access c0134040 1 188905 5.3e-04 99.9281 (no location information) vmlinux shmem_lookup c0130b10 1 188906 5.3e-04 99.9286 (no location information) vmlinux free_pages c012b500 1 188907 5.3e-04 99.9291 (no location information) vmlinux generic_file_write c01291b0 1 188908 5.3e-04 99.9296 (no location information) vmlinux find_trylock_page c0126560 1 188909 5.3e-04 99.9302 (no location information) vmlinux vmtruncate c01256e0 1 188910 5.3e-04 99.9307 (no location information) vmlinux check_pgt_cache c0123e00 1 188911 5.3e-04 99.9312 (no location information) vmlinux sys_setrlimit c0123ab0 1 188912 5.3e-04 99.9318 (no location information) vmlinux in_egroup_p c01218b0 1 188913 5.3e-04 99.9323 (no location information) vmlinux wake_up_parent c0121310 1 188914 5.3e-04 99.9328 (no location information) vmlinux deliver_signal c0121150 1 188915 5.3e-04 99.9333 (no location information) vmlinux handle_stop_signal c0121100 1 188916 5.3e-04 99.9339 (no location information) vmlinux ignored_signal c0121010 1 188917 5.3e-04 99.9344 (no location information) vmlinux bad_signal c0120c10 1 188918 5.3e-04 99.9349 (no location information) vmlinux exit_sighand c011ef40 1 188919 5.3e-04 99.9355 (no location information) vmlinux __constant_copy_from_user c011d880 1 188920 5.3e-04 99.9360 (no location information) vmlinux do_sysctl_strategy c011d5c0 1 188921 5.3e-04 99.9365 (no location information) vmlinux do_sysctl c011cfd0 1 188922 5.3e-04 99.9371 (no location information) vmlinux cpu_raise_softirq c011ceb0 1 188923 5.3e-04 99.9376 (no location information) vmlinux __run_task_queue c011c2c0 1 188924 5.3e-04 99.9381 (no location information) vmlinux sys_time c0114da0 1 188925 5.3e-04 99.9386 (no location information) vmlinux schedule_timeout c0113dc0 1 188926 5.3e-04 99.9392 (no location information) vmlinux si_meminfo c010e0b0 1 188927 5.3e-04 99.9397 (no location information) vmlinux save_i387_fxsave c010d6e0 1 188928 5.3e-04 99.9402 (no location information) vmlinux restore_fpu c010af13 1 188929 5.3e-04 99.9408 (no location information) vmlinux call_do_IRQ c010a240 1 188930 5.3e-04 99.9413 (no location information) vmlinux release_x86_irqs c0108940 1 188931 5.3e-04 99.9418 (no location information) vmlinux enable_irq c0107140 1 188932 5.3e-04 99.9423 (no location information) vmlinux sigorsets c0105bc0 1 188933 5.3e-04 99.9429 (no location information) vmlinux sys_fork c01057d0 1 188934 5.3e-04 99.9434 (no location information) vmlinux flush_thread 080ca668 1 188935 5.3e-04 99.9439 (no location information) python _fini 080c6eb4 1 188936 5.3e-04 99.9445 frameobject.c:531 python _PyFrame_Init 080c5ae0 1 188937 5.3e-04 99.9450 descrobject.c:792 python proxy_dealloc 080c5910 1 188938 5.3e-04 99.9455 descrobject.c:637 python PyDescr_NewGetSet 080c3364 1 188939 5.3e-04 99.9460 cobject.c:104 python PyCObject_dealloc 080c1fdc 1 188940 5.3e-04 99.9466 parser.c:97 python PyParser_Delete 080c1eec 1 188941 5.3e-04 99.9471 parser.c:31 python s_reset 080b58b0 1 188942 5.3e-04 99.9476 posixmodule.c:403 python posix_error_with_allocated_filename 080b3fc4 1 188943 5.3e-04 99.9482 gcmodule.c:986 python PyGC_Collect 080b27e8 1 188944 5.3e-04 99.9487 getpath.c:220 python copy_absolute 080b2450 1 188945 5.3e-04 99.9492 thread.c:164 python find_key 080b17b8 1 188946 5.3e-04 99.9497 traceback.c:31 python tb_getattr 080b1360 1 188947 5.3e-04 99.9503 sysmodule.c:1089 python PySys_SetPath 080ad884 1 188948 5.3e-04 99.9508 pystate.c:262 python PyThreadState_Swap 080ad38c 1 188949 5.3e-04 99.9513 pystate.c:104 python PyInterpreterState_Delete 080ad164 1 188950 5.3e-04 99.9519 mysnprintf.c:55 python PyOS_vsnprintf 080ad0cc 1 188951 5.3e-04 99.9524 mystrtoul.c:129 python PyOS_strtol 080a6f4c 1 188952 5.3e-04 99.9529 import.c:223 python _PyImport_Fini 080a3ca0 1 188953 5.3e-04 99.9534 errors.c:262 python PyErr_SetFromErrnoWithFilenameObject 080a0bf4 1 188954 5.3e-04 99.9540 compile.c:4742 python symtable_update_flags 080a06b8 1 188955 5.3e-04 99.9545 compile.c:4525 python symtable_init_info 0809fe64 1 188956 5.3e-04 99.9550 compile.c:4216 python dict_keys_inorder 0809ee84 1 188957 5.3e-04 99.9556 compile.c:3537 python get_rawdocstring 0809d0e0 1 188958 5.3e-04 99.9561 compile.c:2374 python com_comparison 0809ca00 1 188959 5.3e-04 99.9566 compile.c:2132 python com_factor 0809c854 1 188960 5.3e-04 99.9572 compile.c:2052 python com_power 0809aa40 1 188961 5.3e-04 99.9577 compile.c:1006 python com_addname 08099f08 1 188962 5.3e-04 99.9582 compile.c:574 python is_free 08093ce0 1 188963 5.3e-04 99.9587 ceval.c:184 python gen_dealloc 0809098c 1 188964 5.3e-04 99.9593 bltinmodule.c:1888 python builtin_issubclass 0809093c 1 188965 5.3e-04 99.9598 bltinmodule.c:1863 python builtin_isinstance 0808f6ac 1 188966 5.3e-04 99.9603 bltinmodule.c:1085 python builtin_locals 080841b0 1 188967 5.3e-04 99.9609 unicodeobject.c:228 python unicode_dealloc 0807e2b0 1 188968 5.3e-04 99.9614 typeobject.c:3314 python wrap_binaryfunc 0807c344 1 188969 5.3e-04 99.9619 typeobject.c:2336 python object_get_class 0807bcf0 1 188970 5.3e-04 99.9624 typeobject.c:1976 python type_getattro 08078764 1 188971 5.3e-04 99.9630 tupleobject.c:275 python tupleitem 080766e0 1 188972 5.3e-04 99.9635 stringobject.c:3156 python string_mod 080765bc 1 188973 5.3e-04 99.9640 stringobject.c:3110 python string_new 08071a00 1 188974 5.3e-04 99.9646 object.c:2133 python Py_ReprEnter 08070038 1 188975 5.3e-04 99.9651 object.c:642 python default_3way_compare 0806a6c0 1 188976 5.3e-04 99.9656 longobject.c:1508 python long_compare 0806755c 1 188977 5.3e-04 99.9661 listobject.c:1648 python merge_compute_minrun 08067508 1 188978 5.3e-04 99.9667 listobject.c:1622 python merge_force_collapse 080666c8 1 188979 5.3e-04 99.9672 listobject.c:771 python reverse_slice 08064858 1 188980 5.3e-04 99.9677 intobject.c:829 python int_or 08060ef8 1 188981 5.3e-04 99.9683 fileobject.c:2017 python PyFile_SoftSpace 08060afc 1 188982 5.3e-04 99.9688 fileobject.c:1742 python drop_readahead 08059d80 1 188983 5.3e-04 99.9693 abstract.c:1988 python abstract_issubclass 08058f9c 1 188984 5.3e-04 99.9698 abstract.c:1288 python PySequence_SetSlice 080582b4 1 188985 5.3e-04 99.9704 abstract.c:735 python binary_iop1 08057a7c 1 188986 5.3e-04 99.9709 abstract.c:421 python binary_op 08055d64 1 188987 5.3e-04 99.9714 tokenizer.c:520 python buf_ungetc 0804e530 1 188988 5.3e-04 99.9720 (no location information) oprofiled xrealloc 0804c5f8 1 188989 5.3e-04 99.9725 db_manage.c:153 oprofiled odb_open 0804bf40 1 188990 5.3e-04 99.9730 oprofiled.c:466 oprofiled opd_do_notes 0804ad2c 1 188991 5.3e-04 99.9736 opd_mapping.c:60 oprofiled opd_init_maps 0804ac58 1 188992 5.3e-04 99.9741 opd_image.c:314 oprofiled opd_get_image_by_hash 0804a9d4 1 188993 5.3e-04 99.9746 opd_image.c:153 oprofiled opd_check_image_mtime 0804a794 1 188994 5.3e-04 99.9751 opd_proc.c:552 oprofiled opd_remove_kernel_mapping 0804a5e0 1 188995 5.3e-04 99.9757 opd_proc.c:432 oprofiled opd_handle_fork 0804a214 1 188996 5.3e-04 99.9762 opd_proc.c:180 oprofiled opd_add_proc 08049ef8 1 188997 5.3e-04 99.9767 opd_kernel.c:398 oprofiled opd_handle_kernel_sample 08049e1c 1 188998 5.3e-04 99.9773 opd_kernel.c:333 oprofiled opd_find_module_by_eip 08049168 1 188999 5.3e-04 99.9778 (no location information) oprofiled anonymous symbol from section .plt 00000000 1 189000 5.3e-04 99.9783 (no location information) libnecko.so (no symbols) 00000000 1 189001 5.3e-04 99.9788 (no location information) libjsdom.so (no symbols) 00000000 1 189002 5.3e-04 99.9794 (no location information) libcookie.so (no symbols) 00000000 1 189003 5.3e-04 99.9799 (no location information) libappcomps.so (no symbols) 00000000 1 189004 5.3e-04 99.9804 (no location information) libgconf-2.so.4.1.0 (no symbols) 00000000 1 189005 5.3e-04 99.9810 (no location information) libORBit-2.so.0.0.0 (no symbols) 00000000 1 189006 5.3e-04 99.9815 (no location information) galeon-bin (no symbols) 00000000 1 189007 5.3e-04 99.9820 (no location information) libgconfbackend-xml.so (no symbols) 00000000 1 189008 5.3e-04 99.9825 (no location information) libXaw.so.7.0 (no symbols) 00000000 1 189009 5.3e-04 99.9831 (no location information) init (no symbols) 00003a40 1 189010 5.3e-04 99.9836 (no location information) oprofile.o my_sys_exit 00003530 1 189011 5.3e-04 99.9841 (no location information) oprofile.o out_mmap 000002b0 1 189012 5.3e-04 99.9847 (no location information) iptable_nat.o ip_nat_local_fn 00000000 1 189013 5.3e-04 99.9852 (no location information) iptable_nat.o ip_nat_fn 00002b10 1 189014 5.3e-04 99.9857 (no location information) ip_conntrack.o resolve_normal_ct 00000460 1 189015 5.3e-04 99.9862 (no location information) ip_conntrack.o ip_conntrack_local 000dea90 1 189016 5.3e-04 99.9868 (no location information) nvidia.o __nvsym00630 000dbb10 1 189017 5.3e-04 99.9873 (no location information) nvidia.o __nvsym03976 000b8e38 1 189018 5.3e-04 99.9878 (no location information) nvidia.o __nvsym03792 000448cc 1 189019 5.3e-04 99.9884 (no location information) nvidia.o __nvsym01364 00043f24 1 189020 5.3e-04 99.9889 (no location information) nvidia.o __nvsym00721 00040020 1 189021 5.3e-04 99.9894 (no location information) nvidia.o __nvsym01359 0003e1c4 1 189022 5.3e-04 99.9899 (no location information) nvidia.o __nvsym01591 000222ec 1 189023 5.3e-04 99.9905 (no location information) nvidia.o __nvsym01451 00017648 1 189024 5.3e-04 99.9910 (no location information) nvidia.o __nvsym00667 000161d0 1 189025 5.3e-04 99.9915 (no location information) nvidia.o __nvsym00237 0000e4ec 1 189026 5.3e-04 99.9921 (no location information) nvidia.o __nvsym00345 000018e0 1 189027 5.3e-04 99.9926 (no location information) 8139too.o rtl8139_interrupt 00001430 1 189028 5.3e-04 99.9931 (no location information) 8139too.o rtl8139_rx_interrupt 0000b8a0 1 189029 5.3e-04 99.9937 (no location information) libpthread-0.10.so _fini 0000ae32 1 189030 5.3e-04 99.9942 (no location information) libpthread-0.10.so thread_self 0000a4e7 1 189031 5.3e-04 99.9947 (no location information) libpthread-0.10.so rwlock_have_already 0000a4b5 1 189032 5.3e-04 99.9952 (no location information) libpthread-0.10.so rwlock_can_rdlock 00008841 1 189033 5.3e-04 99.9958 (no location information) libpthread-0.10.so pthread_getspecific 000087b3 1 189034 5.3e-04 99.9963 (no location information) libpthread-0.10.so __pthread_setspecific 0000734a 1 189035 5.3e-04 99.9968 (no location information) libpthread-0.10.so __pthread_init_max_stacksize 0000721c 1 189036 5.3e-04 99.9974 (no location information) libpthread-0.10.so init_rtsigs 000053b6 1 189037 5.3e-04 99.9979 (no location information) libpthread-0.10.so thread_self 0000de8c 1 189038 5.3e-04 99.9984 (no location information) ld-2.3.1.so memmove 0000d940 1 189039 5.3e-04 99.9989 (no location information) ld-2.3.1.so _setjmp 00000af0 1 189040 5.3e-04 99.9995 (no location information) ld-2.3.1.so anonymous symbol from section .text 00000000 1 189041 5.3e-04 100.0000 (no location information) sleep (no symbols) From barry@python.org Sun Jul 20 19:29:26 2003 From: barry@python.org (Barry Warsaw) Date: 20 Jul 2003 14:29:26 -0400 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <20030715222422.GA3625@async.com.br> References: <20030715222422.GA3625@async.com.br> Message-ID: <1058725765.939.40.camel@anthem> On Tue, 2003-07-15 at 18:24, Christian Reis wrote: > I've spoken briefly to Guido about this, and he's suggested python-dev > as the place to ask. I'd really like to know how bad "too much would > break" is, and if anybody contemplates a way to fix it [*]. I'd volunteer to > work on the change, of course. > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=114132 > [2] http://www.python.org/doc/current/lib/embedding-locale.html > > [*] Havoc Pennington, from the GTK+ team, has offered a > LC_NUMERIC-agnostic strtod() implementation, but I get the feeling this > is more involved than just that. Can we perhaps have a PEP for the 2.4 timeframe? -Barry From kiko@async.com.br Sun Jul 20 19:43:30 2003 From: kiko@async.com.br (Christian Reis) Date: Sun, 20 Jul 2003 15:43:30 -0300 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <1058725765.939.40.camel@anthem> References: <20030715222422.GA3625@async.com.br> <1058725765.939.40.camel@anthem> Message-ID: <20030720184330.GB1082@async.com.br> On Sun, Jul 20, 2003 at 02:29:26PM -0400, Barry Warsaw wrote: > On Tue, 2003-07-15 at 18:24, Christian Reis wrote: > > > I've spoken briefly to Guido about this, and he's suggested python-dev > > as the place to ask. I'd really like to know how bad "too much would > > break" is, and if anybody contemplates a way to fix it [*]. I'd volunteer to > > work on the change, of course. > > > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=114132 > > [2] http://www.python.org/doc/current/lib/embedding-locale.html > > > > [*] Havoc Pennington, from the GTK+ team, has offered a > > LC_NUMERIC-agnostic strtod() implementation, but I get the feeling this > > is more involved than just that. > > Can we perhaps have a PEP for the 2.4 timeframe? Sure, if I can find time to write it. What we'd *really* appreciate are objective comments on the submission and code, to know if this approach is an acceptable one or not. I understand that evaluating it might require a bit more of the rationale and impact (which is where a PEP fits in); however, for first-time contributors, a bit of hinting and nudging is what we were hoping for. (I'm going to blame it all on the 2.3 release effort!) Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From barry@python.org Sun Jul 20 19:47:45 2003 From: barry@python.org (Barry Warsaw) Date: 20 Jul 2003 14:47:45 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: Message-ID: <1058726864.939.44.camel@anthem> On Sat, 2003-07-19 at 17:32, Tim Peters wrote: > Changes we want to go into the next 2.3 release stab (probably 2.3c2, alas) > should be checked in to the r23c1-branch branch. They'll eventually need to > get backported to the head. I'm slowly catching up on email. It looks like 2.3rc2 will be required and that PEP 283 has been updated to reflect this. I'm confused by this message though: are you volunteering to port r23c1-branch to the head so we can do the rc2 and then 2.3 final releases from the head? When is that going to happen, given that Thursday is the target for rc2? And Jack, are your changes going to make it in by Thursday? -Barry From barry@python.org Sun Jul 20 19:49:11 2003 From: barry@python.org (Barry Warsaw) Date: 20 Jul 2003 14:49:11 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: Message-ID: <1058726950.939.47.camel@anthem> On Sat, 2003-07-19 at 22:20, Tim Peters wrote: > Barry should back from vacation this coming week, and I bet he'll help try > things on OS X in his copious spare time. If a question arises without an > obvious answer, post it here and I'll make one up (favoring "let it alone > for 2.3 final" unless there's an obvious fix to an obvious problem). I'll definitely at least run the test suite on OSX 10.2.6 (or whatever is the current micro release now :). But that's about the extent of the time I'll have available for testing. Between Jack, Skip, and others that'll have to do. -Barry From gjc@inescporto.pt Sun Jul 20 20:42:51 2003 From: gjc@inescporto.pt (Gustavo J A M Carneiro) Date: 20 Jul 2003 20:42:51 +0100 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: References: <1058620108.3395.5.camel@emperor.localdomain> <3F19563D.5000909@v.loewis.de> <20030719154504.GU1158@async.com.br> Message-ID: <1058730171.1296.2.camel@emperor.localdomain> A Dom, 2003-07-20 =E0s 10:50, Martin v. L=F6wis escreveu: > Christian Reis writes: >=20 > > > a) it is unlikely that patches are accepted from anybody but > > > the author of the code, and > > > b) it is unlikely that patches are implemented that provide huge > > > chunks of the C library. > >=20 > > I'm afraid I didn't quite understand these two points: > >=20 > > a) Do you mean to say that the patch should be sent *to* the original > > author of the locale code? The original author of the code that *call= s* > > atof/strtod? >=20 > No. I said that the original author should send us the patches; we > will only accept them from that author. >=20 > > If the latter I can try and get Alex Larsson to submit the code. Is > > written permission from the glib team, relicensing the code, not > > acceptable enough, though? >=20 > We would have to discuss this in the PSF. In general, we want the PSF > to be owner of all contributed code, see >=20 > http://www.python.org/psf/psf-contributor-agreement.html >=20 > We had bad experience with contributions by non-authors in the past, > and had to back out changes that we later found we had no right to > distribute. >=20 > > b) I'm unsure as to how we should proceed without offering alternativ= e > > versions of strtod/formatd (which is what the pystrtod.c file include= s); > > AFAICS, the current situation is *caused* by the libc versions not be= ing > > LC_NUMERIC-safe. Do you see an alternative? >=20 > It might well be unimplementable. However, if you can find > platform-specific routines that you can wrap with a small wrapper, > falling back to strtod if such routines are not available, that might > be a way out. For example, on glibc, you could use __strtod_l. Well, the function does exist, but it's called strtod_l. I posted a new patch to sourceforge. It uses these glibc locale extensions when available, but falls back to the glib implementations if these extensions are not available. https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D774665&grou= p_id=3D5470&atid=3D305470 Regards. --=20 Gustavo J. A. M. Carneiro From tim.one@comcast.net Sun Jul 20 20:51:41 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 20 Jul 2003 15:51:41 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <1058726864.939.44.camel@anthem> Message-ID: [Barry Warsaw] > It looks like 2.3rc2 will be required I think so. If yesterday's parser module initialization fix is the only one that ends up getting made, though, I'd be comfortable going straight to a final release. But I don't expect that. > and that PEP 283 has been updated to reflect this. Yes, it schedules a 2.3c2 now. > I'm confused by this message though: are you volunteering to port > r23c1-branch to the head Somebody has to, but nobody has volunteered yet . > so we can do the rc2 and then 2.3 final releases from the head? The release is stretching out, so I didn't intend to release c2 or final from the head. The intent: + Work for c2 proceeds on r23c1-branch, which is the currently active release branch. + Other random work (for 2.3.1 and 2.4) continues on the head. + Come Thursday, - r23c1-branch is tagged as r23c2-fork, and r23c2-branch is created from it. - The then-current state of r23c1-branch is also backported to the head. - The c2 release is made from r23c2-branch, which also gets tagged with r23c2. + After Thursday, work for 2.3 final occurs on r23c2-branch, the then-currently active release branch. Other random work (for 2.3.1 and 2.4) continues on the head. + The Thursday after that, - r23c2-branch is tagged as release23, and release23-maint branch is created from it. - The release23 tag is backported to the head. = 2.3 final is released from the release23 tag. + After that, - 2.4 development occurs on the head. - 2.3.1 development occurs on release23-maint. > When is that going to happen, given that Thursday is the target > for rc2? It doesn't really matter when it happens, although it would be best to backport r23c2 changes to the head concurrent with the r23c2 release, and likewise for 2.3 final changes. > And Jack, are your changes going to make it in by Thursday? That's an important question! Since the point of releasing by the end of July is to synch with some Mac deadline, the point is missed if Jack's changes don't happen. From martin@v.loewis.de Sun Jul 20 22:19:23 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 20 Jul 2003 23:19:23 +0200 Subject: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <1058705856.1165.8.camel@emperor.localdomain> References: <1058620108.3395.5.camel@emperor.localdomain> <3F19563D.5000909@v.loewis.de> <20030719154504.GU1158@async.com.br> <1058705856.1165.8.camel@emperor.localdomain> Message-ID: Gustavo J A M Carneiro writes: > > No. I said that the original author should send us the patches; we > > will only accept them from that author. > > What if the original author isn't the least interested in Python? I > am, but I'm not willing reinvent the wheel. Then find a way to use that code without incorporating it into Python. Regards, Martin From martin@v.loewis.de Sun Jul 20 22:31:17 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 20 Jul 2003 23:31:17 +0200 Subject: [Python-Dev] Recent experiences with socket.inet_aton, socket.inet_{ntop,pton} In-Reply-To: References: Message-ID: Bob Halley writes: > A good implementation must also detect and reject all of the invalid > cases, such as improper use of the "::" zero compression syntax. In that case, I think we should drop the inet_ntop wrapper from socketmodule.c, and provide a pure-Python implementation in socket.py. I know for fact that some platforms don't support AF_INET6 at all, but still provide inet_pton, hence all the #ifdef dances in that function. So if you need guarantees about its behaviour, you have to implement it yourself. Contributions in this direction are welcome; as Aahz points out, they cannot have effect before 2.4. Make sure you provide plenty of test cases, too. Regards, Martin From martin@v.loewis.de Sun Jul 20 22:33:50 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 20 Jul 2003 23:33:50 +0200 Subject: [Python-Dev] Cross Compiling In-Reply-To: <20030720121141.B30653@linuxpower.org> References: <20030720121141.B30653@linuxpower.org> Message-ID: Adam Langley writes: > The configure script (for 2.2.3 at least) has defaults for its tests > of sizeof(int) and the like which are completely broken for cross > compiling. (They are generally values for a 32-bit system). The configure script really isn't meant for cross-compilation; you always have to adjust pyconfig.h manually. It may be possible to improve the code, but it can't be fully automatic. > So can I suggest a better(?) way of doing this (for systems with a GNU > toolchain at least): Please suggest that to the autoconf maintainers. We use standard autoconf macros for that, and we should continue to do so, so we can pick up any improvements they make to these macros. Regards, Martin From martin@v.loewis.de Sun Jul 20 22:36:40 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 20 Jul 2003 23:36:40 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: Message-ID: "Tim Peters" writes: > That's an important question! Since the point of releasing by the end of > July is to synch with some Mac deadline, the point is missed if Jack's > changes don't happen. I'm not so sure about that. I'd like to urge Jack to seriously reconsider what work necessarily has to be done to avoid a completely unusable release, and do any other work that also should be done only after the release. Regards, Martin From martin@v.loewis.de Sun Jul 20 22:40:48 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 20 Jul 2003 23:40:48 +0200 Subject: [Python-Dev] 2.3 startup speed? In-Reply-To: References: Message-ID: "Zooko" writes: > I don't know if this helps, but appended is a profile of the current CVS > version of Python while my Linux box was doing: It can't help for 2.3, but it is certainly interesting to learn that PyDict_Next is a top consumer. Can you find out who the common callers of that are? Regards, Martin From tim.one@comcast.net Sun Jul 20 23:23:51 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 20 Jul 2003 18:23:51 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: Message-ID: [Tim] >> That's an important question! Since the point of releasing by the >> end of July is to synch with some Mac deadline, the point is missed >> if Jack's changes don't happen. [Martin] > I'm not so sure about that. I'd like to urge Jack to seriously > reconsider what work necessarily has to be done to avoid a completely > unusable release, and do any other work that also should be done only > after the release. I already nagged Jack to stick to serious bugfixes for 2.3 final. Since this is an Apple-driven release schedule, all Python gets out of this is a black eye if there's a gross problem preventing Mac OX Whatever users from using 2.3 final. From tim.one@comcast.net Mon Jul 21 02:16:53 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 20 Jul 2003 21:16:53 -0400 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: Message-ID: [Martin] > ... > But gcc is pointing to a real problem. It is just that it cannot, in > general, detect the real problem. Perhaps it can't now, but it *could* know when it's reordering loads and stores, and doing so because of anti-aliasing assumptions. There simply isn't a real problem unless it's doing that (by "real problem" I don't mean a violation of a formal rule, but an actual case of code generation that doesn't match our intent). > As the real problem is wide-spread, By my meaning of "real problem", as I've said before I doubt there are many instances of it. > it makes a best effort approach in guessing what programs might show > undefined behaviour. > > As it turns out, in the case of Python, the compiler is right: There > is undefined behaviour with respect to PyObject*. We could cheat the > compiler to fail to recognize our bad cade, but it still would be bad > code. In the comparisons it's complaining about, casting the comparands to char* first would yield standard-conforming code with the semantics we intend. I haven't seen a real example of anything else in Python it might be worried about (I assume Neil's example was made up), so nothing else to say about those. >> The other question is whether no-strict-aliasing prevents such >> optimizations. > It does. gcc then assumes that any pointer may alias with any other. >> If it does, then we should probably always use it. > We do. Thanks for the confirmation! From skip@pobox.com Mon Jul 21 02:26:57 2003 From: skip@pobox.com (Skip Montanaro) Date: Sun, 20 Jul 2003 20:26:57 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: <1058726864.939.44.camel@anthem> Message-ID: <16155.16737.242631.350308@montanaro.dyndns.org> >> And Jack, are your changes going to make it in by Thursday? Tim> That's an important question! Since the point of releasing by the Tim> end of July is to synch with some Mac deadline, the point is missed Tim> if Jack's changes don't happen. Only if they are significant. The three Jack asked for help on didn't look Earth-shaking to me. Skip From Aki Kubota" This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C34F6C.C14DF5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Im new to this mailing list. And Im interested in Python tools. Stuff you use to make coding easier. like Eclipse for Java. ------=_NextPart_000_0014_01C34F6C.C14DF5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Im new to this mailing list. And = Im interested=20 in Python tools.
Stuff you use to make coding = easier. like=20 Eclipse for Java.
------=_NextPart_000_0014_01C34F6C.C14DF5C0-- From skip@pobox.com Mon Jul 21 04:06:16 2003 From: skip@pobox.com (Skip Montanaro) Date: Sun, 20 Jul 2003 22:06:16 -0500 Subject: [Python-Dev] Python Coding Tools In-Reply-To: <001701c34f29$b331e1b0$503b1cac@hq.ntsp.nec.co.jp> References: <001701c34f29$b331e1b0$503b1cac@hq.ntsp.nec.co.jp> Message-ID: <16155.22696.576520.489167@montanaro.dyndns.org> Aki> Im new to this mailing list. And Im interested in Python tools. Aki> Stuff you use to make coding easier. like Eclipse for Aki> Java. Aki, This isn't the right place to ask such questions. The python-dev list is for discussions about developing Python itself. To ask questions about tools to develop Python programs try python-list@python.org (or the newsgroup twin, comp.lang.python). Skip From martin@v.loewis.de Mon Jul 21 06:16:33 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 21 Jul 2003 07:16:33 +0200 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: Message-ID: "Tim Peters" writes: > > As the real problem is wide-spread, > > By my meaning of "real problem", as I've said before I doubt there are many > instances of it. That might be. What they consider wide-spread is the assumption that you can access the same memory with different incompatible struct types. Atleast the Linux kernel is known to miscompile because of this assumption. Whether most of the programs that are incorrect in this respect also give an opportunity for the optimizer to generate bad code, I don't know. Reportedly, the typical problem is not a bad write order, but a failure to reload a value that the compiler "knows" not to be changed. > In the comparisons it's complaining about, casting the comparands to char* > first would yield standard-conforming code with the semantics we intend. Yes. Indeed, gcc 3.3 offers a type attribute "may_alias", which causes a type to be treated like char* for aliasing purposes. I still think that the non-standards-compliance for Python should be removed in 2.4. If we ever get a bad optimization because of aliasing problems, it will be very time consuming to find the real cause of the problem. So the problem is best avoided to begin with. Regards, Martin From jason@tishler.net Mon Jul 21 13:11:19 2003 From: jason@tishler.net (Jason Tishler) Date: Mon, 21 Jul 2003 08:11:19 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: References: <16151.24705.854058.611883@montanaro.dyndns.org> Message-ID: <20030721121119.GA1664@tishler.net> On Thu, Jul 17, 2003 at 11:37:24PM -0400, Tim Peters wrote: > Partly because of this thing, but mostly because we want to give Jason > a chance to stare at the Cygwin problems. I'm back from being AWOL and will be focusing on this problem... Given the limited time before the expected release date, I will post as soon as I have something to report as oppose to waiting for a final conclusion. Hopefully, this approach will jog something in someone's mind and not irritate others too much. I have started to play the binary search game to determine when the problem began. First, I tried 2.3b2 -- hoping to get lucky. I wasn't, but there is a difference. Instead of tests like test_poll and test_popen just mysteriously causing python to exit without stackdumping (i.e., core dumping), these tests are spinning, consuming all available CPU cycles. Of course, run individually, these test pass. Then, I tried 2.3b1 which ran all tests without exiting or hanging. Only, test_netrc and test_time failed. Hence, the problem was introduced between 2.3b1 and 2.3b2. I will begin the binary search in earnest now... Any thoughts, places to look, etc will be greatly appreciated. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From jason@tishler.net Mon Jul 21 13:13:17 2003 From: jason@tishler.net (Jason Tishler) Date: Mon, 21 Jul 2003 08:13:17 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: References: <20030717204729.GA652@tishler.net> Message-ID: <20030721121317.GB1664@tishler.net> Tim, On Thu, Jul 17, 2003 at 09:16:43PM -0400, Tim Peters wrote: > I've got a bad feeling that we may have a wild store (or such like) in > 2.3. A day or two ago, Jeremy got a senseless and irreproducible > error when running a ZODB test after compiling with 2.3 CVS, and just > now I tried running regrtest with -r on Win98SE (-r randomizes test > case order). That triggered an error I've never seen before and can't > reproduce: > > test test_time failed -- Traceback (most recent call last): > File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime > self.fail('conversion specifier: %r failed.' % format) > File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail > raise self.failureException, msg > AssertionError: conversion specifier: ' %c' failed. Just to confirm, the above is Win32 Python -- not Cygwin. Right? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From jason@tishler.net Mon Jul 21 13:21:39 2003 From: jason@tishler.net (Jason Tishler) Date: Mon, 21 Jul 2003 08:21:39 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <16152.19144.692505.185966@montanaro.dyndns.org> References: <16152.7826.937429.502923@montanaro.dyndns.org> <16152.19144.692505.185966@montanaro.dyndns.org> Message-ID: <20030721122139.GC1664@tishler.net> Skip, On Fri, Jul 18, 2003 at 02:30:16PM -0500, Skip Montanaro wrote: > I then tried (unsuccessfully) another tack. I threw all the test > names into a file then ran > > ./python.exe Lib/test/regrtest.py `head $i tests | tail -20` test_poll > > for $i ranging from 20 to 230 (the number of lines in the file) in > steps of 10. This tickled a fork() problem with test_tempfile in one > situation which seems like the thing rebaseall was supposed to fix. The "all" in rebaseall means all DLLs installed by Cygwin's setup.exe. Since your Python build has not been installed yet, its DLLs have not been rebased. Normally, rebasing /usr/bin/*.dll is sufficient. However, sometimes it's not. If you are interested in helping with the Cygwin hunt, then I can show you how to properly rebase the Python CVS build too. Let me know. Otherwise, I'm back to hunt... Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From amk@amk.ca Mon Jul 21 14:06:58 2003 From: amk@amk.ca (A.M. Kuchling) Date: Mon, 21 Jul 2003 09:06:58 -0400 Subject: [Python-Dev] Re: New branch for r23c2 work References: Message-ID: On Sat, 19 Jul 2003 17:32:52 -0400, Tim Peters wrote: > for a fact that we want the changes in the last 3 files listed. Whoever > changed whatsnew23.tex and modulefinder.py should think about them. The whatsnew23.tex changes added some more text and fixed a minor formatting glitch. They should be safe for 2.3c2, though I'll defer to Fred and/or the release manager if they disagree; otherwise I'll check them in to the branch if given the word. Another change I would like to make before 2.3 final is changing the first paragraph to include the actual release date: "Python 2.3 was released on August 1, 2003..." I can do that as soon as it becomes clear what the final release date will be. I'm not responsible for the modulefinder change, but it's only to a comment: unlikely to be harmful, but equally harmless if deferred to 2.3.1. --amk From kiko@async.com.br Mon Jul 21 15:10:05 2003 From: kiko@async.com.br (Christian Reis) Date: Mon, 21 Jul 2003 11:10:05 -0300 Subject: Be Honest about LC_NUMERIC (PEP proposal), was Re: [Python-Dev] LC_NUMERIC and C libraries In-Reply-To: <1058725765.939.40.camel@anthem> References: <20030715222422.GA3625@async.com.br> <1058725765.939.40.camel@anthem> Message-ID: <20030721141005.GC756@async.com.br> On Sun, Jul 20, 2003 at 02:29:26PM -0400, Barry Warsaw wrote: >=20 > Can we perhaps have a PEP for the 2.4 timeframe? Sure. Reviews would be really appreciated. PEP: XXX Title: Be Honest about LC_NUMERIC (to the C library) Version: $Revision: 1.9 $ Last-Modified: $Date: 2002/08/26 16:29:31 $ Author: Christian R. Reis Status: Draft Type: Standards Track Content-Type: text/plain Created: 19-July-2003 Post-History: =09 ------------------------------------------------------------------------ Abstract =20 Support in Python for the LC_NUMERIC locale category is currently implemented only in Python-space, which causes inconsistent behavior and thread-safety issues for applications that use extension modules and libraries implemented in C. This document proposes a plan for removing this inconsistency by providing and using substitute locale-agnostic functions as necessary. Introduction Python currently provides generic localization services through the locale module, which among other things allows localizing the display and conversion process of numeric types. Locale categories, such as LC_TIME and LC_COLLATE, allow configuring precisely what aspects of the application are to be localized. The LC_NUMERIC category specifies formatting for non-monetary numeric information, such as the decimal separator in float and fixed-precision numbers. Localization of the LC_NUMERIC category is currently implemented in only in Python-space; the C libraries are unaware of the application's LC_NUMERIC setting. This is done to avoid changing the behavior of certain low-level functions that are used by the Python parser and related code [2]. However, this presents a problem for extension modules that wrap C libraries; applications that use these extension modules will inconsistently display and convert numeric values.=20 =20 James Henstridge, the author of PyGTK [3], has additionally pointed out that the setlocale() function also presents thread-safety issues, since a thread may call the C library setlocale() outside of the GIL, and cause Python to function incorrectly. Rationale The inconsistency between Python and C library localization for LC_NUMERIC is a problem for any localized application using C extensions. The exact nature of the problem will vary depending on the application, but it will most likely occur when parsing or formatting a numeric value. Example Problem =20 The initial problem that motivated this PEP is related to the GtkSpinButton [4] widget in the GTK+ UI toolkit, wrapped by PyGTK. The widget can be set to numeric mode, and when this occurs, characters typed into it are evaluated as a number.=20 =20 Because LC_NUMERIC is not set in libc, float values are displayed incorrectly, and it is impossible to enter values using the localized decimal separator (for instance, `,' for the Brazilian locale pt_BR). This small example demonstrates reduced usability for localized applications using this toolkit when coded in Python. Proposal Martin V. L=F6wis commented on the initial constraints for an acceptable solution to the problem on python-dev: - LC_NUMERIC can be set at the C library level without breaking the parser. - float() and str() stay locale-unaware. The following seems to be the current practice: - locale-aware str() and float() [XXX: atof(), currently?] stay in the locale module. An analysis of the Python source suggests that the following functions currently depend on LC_NUMERIC being set to the C locale: - Python/compile.c:parsenumber() - Python/marshal.c:r_object() - Objects/complexobject.c:complex_to_buf() - Objects/complexobject.c:complex_subtype_from_string() - Objects/floatobject.c:PyFloat_FromString() - Objects/floatobject.c:format_float() - Modules/stropmodule.c:strop_atof() - Modules/cPickle.c:load_float() [XXX: still need to check if any other occurrences exist] The proposed approach is to implement LC_NUMERIC-agnostic functions for converting from (strtod()/atof()) and to (snprintf()) float formats, using these functions where the formatting should not vary according to the user-specified locale.=20 =20 This change should also solve the aforementioned thread-safety problems. Potential Code Contributions This problem was initially reported as a problem in the GTK+ libraries [5]; since then it has been correctly diagnosed as an inconsistency in Python's implementation. However, in a fortunate coincidence, the glib library implements a number of LC_NUMERIC-agnostic functions (for an example, see [6]) for reasons similar to those presented in this paper. In the same GTK+ problem report, Havoc Pennington has suggested that the glib authors would be willing to contribute this code to the PSF, which would simplify implementation of this PEP considerably. [XXX: I believe the code is cross-platform, since glib in part was devised to be cross-platform. Needs checking.] [XXX: I will check if Alex Larsson is willing to sign the PSF contributor agreement [7] to make sure the code is safe to integrate.] Risks There may be cross-platform issues with the provided locale-agnostic functions. This needs to be tested further. Martin has pointed out potential copyright problems with the contributed code. I believe we will have no problems in this area as members of the GTK+ and glib teams have said they are fine with relicensing the code. Code An implementation is being developed by Gustavo Carneiro=20 . It is currently attached to Sourceforge.net bug 744665 [8] [XXX: The SF.net tracker is horrible 8(] References [1] PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton http://www.python.org/peps/pep-0001.html [2] Python locale documentation for embedding, http://www.python.org/doc/current/lib/embedding-locale.html [3] PyGTK homepage, http://www.daa.com.au/~james/pygtk/ [4] GtkSpinButton screenshot (demonstrating problem),=20 http://www.async.com.br/~kiko/spin.png [5] GNOME bug report, http://bugzilla.gnome.org/show_bug.cgi?id=3D114= 132 [6] Code submission of g_ascii_strtod and g_ascii_dtostr (later renamed g_ascii_formatd) by Alex Larsson,=20 http://mail.gnome.org/archives/gtk-devel-list/2001-October/msg001= 14.html [7] PSF Contributor Agreement,=20 http://www.python.org/psf/psf-contributor-agreement.html [8] Python bug report, http://www.python.org/sf/774665 Copyright This document has been placed in the public domain. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From Jack.Jansen@cwi.nl Mon Jul 21 15:23:53 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 21 Jul 2003 16:23:53 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: Message-ID: On zondag, jul 20, 2003, at 21:51 Europe/Amsterdam, Tim Peters wrote: >> And Jack, are your changes going to make it in by Thursday? > > That's an important question! Since the point of releasing by the end > of > July is to synch with some Mac deadline, the point is missed if Jack's > changes don't happen. I'm going to try to get my changes in by today. If there's something really serious I may need tomorrow too (tomorrownight that is, MET), but I hope to have everything done today. I'll let you know. Also, if there are no other issues coming up (and assuming this idea fits in with other people's schedules) I would be in favor of a more aggressive rc2/final timeline, something like Wed 23 for rc2 and Mon 28 for final. I'm not sure how Apple's scheduling works, but it would be a shame if their timetable is cast-in-concrete, and we miss it because of a random fluke like a network outage on thursday 31, or unavailability of some key person on our side, or some such. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From Jack.Jansen@cwi.nl Mon Jul 21 15:27:03 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 21 Jul 2003 16:27:03 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: Message-ID: <65E00892-BB87-11D7-9366-000A27B19B96@cwi.nl> On zondag, jul 20, 2003, at 23:36 Europe/Amsterdam, Martin v. L=F6wis=20 wrote: > "Tim Peters" writes: > >> That's an important question! Since the point of releasing by the=20 >> end of >> July is to synch with some Mac deadline, the point is missed if = Jack's >> changes don't happen. > > I'm not so sure about that. I'd like to urge Jack to seriously > reconsider what work necessarily has to be done to avoid a completely > unusable release, and do any other work that also should be done only > after the release. Don't worry. I'm of a mind to pass on the three bugs in the build=20 process (two seem to be innocuous, according to Skip, and the third one=20= came from Apple but they already have a workaround they used with=20 2.3b1), and the remaining bugs are very localized: in the Package=20 Manager and in the procedure used to build the binary installer. -- - Jack Jansen =20 http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma=20 Goldman - From barry@python.org Mon Jul 21 15:26:50 2003 From: barry@python.org (Barry Warsaw) Date: 21 Jul 2003 10:26:50 -0400 Subject: [Python-Dev] New branch for r23c2 work (IMPORTANT) In-Reply-To: References: Message-ID: <1058797610.2036.8.camel@yyz> On Sun, 2003-07-20 at 15:51, Tim Peters wrote: > > I'm confused by this message though: are you volunteering to port > > r23c1-branch to the head > > Somebody has to, but nobody has volunteered yet . > > > so we can do the rc2 and then 2.3 final releases from the head? > > The release is stretching out, so I didn't intend to release c2 or final > from the head. The intent: See? You go on vacation for a week and everything goes to hell. :) I don't like that at the end of this process that we're going to be doing 2.3 maint on a branch of a branch of a branch. IMPORTANT: Do not do 2.4 work on the head! The remnants of Pylabs just came to concensus <3 wink>. We're going to release 2.3 rc2 and final from the head. Tim is right now merging the r23c1-branch back to the head. If people want to start working on 2.4 now, we can create a short-lived branch for that work until 2.3 final goes out. At that point, we'll create a 23-maint branch from the head and do all the point-releases of 2.3 from that. Then, if necessary, we can merge the 2.4-branch back to the head. So, if your name isn't 3 letters long and doesn't start with T and end with m, please ignore the r23c1-branch. Let me know if you have a burning desire to do 2.4 work now and I'll create a branch for it. -Barry From Anthony Baxter Mon Jul 21 15:39:13 2003 From: Anthony Baxter (Anthony Baxter) Date: Tue, 22 Jul 2003 00:39:13 +1000 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <65E00892-BB87-11D7-9366-000A27B19B96@cwi.nl> Message-ID: <200307211439.h6LEdECc006696@localhost.localdomain> Could someone have a quick look at 774751 and decide if it's worth spending time on before rc2? (synopsis: sometime between 2.1 and 2.2, binding to a socket on MacOS X started taking a long long long time.) Anthony -- = Anthony Baxter = It's never too late to have a happy childhood. From barry@python.org Mon Jul 21 15:47:05 2003 From: barry@python.org (Barry Warsaw) Date: 21 Jul 2003 10:47:05 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: Message-ID: <1058798825.2036.19.camel@yyz> On Mon, 2003-07-21 at 10:23, Jack Jansen wrote: > I'm going to try to get my changes in by today. If there's something > really serious I may need tomorrow too (tomorrownight that is, MET), > but I hope to have everything done today. I'll let you know. Cool, that's fine. I'll sleep well knowing that it'll all be done by the time I wake up Wednesday morning. :) > Also, if there are no other issues coming up (and assuming this idea > fits in with other people's schedules) I would be in favor of a more > aggressive rc2/final timeline, something like Wed 23 for rc2 I don't think we're going to be able to do a release on Wednesday. I think we'll be traveling to Zope World HQ and I'll be way too tired when we get back to cut the release. Let's stick with Thursday. We can re-evaluate whether that needs to be rc2 or can be 2.3 final sometime Wednesday night EDT. After getting caught up from Tim and Fred, here's what I see outstanding: - test_logging vs. the locale vs. test_strptime My understanding here is that Jeremy's patch isn't the right fix, but that nobody knows 1) why test_logging is mucking with the locale, 2) what the right fix actually is. If I can reproduce the original problem, I want to see if removing the locale setting in test_logging "fixes" the problem. I suspect that non-us native locales could get hosed though so we'll need confirmation before that one could go in. - Jack's Mac changes. Sounds like Jack's got this one under control. - Jason Tishler vs. cygwin. Tim tells me that the cygwin builds have suddenly and mysteriously started breaking. Could be a bug in Python or in cygwin. Hopefully Jason can debug this and get a fix in, but I don't want to hold up 2.3c2 or 2.3 final for this. If there's anything else I'm missing, please be sure to let me know asap, or submit a priority > 7 bug report on SF. > and Mon 28 > for final. I'm not sure how Apple's scheduling works, but it would be a > shame if their timetable is cast-in-concrete, and we miss it because of > a random fluke like a network outage on thursday 31, or unavailability > of some key person on our side, or some such. Oh c'mon, don't be a pessimist! SF could never have a day-long outage of CVS just at the critical time! :) Good point, and I'm willing to push the final release forward a few days if c2 looks good on Thursday. If Monday's too early, we could shoot for Tuesday or Wednesday. Let's see how c2 looks. -Barry From barry@python.org Mon Jul 21 16:08:45 2003 From: barry@python.org (Barry Warsaw) Date: 21 Jul 2003 11:08:45 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <200307211439.h6LEdECc006696@localhost.localdomain> References: <200307211439.h6LEdECc006696@localhost.localdomain> Message-ID: <1058800125.2036.21.camel@yyz> On Mon, 2003-07-21 at 10:39, Anthony Baxter wrote: > Could someone have a quick look at 774751 and decide if it's worth > spending time on before rc2? (synopsis: sometime between 2.1 and 2.2, > binding to a socket on MacOS X started taking a long long long time.) I'll take a look in a little while. -Barry From tim.one@comcast.net Mon Jul 21 16:28:17 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 21 Jul 2003 11:28:17 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <20030721121317.GB1664@tishler.net> Message-ID: [Tim] >> I've got a bad feeling that we may have a wild store (or such like) >> in 2.3. A day or two ago, Jeremy got a senseless and irreproducible >> error when running a ZODB test after compiling with 2.3 CVS, and just >> now I tried running regrtest with -r on Win98SE (-r randomizes test >> case order). That triggered an error I've never seen before and >> can't reproduce: >> >> test test_time failed -- Traceback (most recent call last): >> File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in >> test_strptime self.fail('conversion specifier: %r failed.' % >> format) File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail >> raise self.failureException, msg >> AssertionError: conversion specifier: ' %c' failed. [Jason Tishler] > Just to confirm, the above is Win32 Python -- not Cygwin. Right? Yes, it was Win32 Python -- and also Jeremy's Linux. It "got fixed" by focing the locale to "C" at the end of test_logging.py. That's probably not a correct fix, just a bandaid. Brett is on vacation, and I have no real idea what strptime is trying to do with locale; it appears to be a bug that strptime tries to be locale-independent but that the strptime test in test_time.py fails if test_logging (which changes the locale) isn't hacked to force locale (back?) to "C" at its end. From skip@pobox.com Mon Jul 21 16:34:40 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 21 Jul 2003 10:34:40 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <200307211439.h6LEdECc006696@localhost.localdomain> References: <65E00892-BB87-11D7-9366-000A27B19B96@cwi.nl> <200307211439.h6LEdECc006696@localhost.localdomain> Message-ID: <16156.2064.781257.761849@montanaro.dyndns.org> Anthony> Could someone have a quick look at 774751 and decide if it's Anthony> worth spending time on before rc2? (synopsis: sometime between Anthony> 2.1 and 2.2, binding to a socket on MacOS X started taking a Anthony> long long long time.) I took the proverbial quick look. It appears the call to getsockaddrarg is taking all the time. I added some calls to gettimeofday surrounding the bits of functionality in sock_bind: struct timeval t; long usec; gettimeofday(&t, NULL); usec = t.tv_usec; if (!getsockaddrarg(s, addro, &addr, &addrlen)) return NULL; gettimeofday(&t, NULL); fprintf(stderr, "getsockaddrarg: %d\n", (t.tv_usec-usec)); gettimeofday(&t, NULL); usec = t.tv_usec; Py_BEGIN_ALLOW_THREADS res = bind(s->sock_fd, addr, addrlen); Py_END_ALLOW_THREADS gettimeofday(&t, NULL); fprintf(stderr, "bind+threads: %d\n", (t.tv_usec-usec)); and get this sort of output running on my Powerbook: getsockaddrarg: 139824 bind+threads: 30 getsockaddrarg: 139884 bind+threads: 17 getsockaddrarg: 138592 bind+threads: 17 getsockaddrarg: 139504 bind+threads: 19 Instrumenting Python 2.2.3 sock_bind on a Linux machine generates this sort of output: getsockaddrarg: 13 bind+threads: 7 getsockaddrarg: 14 bind+threads: 8 getsockaddrarg: 14 bind+threads: 8 getsockaddrarg: 15 bind+threads: 7 getsockaddrarg: 14 bind+threads: 7 Moving the time checks into getsockaddrarg generates this output on my Powerbook: tuple check: 4 parse tuple: 26 setipaddr: 141153 htons: 3 Looking at setipaddr I see that Just added some lock acquisition code in May: 1.265 (jvr 09-May-03): Py_BEGIN_ALLOW_THREADS 1.265 (jvr 09-May-03): ACQUIRE_GETADDRINFO_LOCK 1.153 (loewis 21-Jul-01): error = getaddrinfo(NULL, "0", &hints, &res); 1.265 (jvr 09-May-03): Py_END_ALLOW_THREADS 1.265 (jvr 09-May-03): /* We assume that those thread-unsafe getaddrinfo() versions 1.265 (jvr 09-May-03): *are* safe regarding their return value, ie. that a 1.265 (jvr 09-May-03): subsequent call to getaddrinfo() does not destroy the 1.265 (jvr 09-May-03): outcome of the first call. */ 1.265 (jvr 09-May-03): RELEASE_GETADDRINFO_LOCK revision 1.265 date: 2003/05/09 07:53:18; author: jvr; state: Exp; lines: +45 -10 [ 731644] & [ 604210 ] Release the GIL around getaddrinfo(), yet protect access with lock on those platforms that getaddrinfo() isn't (known to be) thread-safe. Thanks to MvL for mentoring this patch. Without digging deeper, I'm going to suggest that's the culprit. I'll leave it to others to figure out what can be done. Skip From skip@pobox.com Mon Jul 21 16:36:47 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 21 Jul 2003 10:36:47 -0500 Subject: [Python-Dev] cygwin errors In-Reply-To: <20030721122139.GC1664@tishler.net> References: <16152.7826.937429.502923@montanaro.dyndns.org> <16152.19144.692505.185966@montanaro.dyndns.org> <20030721122139.GC1664@tishler.net> Message-ID: <16156.2191.354230.898161@montanaro.dyndns.org> Jason> Normally, rebasing /usr/bin/*.dll is sufficient. However, Jason> sometimes it's not. If you are interested in helping with the Jason> Cygwin hunt, then I can show you how to properly rebase the Jason> Python CVS build too. Let me know. Otherwise, I'm back to Jason> hunt... If it's not too much trouble. It's unlikely I'll be able to contribute anything useful though. Skip From fdrake@acm.org Mon Jul 21 16:41:23 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 21 Jul 2003 11:41:23 -0400 Subject: [Python-Dev] Re: New branch for r23c2 work In-Reply-To: References: Message-ID: <16156.2467.299506.419245@grendel.zope.com> A.M. Kuchling writes: > The whatsnew23.tex changes added some more text and fixed a minor > formatting glitch. > They should be safe for 2.3c2, though I'll defer to Fred and/or the release > manager > if they disagree; otherwise I'll check them in to the branch if given the > word. These changes should go in rc2. > Another change I would like to make before 2.3 final is changing the first > paragraph to include the actual release date: "Python 2.3 was released on > August 1, 2003..." I can do that as soon as it becomes clear what the > final release date will be. That's fine. Checking that should be part of the release procedure PEP; please update PEP 101 accordingly. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tim.one@comcast.net Mon Jul 21 16:53:34 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 21 Jul 2003 11:53:34 -0400 Subject: [Python-Dev] Re: New branch for r23c2 work In-Reply-To: Message-ID: [Andrew] > The whatsnew23.tex changes added some more text and fixed a minor > formatting glitch. They should be safe for 2.3c2, though I'll defer > to Fred and/or the release manager if they disagree; otherwise I'll > check them in to the branch if given the word. Provided you want these changes (fine by me!), there's nothing more for = you to do -- they're already where they need to be for 2.3c2. > Another change I would like to make before 2.3 final is changing the > first paragraph to include the actual release date: "Python 2.3 was > released on August 1, 2003..." I can do that as soon as it becomes > clear what the final release date will be. No problem. > I'm not responsible for the modulefinder change, but it's only to a > comment: unlikely to be harmful, but equally harmless if deferred to > 2.3.1.=20 It's already in, so thanks for checking its harmlessness. From barry@python.org Mon Jul 21 18:06:31 2003 From: barry@python.org (Barry Warsaw) Date: 21 Jul 2003 13:06:31 -0400 Subject: [Python-Dev] bsddb3 test hang Message-ID: <1058807191.2036.76.camel@yyz> I just did a fresh cvs up, configure, build and am running the test suite with TESTOPTS='-u all -v'. It looks like I'm getting a hang in test_bsddb3 on RH9. Running test_bsddb3 alone works just fine. The hang happens at: test02_SimpleLocks (bsddb.test.test_thread.BTreeSimpleThreaded) ... ok So I don't know if it's this test or the next one. I don't have time at the moment to dig further, but one useful thing would be to see if Martin's last checkin to _bsddb.c has any effect. strace-ing the process gives me: % strace -p 26615 futex(0x82fb8c0, FUTEX_WAIT, 0, NULL -Barry From jason@tishler.net Mon Jul 21 19:02:49 2003 From: jason@tishler.net (Jason Tishler) Date: Mon, 21 Jul 2003 14:02:49 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <20030721121119.GA1664@tishler.net> References: <16151.24705.854058.611883@montanaro.dyndns.org> <20030721121119.GA1664@tishler.net> Message-ID: <20030721180249.GG1664@tishler.net> On Mon, Jul 21, 2003 at 08:11:19AM -0400, Jason Tishler wrote: > I have started to play the binary search game to determine when the > problem began. Ding, ding, ding! We have a winner: http://sf.net/tracker/?group_id=5470&atid=305470&func=detail&aid=742741 The above patch enables HAVE_PTHREAD_SIGMASK under Cygwin which was not enabled before. I just tried the following with 2.3c1: $ configure ... $ # edit pyconfig.h to #undef HAVE_PTHREAD_SIGMASK $ make $ ./python.exe -E -tt ../Lib/test/regrtest.py -l test_grammar [snip] test_zlib 221 tests OK. 2 tests failed: test_netrc test_time 32 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_ioctl test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 1 skip unexpected on cygwin: test_ioctl Scanning the Cygwin code, I found the following: extern "C" int pthread_sigmask (int operation, const sigset_t *set, sigset_t *old_set) { pthread *thread = pthread::self (); // lock this myself, for the use of thread2signal ***> // two differt kills might clash: FIXME [snip] } Hence, it seems that my hypothesis that a Python change was tickling a Cygwin bug (i.e., the above FIXME or another issue) is correct. So, the question is how should we deal with this issue? 1. Leave the Python code base alone and assume that Cygwin's pthread_sigmask() will get fixed. Additionally, assume I will patch around this problem until that happens. 2. Patch the Python code base so that HAVE_PTHREAD_SIGMASK is undefined under Cygwin. I recommend option #1. Do others agree? Did I miss any other options? BTW, does anyone know if Python is triggering the FIXME in Cygwin's pthread_sigmask()? Or, should I look elsewhere? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From jason@tishler.net Mon Jul 21 19:17:53 2003 From: jason@tishler.net (Jason Tishler) Date: Mon, 21 Jul 2003 14:17:53 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <16156.2191.354230.898161@montanaro.dyndns.org> References: <16152.7826.937429.502923@montanaro.dyndns.org> <16152.19144.692505.185966@montanaro.dyndns.org> <20030721122139.GC1664@tishler.net> <16156.2191.354230.898161@montanaro.dyndns.org> Message-ID: <20030721181753.GH1664@tishler.net> Skip, On Mon, Jul 21, 2003 at 10:36:47AM -0500, Skip Montanaro wrote: > Jason> Normally, rebasing /usr/bin/*.dll is sufficient. However, > Jason> sometimes it's not. If you are interested in helping with the > Jason> Cygwin hunt, then I can show you how to properly rebase the > Jason> Python CVS build too. Let me know. Otherwise, I'm back to > Jason> hunt... > > If it's not too much trouble. It's unlikely I'll be able to > contribute anything useful though. Since I think I have isolated the Cygwin Python problem, I would prefer to hold off on the above. My intention is to enhance rebaseall (and in turn rebase) so that rebasing additionally DLLs is easy. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From fdrake@acm.org Mon Jul 21 20:02:50 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 21 Jul 2003 15:02:50 -0400 Subject: [Python-Dev] post-release festivities In-Reply-To: References: <007b01c34d7b$827c3480$f7bc2c81@oemcomputer> Message-ID: <16156.14554.31900.910218@grendel.zope.com> Raymond Hettinger: > All that was being contemplated was fixing some URLs in > the docs and adding more examples. That can wait for another day. If there are broken URLs, this is the time to fix them. Please submit a bug to SF, assign to me, and set priority to 7. If I don't like the patch, I'll reject it or lower the priority. New examples should be handled separately; you can just check those in after the release (or use a branch if you really want to check them in). -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tim.one@comcast.net Mon Jul 21 20:55:31 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 21 Jul 2003 15:55:31 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <20030721180249.GG1664@tishler.net> Message-ID: [Jason Tishler] > Ding, ding, ding! We have a winner: Congratulations! > http://sf.net/tracker/?group_id=5470&atid=305470&func=detail&aid=742741 > > The above patch enables HAVE_PTHREAD_SIGMASK under Cygwin which was > not enabled before. > > ... > > Scanning the Cygwin code, I found the following: > > extern "C" int > pthread_sigmask (int operation, const sigset_t *set, sigset_t > *old_set) > { > pthread *thread = pthread::self (); > > // lock this myself, for the use of thread2signal > ***> // two differt kills might clash: FIXME > [snip] > } > > Hence, it seems that my hypothesis that a Python change was tickling a > Cygwin bug (i.e., the above FIXME or another issue) is correct. > > So, the question is how should we deal with this issue? > > 1. Leave the Python code base alone and assume that Cygwin's > pthread_sigmask() will get fixed. Additionally, assume I will > patch around this problem until that happens. > 2. Patch the Python code base so that HAVE_PTHREAD_SIGMASK is > undefined under Cygwin. > > I recommend option #1. Do others agree? I don't know. It seems the only effect of HAVE_PTHREAD_SIGMASK is to decide whether Python uses pthread_sigmask() or sigprocmask(). If the latter works but the former doesn't, I would have guessed you'd like to use the latter . > Did I miss any other options? > > BTW, does anyone know if Python is triggering the FIXME in Cygwin's > pthread_sigmask()? Sorry, no idea. > Or, should I look elsewhere? Ditto. From johnfabel@btinternet.com Mon Jul 21 21:07:36 2003 From: johnfabel@btinternet.com (John Abel) Date: Mon, 21 Jul 2003 21:07:36 +0100 Subject: [Python-Dev] PyConfig.h On Solaris Message-ID: <3F1C4808.2090102@btinternet.com> Hi, I apologise if this is an inappropriate post for this list; my query is concerned with the internals of Python, honest :) I am trying to compile a C module on Solaris, to return extended process information (args greater than 80 characters). However, the _FILE_OFFSET_BITS in pyconfig.h is causing me a bit of bother. It is preventing me, from correctly parsing /proc - according to the man pages, any handling of /proc entries must be done with 32bit structures, variables, etc. I've tried undefining it at compile time, without success. I've had to define _LP64, include , then undefine _LP64. Doing this, allows me to use structured proc, instead of the deprecatd ioctl method. However, I don't think this is a working solution, as the code compiles, runs, but returns dubious results (I have a pure C version of the code, which works fine). I've included the code below. Is there a way, to tell Python to compile a module in 32bit mode? Or, is there a workaround for this Solaris oddity? Regards John #include "Python.h" #include #define _LP64 #include #undef _LP64 #include #include #include static PyObject * psinfo_fullpidinfo(PyObject *self, PyObject *args) { PyObject *queryPid; char procBuf[50]; char argStr[512]; char **argvp; int fdPSInfoFile, fdASFile, counter; struct psinfo psBuf; if (!PyArg_ParseTuple(args, "i:pidinfo", &queryPid) ) { return NULL; } (void)sprintf(procBuf,"/proc/%i/psinfo", (int)queryPid); (void)sprintf(asBuf,"/proc/%i/as", (int)queryPid); if ((fdPSInfoFile = open(procBuf, O_RDONLY)) != -1 ) { if (read(fdPSInfoFile, &psBuf, sizeof(struct psinfo)) == sizeof(struct psinfo) ) { close(fdPSInfoFile); if ((fdASFile = open(asBuf, O_RDONLY)) == -1 ) { printf(" Open Of AS Failed"); } else { printf( "%d", psBuf.pr_argc); argvp=(char **) malloc(sizeof(char *) * (psBuf.pr_argc + 1)); if (lseek(fdASFile, psBuf.pr_argv, SEEK_SET) == -1) { printf ("Initial LSeek Failed" ); return NULL; } if (read(fdASFile, argvp, sizeof(char *) * (psBuf.pr_argc + 1)) == -1 ) { printf( "Read Failed" ); return NULL; } for ( counter=0; counter < psBuf.pr_argc; counter++ ) { if (lseek(fdASFile, argvp[ counter ], SEEK_SET) == -1) { printf( "2nd LSeek Failed"); return NULL; } if (read(fdASFile, argStr, 512) == -1) { printf( "Read Of AS File Failed"); return NULL; } printf( "Got %s.\n", argStr ); } close(fdASFile); } } } return Py_BuildValue( "s", argStr ); } static struct PyMethodDef PSInfoMethods[]={ { "fullpidinfo", psinfo_fullpidinfo, METH_VARARGS, "Display Full Arg Details For A Given PID" }, { NULL, NULL, 0, NULL } }; void initpsinfo(void) { (void)Py_InitModule("psinfo", PSInfoMethods); } From jason@tishler.net Mon Jul 21 21:27:49 2003 From: jason@tishler.net (Jason Tishler) Date: Mon, 21 Jul 2003 16:27:49 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: References: <20030721180249.GG1664@tishler.net> Message-ID: <20030721202749.GC2260@tishler.net> On Mon, Jul 21, 2003 at 03:55:31PM -0400, Tim Peters wrote: > [Jason Tishler] > > So, the question is how should we deal with this issue? > > > > 1. Leave the Python code base alone and assume that Cygwin's > > pthread_sigmask() will get fixed. Additionally, assume I > > will patch around this problem until that happens. > > 2. Patch the Python code base so that HAVE_PTHREAD_SIGMASK is > > undefined under Cygwin. > > > > I recommend option #1. Do others agree? > > I don't know. It seems the only effect of HAVE_PTHREAD_SIGMASK is to > decide whether Python uses pthread_sigmask() or sigprocmask(). If the > latter works but the former doesn't, I would have guessed you'd like > to use the latter . Yup! But, would such a Cygwin specific change be accepted so close to the release date? This is one of the reasons that I recommended option #1. Any other opinions? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From tim.one@comcast.net Mon Jul 21 22:01:35 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 21 Jul 2003 17:01:35 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <20030721202749.GC2260@tishler.net> Message-ID: [Tim] >> It seems the only effect of HAVE_PTHREAD_SIGMASK is to decide >> whether Python uses pthread_sigmask() or sigprocmask(). If >> the latter works but the former doesn't, I would have guessed you'd >> like to use the latter . [Jason Tishler] > Yup! But, would such a Cygwin specific change be accepted so close to > the release date? If the Cygwin-specific part is (as it seemed to me) isolated to the only line in the codebase that tests HAVE_PTHREAD_SIGMASK, I think the risk is too small to worry about. In one real sense, the HAVE_PTHREAD_SIGMASK patch introduced bugs, causing a formerly-working platform to fall over. > This is one of the reasons that I recommended option #1. Any other > opinions? Barry is the release manager again, so only his counts. Well, his and yours. OK, his, yours, and mine. OK, if you want to push it, his, yours, mine and Guido's. That's it, though. Unless you want to count Jeremy too. I suppose we should! OK, the only opinions that count are Skip's, Barry's, yours, Tim's, Jeremy's and Guido's. We shouldn't leave Jack out, should we? For sure, the only opinions that count are Fred's. From barry@python.org Mon Jul 21 22:14:33 2003 From: barry@python.org (Barry Warsaw) Date: 21 Jul 2003 17:14:33 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: References: Message-ID: <1058822073.2036.140.camel@yyz> On Mon, 2003-07-21 at 17:01, Tim Peters wrote: > > [Jason Tishler] > > Yup! But, would such a Cygwin specific change be accepted so close to > > the release date? > > If the Cygwin-specific part is (as it seemed to me) isolated to the only > line in the codebase that tests HAVE_PTHREAD_SIGMASK, I think the risk is > too small to worry about. In one real sense, the HAVE_PTHREAD_SIGMASK patch > introduced bugs, causing a formerly-working platform to fall over. I'd agree. This isn't hurting any other platform, so hacking configure for this test on cygwin seems of minimal pain. The potential for other OS breakage is smaller the sooner you do it. > > > This is one of the reasons that I recommended option #1. Any other > > opinions? > > Barry is the release manager again, so only his counts. Well, his and > yours. OK, his, yours, and mine. OK, if you want to push it, his, yours, > mine and Guido's. That's it, though. Unless you want to count Jeremy too. > I suppose we should! OK, the only opinions that count are Skip's, Barry's, > yours, Tim's, Jeremy's and Guido's. We shouldn't leave Jack out, should we? > For sure, the only opinions that count are Fred's. The only opinion that matters to me is our new Pylabs boss Frank Lomax, who, while being a genius, smells funny. He says to go for it, but I'm not sure if he was talking about this patch, or about eating the patch of chocolate pudding on his sleeve. 50/50. -Barry From skip@pobox.com Mon Jul 21 22:56:14 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 21 Jul 2003 16:56:14 -0500 Subject: [Python-Dev] Need help with the slow bind on Mac OS X problem Message-ID: <16156.24958.238410.726935@montanaro.dyndns.org> I need some help with . Jack assigned it to me. I'll take a stab at it, but I need a bit of guidance from someone who understands the code a bit better. In particular, there are two chunks of code near the top of socketmodule.c which seem to be interfering with my attempts to craft a fix. First, there's code to determine whether or not the lock is required: /* On systems on which getaddrinfo() is believed to not be thread-safe, (this includes the getaddrinfo emulation) protect access with a lock. */ #if defined(WITH_THREAD) && (defined(__APPLE__) || defined(__FreeBSD__) || \ defined(__OpenBSD__) || defined(__NetBSD__) || !defined(HAVE_GETADDRINFO)) #define USE_GETADDRINFO_LOCK #endif #ifdef USE_GETADDRINFO_LOCK #define ACQUIRE_GETADDRINFO_LOCK PyThread_acquire_lock(netdb_lock, 1); #define RELEASE_GETADDRINFO_LOCK PyThread_release_lock(netdb_lock); #else #define ACQUIRE_GETADDRINFO_LOCK #define RELEASE_GETADDRINFO_LOCK #endif This is fine as far as it goes I suspect, however, later on, in certain cases HAVE_GETADDRINFO is #undef'd: #ifdef __APPLE__ /* On OS X, getaddrinfo returns no error indication of lookup failure, so we must use the emulation instead of the libinfo implementation. Unfortunately, performing an autoconf test for this bug would require DNS access for the machine performing the configuration, which is not acceptable. Therefore, we determine the bug just by checking for __APPLE__. If this bug gets ever fixed, perhaps checking for sys/version.h would be appropriate, which is 10/0 on the system with the bug. */ #ifndef HAVE_GETNAMEINFO /* This bug seems to be fixed in Jaguar. Ths easiest way I could Find to check for Jaguar is that it has getnameinfo(), which older releases don't have */ #undef HAVE_GETADDRINFO #endif #endif I am running 10.2.6 (Jaguar), so compilation doesn't reach the #undef directive. This means I'm not using the fake_getaddrinfo, however I still have the *_GETADDRINFO_LOCKs defined. It seems to me that perhaps the fake_getaddrinfo code should be used on Mac OS X in all cases. Either it's < 10.2.6 and thus has a broken getaddrinfo, or its >= 10.2.6 in which case it still has a getaddrinfo which is likely not to be thread-safe. That requires more restructuring of socketmodule.c's tests than I'm comfortable with at this late date. I will try to craft a patch and attach it to the above tracker item, but I need some people to both look at it and try it out. Thanks, Skip From martin@v.loewis.de Mon Jul 21 23:06:26 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 00:06:26 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <16156.2064.781257.761849@montanaro.dyndns.org> References: <65E00892-BB87-11D7-9366-000A27B19B96@cwi.nl> <200307211439.h6LEdECc006696@localhost.localdomain> <16156.2064.781257.761849@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > Without digging deeper, I'm going to suggest that's the culprit. I'll leave > it to others to figure out what can be done. Interestingly enough, this change was implemented to improve the performance of name lookup, by releasing the GIL while perform name lookup. Just thinks that getaddrinfo is not thread-safe on OSX, so it needs to use a lock around getaddrinfo. It is surprising that this has caused a slow-down, in particular on a non-threaded application. If there was a bug in this code, I had expected that to cause a deadlock, instead of causing a slow-down. Regards, Martin From martin@v.loewis.de Mon Jul 21 23:15:48 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 00:15:48 +0200 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: <1058807191.2036.76.camel@yyz> References: <1058807191.2036.76.camel@yyz> Message-ID: Barry Warsaw writes: > % strace -p 26615 > futex(0x82fb8c0, FUTEX_WAIT, 0, NULL NPTL. 'Nuff said. Regards, Martin P.S. Perhaps not: NPTL is the New Posix Threads Library, and it is an attempt to make pthreads both standards-conforming and efficient on Linux, by providing more kernel support, and building the library on tof of this kernel support; the futex syscall is one of the extensions. The NGPTL version of pthreads is supposed to be binary-compatible with the old LinuxThreads library. Unfortunately, there appears to be a number of inconsistencies, which might be bugs in the application, bugs in NPTL, or mere failure to provide binary compatibility. For some reason, Redhat decided to include NPTL with Redhat 9, even though it hasn't been released yet. Unless you want to determine the cause of this problem, I recommend to turn off NPTL. There is some magic environment variable that allows to do that (LD_ASSUME_KERNEL), see http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/release-notes/x86/ From martin@v.loewis.de Mon Jul 21 23:25:36 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 00:25:36 +0200 Subject: [Python-Dev] PyConfig.h On Solaris In-Reply-To: <3F1C4808.2090102@btinternet.com> References: <3F1C4808.2090102@btinternet.com> Message-ID: John Abel writes: > Is there a way, to tell Python to compile a module in 32bit mode? You could edit pyconfig.h after configuring but before compiling Python. I would advise against doing so. > Or, is there a workaround for this Solaris oddity? You could split your code into two files, with LFS-independent data structures in-between them. IOW, define JA_psinfo_t, which has just the fields of psinfo_t that you are interested in, using LFS-independent data types. In the source file opening /proc, copy all interesting fields in the data structure pointed-to by the caller, and compile this without LFS. Then, in the Python module proper, call these helper functions, passing JA_psinfo_t. AFAICT, it is only priovec_t, anyway, which is affected by the incompatibility, so if you don't use that, you could just pass psinfo_t through. I might be wrong here, though. Regards, Martin From skip@pobox.com Mon Jul 21 23:36:37 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 21 Jul 2003 17:36:37 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: <65E00892-BB87-11D7-9366-000A27B19B96@cwi.nl> <200307211439.h6LEdECc006696@localhost.localdomain> <16156.2064.781257.761849@montanaro.dyndns.org> Message-ID: <16156.27381.925389.777799@montanaro.dyndns.org> Martin> Just thinks that getaddrinfo is not thread-safe on OSX, so it Martin> needs to use a lock around getaddrinfo. I've been thusfar unable to get the code in getaddrinfo.c to compile as part of socketmodule.c (errors about missing #defines and struct members). Unless maybe Barry or Jack can figure out what the problem is, I think solving this particular performance problem may have to wait until after the 2.3 release. Martin> It is surprising that this has caused a slow-down, in particular Martin> on a non-threaded application. If there was a bug in this code, Martin> I had expected that to cause a deadlock, instead of causing a Martin> slow-down. It looks like the Mac OS X implementation of getaddrinfo is just dog slow. I instrumented setipaddr with calls to gettimeofday() to see how long different sections took. It turns out that getaddrinfo() is hideously slow: start: 5 acquire: 11 getaddrinfo: 159754 release: 14 switch: 5 (the numbers above are microseconds). "start" is the time before either lock is acquired and "switch" is the time after both locks are released. Maybe the solution for the common case is easier. In the common case of: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) when you get into setipaddr() name[0] will always be '\0' and so you'll take the first branch. Do you need all of getaddrinfo()'s bells and whistles to properly set up addr_ret in this case? At worst, can't the getaddrinfo() call be made once and then cached? Skip From barry@python.org Mon Jul 21 23:44:53 2003 From: barry@python.org (Barry Warsaw) Date: 21 Jul 2003 18:44:53 -0400 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: References: <1058807191.2036.76.camel@yyz> Message-ID: <1058827492.2036.214.camel@yyz> On Mon, 2003-07-21 at 18:15, Martin v. L=F6wis wrote: > Barry Warsaw writes: >=20 > > % strace -p 26615 > > futex(0x82fb8c0, FUTEX_WAIT, 0, NULL >=20 > NPTL. 'Nuff said. Perhaps, but there's more: Tim, Fred, and I spent some time running tests, turning on verbosity, etc. I can only reproduce the hang if I run % make TESTOPTS=3D"-u all" test and then it hangs almost every time, the second pass through the tests.=20 It can't be interrupted. If I turn on -v or hack the test to be slightly more verbose, or use a less inclusive -u option, it never hangs. So clearly there's some timing issue in the tests. Tim has had a little more luck on Windows by adding some verbosity and watching it hang in dbutils.DeadlockWrap() -- or actually infloop in that function's while 1. This comes from bsddb/test/test_thread.py and the only place where DeadlockWrap() gets called without passing in max_retries (i.e. it runs forever) is in readerThread(). So I added max_retries to both those calls and now I see DBLockDeadlockErrors in the readerThreads and AssertionErrors in the writerThreads. Fred's seen these assertions and Tim says that Skip reported these assertions too. I think I'm going to leave the max_retries in on the readerThread() calls to DeadlockWrap(). That'll at least prevent the tests from hanging. We'll investigate a bit more to see if we can find out more about the underlying cause of the assertion failures. There's some mystery there too. -Barry From barry@python.org Tue Jul 22 00:00:26 2003 From: barry@python.org (Barry Warsaw) Date: 21 Jul 2003 19:00:26 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <16156.27381.925389.777799@montanaro.dyndns.org> References: <65E00892-BB87-11D7-9366-000A27B19B96@cwi.nl> <200307211439.h6LEdECc006696@localhost.localdomain> <16156.2064.781257.761849@montanaro.dyndns.org> <16156.27381.925389.777799@montanaro.dyndns.org> Message-ID: <1058828426.2036.217.camel@yyz> On Mon, 2003-07-21 at 18:36, Skip Montanaro wrote: > Martin> Just thinks that getaddrinfo is not thread-safe on OSX, so it > Martin> needs to use a lock around getaddrinfo. > > I've been thusfar unable to get the code in getaddrinfo.c to compile as part > of socketmodule.c (errors about missing #defines and struct members). > Unless maybe Barry or Jack can figure out what the problem is, I think > solving this particular performance problem may have to wait until after the > 2.3 release. I don't see myself having any more time to dig into this. I say if it doesn't get resolved, we'll leave it in the old state (which works, but is slow), and add a release note about it in the known bugs section. -Barry From tdelaney@avaya.com Tue Jul 22 01:03:23 2003 From: tdelaney@avaya.com (Delaney, Timothy C (Timothy)) Date: Tue, 22 Jul 2003 10:03:23 +1000 Subject: [Python-Dev] New branch for r23c2 work Message-ID: <338366A6D2E2CA4C9DAEAE652E12A1DE8D424B@au3010avexu1.global.avaya.com> > From: Barry Warsaw [mailto:barry@python.org] >=20 > I don't see myself having any more time to dig into this. I say if it > doesn't get resolved, we'll leave it in the old state (which=20 > works, but > is slow), and add a release note about it in the known bugs section.=20 I think the most important thing here is to have a stable release for = Apple. It should always be possible to work with Apple to produce an = improved version post-2.3 to be delivered via Apple Software Update (or = whatever it's called). The fix could then be rolled into 2.3.1. Contributions also go both ways - I definitely think Apple should be = made aware of Skip's findings about getaddrinfo. Hopefully we'll either = get a Python fix from Apple, or a getaddrinfo fix ... or both ;) Tim Delaney From barry@python.org Tue Jul 22 01:12:32 2003 From: barry@python.org (Barry Warsaw) Date: 21 Jul 2003 20:12:32 -0400 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <338366A6D2E2CA4C9DAEAE652E12A1DE8D424B@au3010avexu1.global.avaya.com> References: <338366A6D2E2CA4C9DAEAE652E12A1DE8D424B@au3010avexu1.global.avaya.com> Message-ID: <1058832752.27675.5.camel@anthem> On Mon, 2003-07-21 at 20:03, Delaney, Timothy C (Timothy) wrote: > > From: Barry Warsaw [mailto:barry@python.org] > > > > I don't see myself having any more time to dig into this. I say if it > > doesn't get resolved, we'll leave it in the old state (which > > works, but > > is slow), and add a release note about it in the known bugs section. > > I think the most important thing here is to have a stable release for Apple. It should always be possible to work with Apple to produce an improved version post-2.3 to be delivered via Apple Software Update (or whatever it's called). The fix could then be rolled into 2.3.1. > > Contributions also go both ways - I definitely think Apple should be made aware of Skip's findings about getaddrinfo. Hopefully we'll either get a Python fix from Apple, or a getaddrinfo fix ... or both ;) Agreed. In private email, I put Skip in touch with the Apple engineer who's shepherding Python (and Perl) for Panther. -Barry From tim.one@comcast.net Tue Jul 22 01:39:00 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 21 Jul 2003 20:39:00 -0400 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: Message-ID: Over on the spambayes-dev mailing list, Richie Hindle presents a program that makes bsddb3 go insane: http://mail.python.org/pipermail/spambayes-dev/2003-July/000519.html He was on Win98SE. I got the same "corrupted database" symptom several times on Win2K using the same program, but never the "illegal instruction" symptom. This throws multiple threads at a Berkely hash DB. It's clear as snot whether that's supported. Contrary to a followup msg, it looks like the Python hashopen() call *always* forces the DB_THREAD flag into the mix, so the absence of DB_THREAD probably isn't the problem. From zen@shangri-la.dropbear.id.au Tue Jul 22 02:58:00 2003 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Tue, 22 Jul 2003 11:58:00 +1000 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <16156.27381.925389.777799@montanaro.dyndns.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, July 22, 2003, at 08:36 AM, Skip Montanaro wrote: > It looks like the Mac OS X implementation of getaddrinfo is just dog > slow. > I instrumented setipaddr with calls to gettimeofday() to see how long > different sections took. It turns out that getaddrinfo() is hideously > slow: This would be hideously slow by design - Python is sitting idle while the lookupd directory is queried (you can tell as lookupd process is chewing CPU). I don't think this should affect an Apple release - Python 2.2.0 as shipped with OS X 10.2 has the same behavior. > when you get into setipaddr() name[0] will always be '\0' and so > you'll take > the first branch. Do you need all of getaddrinfo()'s bells and > whistles to > properly set up addr_ret in this case? At worst, can't the > getaddrinfo() > call be made once and then cached? 'man lookupd' says 'lookupd keeps a cache of recently located items to improve system performance', so Python shouldn't have to (?) I've found no way of determining what queries are being sent to lookupd :-( - -- Stuart Bishop http://shangri-la.dropbear.id.au/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE/HJosh8iUz1x5geARAsDuAJ0fogD1PAqmm79skBYHgVfpc6Y51ACfdqwR VUaMwjBGDPSMjXUaX1bb+kI= =NrnR -----END PGP SIGNATURE----- From tim.one@comcast.net Tue Jul 22 03:15:43 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 21 Jul 2003 22:15:43 -0400 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: Message-ID: BTW, all the bsddb3 tests people have reported gross problems with (hangs and AssertionErrors) recently come from a group of 8 tests that can be run by themselves, via your platform equivalent of python ../Lib/bsddb/test/test_thread.py Add -v and unittest will show you the names of the 8 tests as they're running. Add verbose and the tests themselves will display a lot about what they're doing. Since there seem to be timing-related bugs here, trying this on a lot of platforms may help us gather better clues. For example, I was able just once to provoke "a hang" on Win2K when using "-v verbose", by using a debug build of Python, which revealed that it was stuck in an infinite loop in DeadlockWrap, not really hung. Switching options, Python builds, and background loads may all help provoke problems. I never saw AssertionErrors on Win2K no matter what I did. Fred and Barry did on Linux, though, in the same place Skip reported them. Of (IMO) vital importance is that the assertion details were identical too: in all, the very first (key, value) pair added by writerThread #2 vanished by the time the thread tried to read back all the pairs it wrote. Other AssertionErrors also appeared to be at, or very near, the first (key, value) pair written by a thread. There's no reason to believe these failures are new, so I wouldn't hold the release for them. But especially on Windows, Berkeley has a rotten reputation (thanks to using the plain broken 1.85 for so many years), and people using bsddb3 in the spambayes Outlook addin are reporting more than their share of seemingly database-related bugs too. The evidence suggests there are still potentially catastrophic bugs in bsddb3! OTOH, there are no known bugs in ZODB or ZEO. This is because we stopped running their test suites in a loop . From tim.one@comcast.net Tue Jul 22 03:18:47 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 21 Jul 2003 22:18:47 -0400 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: Message-ID: [Tim] > Over on the spambayes-dev mailing list, Richie Hindle presents a > program that makes bsddb3 go insane: > > http://mail.python.org/pipermail/spambayes-dev/2003-July/000519.html Oops! That was an insane database in the context of running spambayes. Here's his isolated, standalone driver: http://mail.python.org/pipermail/spambayes-dev/2003-July/000524.html I'll add that to the Python bug tracker. From Anthony Baxter Tue Jul 22 03:29:08 2003 From: Anthony Baxter (Anthony Baxter) Date: Tue, 22 Jul 2003 12:29:08 +1000 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: <1058807191.2036.76.camel@yyz> Message-ID: <200307220229.h6M2T9c9018285@localhost.localdomain> >>> Barry Warsaw wrote > strace-ing the process gives me: > > % strace -p 26615 > futex(0x82fb8c0, FUTEX_WAIT, 0, NULL Upgrade your glibc. This should go on the download page - the glibc that ships with RH9 is seriously broken. Anthony From skip@pobox.com Tue Jul 22 03:48:09 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 21 Jul 2003 21:48:09 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: <16156.27381.925389.777799@montanaro.dyndns.org> Message-ID: <16156.42473.441618.555308@montanaro.dyndns.org> Skip> It looks like the Mac OS X implementation of getaddrinfo is just Skip> dog slow. I instrumented setipaddr with calls to gettimeofday() Skip> to see how long different sections took. It turns out that Skip> getaddrinfo() is hideously slow: Stuart> This would be hideously slow by design - Python is sitting idle Stuart> while the lookupd directory is queried (you can tell as lookupd Stuart> process is chewing CPU). Yes, thanks for reminding me of that. I had forgotten that an external process is involved in name resolution. Stuart> I don't think this should affect an Apple release - Python 2.2.0 Stuart> as shipped with OS X 10.2 has the same behavior. I think we've concluded that it's okay to ship 2.3 with this problem unresolved, however I'm completely befuddled at the moment. I wrote this simple program: #include #include #include #include #include int main(int argc, char **argv) { int i; struct addrinfo hints, *res; int error; struct timeval t, u; hints.ai_family = AF_INET; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; printf("start\n"); for (i=0; i<100; i++) { gettimeofday(&t, NULL); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, NULL); fprintf(stderr, "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); freeaddrinfo(res); } printf("finish\n"); } When run on my Mac, it takes between 2 and 7 microseconds per getaddrinfo call. The exact same instrumented call inside socketmodule.c:setipaddr at line 700 takes about 150 *milli*seconds per call. I tried eliminating the Py_{BEGIN,END}_ALLOW_THREADS calls as well as the ACQUIRE and RELEASE of the getaddrinfo lock. That had no effect on the call. I also tweaked the compile like to run just the C preprocessor (gcc -E instead of gcc -g) and checked the output: ... hints.ai_family = af; hints.ai_socktype = 2; hints.ai_flags = 0x00000001; { PyThreadState *_save; _save = PyEval_SaveThread(); PyThread_acquire_lock(netdb_lock, 1); gettimeofday(&t, 0); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, 0); fprintf((&__sF[2]), "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); PyEval_RestoreThread(_save); } ... otool -L run against both the test program and _socket.so indicate that both refer to just one shared library (/usr/lib/libSystem.B.dylib), so both should be calling the same routine. Another little observation. I ran the getaddr program (with the loop cranked up to 10 million iterations) while the top command was running. The lookupd process didn't show on the radar at all. While running the Python script however, lookupd consumed about 50% of the cpu. I've added this information to the tracker item. Skip From tim.one@comcast.net Tue Jul 22 04:26:31 2003 From: tim.one@comcast.net (Tim Peters) Date: Mon, 21 Jul 2003 23:26:31 -0400 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: Message-ID: [martin@v.loewis.de] > That might be. What they consider wide-spread is the assumption that > you can access the same memory with different incompatible struct > types. Atleast the Linux kernel is known to miscompile because of this > assumption. When I first googled on this, I found a lot of confused hits. It appears that Perl and Parrot need -fno-strict-aliasing for correct operation. > Whether most of the programs that are incorrect in this respect also > give an opportunity for the optimizer to generate bad code, I don't > know. Reportedly, the typical problem is not a bad write order, but a > failure to reload a value that the compiler "knows" not to be changed. That makes sense (alas). We cast PyObject* to and from everything all over the place, but the only common members are the essentially read-only (after initialization) pointer to the type object, and the refcount field, which latter is almost always accessed via macros that cast to PyObject* first. The other fields can't be accessed at all except via a correctly typed pointer to the (conceptual) subtype, while the common fields are usually accessed via a PyObject*. Since the access paths to a given member don't normally use both ways, the compiler normally may as well assume the two kinds of pointers point to non-overlapping stuff. Perhaps the ob_size member of var objects is more vulnerable. > ... > Yes. Indeed, gcc 3.3 offers a type attribute "may_alias", which causes > a type to be treated like char* for aliasing purposes. Sounds like we should add that to PyObject*. Maybe . > I still think that the non-standards-compliance for Python should be > removed in 2.4. If we ever get a bad optimization because of aliasing > problems, it will be very time consuming to find the real cause of the > problem. So the problem is best avoided to begin with. I'm not fatally opposed to standard code . It's unclear whether this can be done for 2.4, though, or needs to wait for Python 3. Not *all* accesses to ob_refcnt and ob_type go thru macros, and if those members get stuffed behind another access component, some non-core extension modules are going to stop compiling. In Zope's C extensions, ob_refcnt is referenced directly 16 times, and ob_type 174 times. Many of those are dereferencing PyObject* vrbls, but many are dereferencing conceptual subtypes (like BTree*, Sized*, and Wrapper*). For example, typedef struct { PyObject_HEAD PyObject *obj; PyObject *container; } Wrapper; ... Wrapper *self; ... assert(self->ob_refcnt == 1); self->ob_type=Wrappertype; Of course creating work is hard to sell. From skip@pobox.com Tue Jul 22 04:34:15 2003 From: skip@pobox.com (Skip Montanaro) Date: Mon, 21 Jul 2003 22:34:15 -0500 Subject: [Python-Dev] ANSI strict aliasing and Python In-Reply-To: References: Message-ID: <16156.45239.666861.513976@montanaro.dyndns.org> Tim> When I first googled on this, I found a lot of confused hits. It Tim> appears that Perl and Parrot need -fno-strict-aliasing for correct Tim> operation. This surprises you? Skip From martin@v.loewis.de Tue Jul 22 07:12:56 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 08:12:56 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <16156.27381.925389.777799@montanaro.dyndns.org> References: <65E00892-BB87-11D7-9366-000A27B19B96@cwi.nl> <200307211439.h6LEdECc006696@localhost.localdomain> <16156.2064.781257.761849@montanaro.dyndns.org> <16156.27381.925389.777799@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > I've been thusfar unable to get the code in getaddrinfo.c to compile as part > of socketmodule.c (errors about missing #defines and struct members). And you shouldn't: OSX has its own implementation of getaddrinfo, so you don't need the emulation code from getaddrinfo.c. > Maybe the solution for the common case is easier. In the common case of: > > s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) > s.bind (('',0)) > > when you get into setipaddr() name[0] will always be '\0' and so you'll take > the first branch. Do you need all of getaddrinfo()'s bells and whistles to > properly set up addr_ret in this case? At worst, can't the getaddrinfo() > call be made once and then cached? OTOH, we shouldn't work around performance problems on certain systems. Instead, we should report them to the system vendors and wait for fixes from them. It's worse enough that we need to work around functional problems (getaddrinfo not being thread-safe even though the spec says it should be). Regards, Martin From Anthony Baxter Tue Jul 22 07:15:50 2003 From: Anthony Baxter (Anthony Baxter) Date: Tue, 22 Jul 2003 16:15:50 +1000 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: Message-ID: <200307220615.h6M6Fos1022125@localhost.localdomain> >>> Martin v. =?iso-8859-15?q?L=F6wis?= wrote > OTOH, we shouldn't work around performance problems on certain > systems. Instead, we should report them to the system vendors and wait > for fixes from them. In this case, though, it seems that we only developed the performance-impacting code between Python2.1 and Python2.2. Anthony From martin@v.loewis.de Tue Jul 22 07:16:06 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 08:16:06 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <16156.42473.441618.555308@montanaro.dyndns.org> References: <16156.27381.925389.777799@montanaro.dyndns.org> <16156.42473.441618.555308@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > I think we've concluded that it's okay to ship 2.3 with this problem > unresolved, however I'm completely befuddled at the moment. I wrote this > simple program: [...] > error = getaddrinfo(0, "0", &hints, &res); Is this really the same call that runs in Python? I thought it should have "" as the first argument instead of 0. Regards, Martin From martin@v.loewis.de Tue Jul 22 07:18:21 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 08:18:21 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <1058832752.27675.5.camel@anthem> References: <338366A6D2E2CA4C9DAEAE652E12A1DE8D424B@au3010avexu1.global.avaya.com> <1058832752.27675.5.camel@anthem> Message-ID: Barry Warsaw writes: > Agreed. In private email, I put Skip in touch with the Apple engineer > who's shepherding Python (and Perl) for Panther. That person might also be the one to ask whether getaddrinfo is thread-safe on OSX (not that this can have effect on 2.3.0, but we still should know). Regards, Martin From martin@v.loewis.de Tue Jul 22 07:21:54 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 08:21:54 +0200 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: References: Message-ID: "Tim Peters" writes: > The evidence suggests there are still potentially catastrophic bugs > in bsddb3! So far, I have interpreted all failures in test_bsddb3 as being related to the explicit use of transactions. Since the historic bsddb module does not provide an interface for transactions, I have always concluded that existing code won't be affected by these problems. Regards, Martin From Jack.Jansen@cwi.nl Tue Jul 22 09:35:43 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 22 Jul 2003 10:35:43 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <200307220615.h6M6Fos1022125@localhost.localdomain> Message-ID: <7BBEEE8D-BC1F-11D7-8007-0030655234CE@cwi.nl> On Tuesday, Jul 22, 2003, at 08:15 Europe/Amsterdam, Anthony Baxter wrote: > >>>> Martin v. =?iso-8859-15?q?L=F6wis?= wrote >> OTOH, we shouldn't work around performance problems on certain >> systems. Instead, we should report them to the system vendors and wait >> for fixes from them. > > In this case, though, it seems that we only developed the > performance-impacting > code between Python2.1 and Python2.2. Not really: Python 2.1 used the getaddrinfo() emulation on OSX, because OSX 10.1, which was then current, didn't have a working getaddrinfo() at all. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Richie Hindle Tue Jul 22 09:49:56 2003 From: Richie Hindle (Richie Hindle) Date: Tue, 22 Jul 2003 09:49:56 +0100 Subject: [Python-Dev] bsddb3 test hang Message-ID: [Tim] > background loads may [...] help provoke problems. For what it's worth, my hammer_bsddb script that Tim mentioned, at http://mail.python.org/pipermail/spambayes-dev/2003-July/000524.html seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. I don't have a source build of Python at the moment, but if no-one else can reproduce the problem then I can check one out (SF permitting 8-) and try to find out where it's crashing. One minor correction to Tim's post: I'm on Plain Old Win98, not SE. -- Richie Hindle richie@entrian.com From skip@pobox.com Tue Jul 22 11:32:12 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 22 Jul 2003 05:32:12 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: <16156.27381.925389.777799@montanaro.dyndns.org> <16156.42473.441618.555308@montanaro.dyndns.org> Message-ID: <16157.4780.255883.508277@montanaro.dyndns.org> >> error = getaddrinfo(0, "0", &hints, &res); Martin> Is this really the same call that runs in Python? I thought it Martin> should have "" as the first argument instead of 0. In this case, yes. There are other calls to getaddrinfo in socketmodule.c which have non-NULL first args, but the first one in setipaddr() which is causing all the fuss has NULL as the first argument. Skip From jason@tishler.net Tue Jul 22 13:38:20 2003 From: jason@tishler.net (Jason Tishler) Date: Tue, 22 Jul 2003 08:38:20 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <1058822073.2036.140.camel@yyz> References: <1058822073.2036.140.camel@yyz> Message-ID: <20030722123820.GA1180@tishler.net> Barry, On Mon, Jul 21, 2003 at 05:14:33PM -0400, Barry Warsaw wrote: > On Mon, 2003-07-21 at 17:01, Tim Peters wrote: > > [Jason Tishler] > > > Yup! But, would such a Cygwin specific change be accepted so > > > close to the release date? > > > > If the Cygwin-specific part is (as it seemed to me) isolated to the > > only line in the codebase that tests HAVE_PTHREAD_SIGMASK, I think > > the risk is too small to worry about. In one real sense, the > > HAVE_PTHREAD_SIGMASK patch introduced bugs, causing a > > formerly-working platform to fall over. > > I'd agree. This isn't hurting any other platform, so hacking > configure for this test on cygwin seems of minimal pain. The > potential for other OS breakage is smaller the sooner you do it. > Please see the following: http://sf.net/tracker/?func=detail&aid=775605&group_id=5470&atid=305470 Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From mwh@python.net Tue Jul 22 15:33:28 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 22 Jul 2003 15:33:28 +0100 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <16156.42473.441618.555308@montanaro.dyndns.org> (Skip Montanaro's message of "Mon, 21 Jul 2003 21:48:09 -0500") References: <16156.27381.925389.777799@montanaro.dyndns.org> <16156.42473.441618.555308@montanaro.dyndns.org> Message-ID: <2mznj6oclj.fsf@starship.python.net> Skip Montanaro writes: > When run on my Mac, it takes between 2 and 7 microseconds per getaddrinfo > call. The exact same instrumented call inside socketmodule.c:setipaddr at > line 700 takes about 150 *milli*seconds per call. It might be something horrendous like linking with AppKit means you get a difference version of getaddrinfo that goes through NetInfo. Cheers, mwh -- Well, you pretty much need Microsoft stuff to get misbehaviours bad enough to actually tear the time-space continuum. Luckily for you, MS Internet Explorer is available for Solaris. -- Calle Dybedahl, alt.sysadmin.recovery From theller@python.net Tue Jul 22 15:43:26 2003 From: theller@python.net (Thomas Heller) Date: Tue, 22 Jul 2003 16:43:26 +0200 Subject: [Python-Dev] improved zipimport Message-ID: Is it too late to get this small patch in? I'm hesitating to raise the priority... Thomas From Jack.Jansen@cwi.nl Tue Jul 22 16:01:46 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 22 Jul 2003 17:01:46 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <2mznj6oclj.fsf@starship.python.net> Message-ID: <6A2482C4-BC55-11D7-8007-0030655234CE@cwi.nl> On Tuesday, Jul 22, 2003, at 16:33 Europe/Amsterdam, Michael Hudson wrote: > Skip Montanaro writes: > >> When run on my Mac, it takes between 2 and 7 microseconds per >> getaddrinfo >> call. The exact same instrumented call inside >> socketmodule.c:setipaddr at >> line 700 takes about 150 *milli*seconds per call. > > It might be something horrendous like linking with AppKit means you > get a difference version of getaddrinfo that goes through NetInfo. Good point! Or the C++ runtime, or some other thing Python pulls in. Skip: could you try linking your test program with a command line similar to what Python uses? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From barry@python.org Tue Jul 22 16:00:52 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 11:00:52 -0400 Subject: [Python-Dev] improved zipimport In-Reply-To: References: Message-ID: <1058886052.13235.19.camel@yyz> On Tue, 2003-07-22 at 10:43, Thomas Heller wrote: > Is it too late to get this small patch in? > > > > I'm hesitating to raise the priority... I'm not a zipimport export but the description seems to imply it's a new feature not a bug fix. Without more persuasion, I'd say it's too late for 2.3. -Barry From skip@pobox.com Tue Jul 22 16:17:56 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 22 Jul 2003 10:17:56 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <6A2482C4-BC55-11D7-8007-0030655234CE@cwi.nl> References: <2mznj6oclj.fsf@starship.python.net> <6A2482C4-BC55-11D7-8007-0030655234CE@cwi.nl> Message-ID: <16157.21924.906859.325583@montanaro.dyndns.org> --TBwrwcFxuo Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Jack> Skip: could you try linking your test program with a command line Jack> similar to what Python uses? No change. I used the attached Makefile and getaddr.c files and got this output when building getaddr: ld: warning dynamic shared library: /System/Library/Frameworks/CoreServices.framework/CoreServices not made a weak library in output with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 Still ran like a bat out of hell. Skip --TBwrwcFxuo Content-Type: application/octet-stream Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN5cy90aW1lLmg+CiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KI2luY2x1ZGUg PHN5cy9zb2NrZXQuaD4KI2luY2x1ZGUgPG5ldGRiLmg+CiNpbmNsdWRlIDxzdGRpby5oPgoK aW50Cm1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KSB7CglpbnQgaTsKCXN0cnVjdCBhZGRy aW5mbyBoaW50cywgKnJlczsKCWludCBlcnJvcjsKCXN0cnVjdCB0aW1ldmFsIHQsIHU7CgkK CWhpbnRzLmFpX2ZhbWlseSA9IEFGX0lORVQ7CgloaW50cy5haV9zb2NrdHlwZSA9IFNPQ0tf REdSQU07CS8qZHVtbXkqLwoJaGludHMuYWlfZmxhZ3MgPSBBSV9QQVNTSVZFOwoKCWZvciAo aT0wOyBpPDEwMDsgaSsrKSB7CgkJZ2V0dGltZW9mZGF5KCZ0LCBOVUxMKTsKCQllcnJvciA9 IGdldGFkZHJpbmZvKDAsICIwIiwgJmhpbnRzLCAmcmVzKTsKCQlnZXR0aW1lb2ZkYXkoJnUs IE5VTEwpOwoJCWZwcmludGYoc3RkZXJyLCAiZ3RvZDogJS42ZlxuIiwKCQkJdS50dl9zZWMt dC50dl9zZWMrKHUudHZfdXNlYy10LnR2X3VzZWMpKjFlLTYpOwoJCWZyZWVhZGRyaW5mbyhy ZXMpOwoJfQp9Cg== --TBwrwcFxuo Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Z2V0YWRkciA6IGdldGFkZHIuYwoJYysrICAtdSBfX2R1bW15IC1mcmFtZXdvcmsgU3lzdGVt IC1mcmFtZXdvcmsgQ29yZVNlcnZpY2VzIC1mcmFtZXdvcmsgRm91bmRhdGlvbiAtbyBnZXRh ZGRyIFwKCQkJZ2V0YWRkci5jIC1sZGwK --TBwrwcFxuo-- From theller@python.net Tue Jul 22 16:25:29 2003 From: theller@python.net (Thomas Heller) Date: Tue, 22 Jul 2003 17:25:29 +0200 Subject: [Python-Dev] improved zipimport In-Reply-To: <1058886052.13235.19.camel@yyz> (Barry Warsaw's message of "22 Jul 2003 11:00:52 -0400") References: <1058886052.13235.19.camel@yyz> Message-ID: Barry Warsaw writes: > On Tue, 2003-07-22 at 10:43, Thomas Heller wrote: >> Is it too late to get this small patch in? >> >> >> >> I'm hesitating to raise the priority... > > I'm not a zipimport export but the description seems to imply it's a new > feature not a bug fix. There are several ways to argue that is *is* a bug fix: zipimport.c doesn't handle zip files which are no problem for the zipfile module. zipimport.c, as it is now, looks for the endof_central_dir header relative to the *end of the file*: fseek(fp, -22, SEEK_END); header_end = ftell(fp); if (fread(endof_central_dir, 1, 22, fp) != 22) { ... but then goes on positioning relative to the *start of the file*: fseek(fp, header_offset, 0); /* Start of file header */ l = PyMarshal_ReadLongFromFile(fp); if (l != 0x02014B50) break; /* Bad: Central Dir File Header */ OTOH, fixing this 'bug' allows py2exe using the zipimport hook. Thanks, Thomas From Jack.Jansen@cwi.nl Tue Jul 22 16:36:20 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 22 Jul 2003 17:36:20 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <16157.21924.906859.325583@montanaro.dyndns.org> Message-ID: <3DCE059B-BC5A-11D7-8007-0030655234CE@cwi.nl> On Tuesday, Jul 22, 2003, at 17:17 Europe/Amsterdam, Skip Montanaro wrote: > > Jack> Skip: could you try linking your test program with a command > line > Jack> similar to what Python uses? > > No change. Grmpf. Next wild idea: could it have something to do with the way the code referring to getaddrinfo() is loaded from a bundle, in stead of being in the main executable? This is difficult to test in general, but you could try turning your test program into a Python extension module by renaming main to initfoobar() and importing it. Python will complain after importing the module, but by that time you'll have the numbers:-) -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Paul.Moore@atosorigin.com Tue Jul 22 16:43:55 2003 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Tue, 22 Jul 2003 16:43:55 +0100 Subject: [Python-Dev] improved zipimport Message-ID: <16E1010E4581B049ABC51D4975CEDB88619AD3@UKDCX001.uk.int.atosorigin.com> From: Barry Warsaw [mailto:barry@python.org] > On Tue, 2003-07-22 at 10:43, Thomas Heller wrote: >> Is it too late to get this small patch in? >>=20 >> >>=20 >> I'm hesitating to raise the priority... > I'm not a zipimport export but the description seems to imply it's a = new > feature not a bug fix. Without more persuasion, I'd say it's too late > for 2.3. I thought this already worked, and I'd like it to. But as it doesn't, = I'd have to agree that it's a new feature and not appropriate at this late stage (much as I'd like it to go in). [Mumble, click] Ah yes. See http://www.python.org/sf/669036 - Just meant to get to this, but didn't manage to. On the other hand, the fact that it's logged as a = bug may mean it makes sense to allow it. Paul. From barry@python.org Tue Jul 22 16:45:48 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 11:45:48 -0400 Subject: [Python-Dev] improved zipimport In-Reply-To: References: <1058886052.13235.19.camel@yyz> Message-ID: <1058888748.13235.42.camel@yyz> On Tue, 2003-07-22 at 11:25, Thomas Heller wrote: > There are several ways to argue that is *is* a bug fix: zipimport.c > doesn't handle zip files which are no problem for the zipfile module. Okay, that does seem like a problem. SF's web site is dead again, but go ahead and check it in when it comes back up. -Barry From tim.one@comcast.net Tue Jul 22 16:58:11 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 11:58:11 -0400 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: Message-ID: [Tim] >> The evidence suggests there are still potentially catastrophic bugs >> in bsddb3! [martin@v.loewis.de] > So far, I have interpreted all failures in test_bsddb3 as being > related to the explicit use of transactions. Since the historic bsddb > module does not provide an interface for transactions, I have always > concluded that existing code won't be affected by these problems. I'm guessing we're talking about different things, then. These things have been discussed recently here: + Reports of bsddb3 database corruption in spambayes. + Likewise in Richie Hindle's multithreaded test driver, plus hardware faults. + Hangs and AssertionErrors in the tests from Lib/bsddb/test/test_thread.py. Richie's program uses only our wrapper's __delitem__, __setitem__ and __getitem__ implementations. spambayes does the same. While some tests in test_thread.py use transactions, the AssertionError Skip reported was in a test that does not use transactions: http://mail.python.org/pipermail/python-dev/2003-July/036920.html Fred and Barry also saw the same kind of AssertionErrors in SimpleThreadBase.writerThread, on the same line. Finally, the hangs Barry and I saw were in test02_SimpleLocks, which is also devoid of transactions. So I haven't seen any evidence of problems with transactions -- unless these things use transactions implicitly in some way. From theller@python.net Tue Jul 22 17:03:22 2003 From: theller@python.net (Thomas Heller) Date: Tue, 22 Jul 2003 18:03:22 +0200 Subject: [Python-Dev] improved zipimport In-Reply-To: <1058888748.13235.42.camel@yyz> (Barry Warsaw's message of "22 Jul 2003 11:45:48 -0400") References: <1058886052.13235.19.camel@yyz> <1058888748.13235.42.camel@yyz> Message-ID: Barry Warsaw writes: > On Tue, 2003-07-22 at 11:25, Thomas Heller wrote: > >> There are several ways to argue that is *is* a bug fix: zipimport.c >> doesn't handle zip files which are no problem for the zipfile module. > > Okay, that does seem like a problem. SF's web site is dead again, but > go ahead and check it in when it comes back up. "Moore, Paul" writes: > I thought this already worked, and I'd like it to. But as it doesn't, I'd > have to agree that it's a new feature and not appropriate at this late > stage (much as I'd like it to go in). > > [Mumble, click] > Ah yes. See http://www.python.org/sf/669036 - Just meant to get to this, > but didn't manage to. On the other hand, the fact that it's logged as a bug > may mean it makes sense to allow it. It would be best if someone else who really uses zipimports would be able to test it - I really don't want to break anything. Thomas From barry@python.org Tue Jul 22 17:14:06 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 12:14:06 -0400 Subject: [Python-Dev] improved zipimport In-Reply-To: <16E1010E4581B049ABC51D4975CEDB88619AD3@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB88619AD3@UKDCX001.uk.int.atosorigin.com> Message-ID: <1058890446.13235.50.camel@yyz> On Tue, 2003-07-22 at 11:43, Moore, Paul wrote: > [Mumble, click] > Ah yes. See http://www.python.org/sf/669036 - Just meant to get to this, > but didn't manage to. On the other hand, the fact that it's logged as a bug > may mean it makes sense to allow it. Yes, we're going to allow it. Thomas, be sure to also update the NEWS file. -Barry From mwh@python.net Tue Jul 22 18:10:50 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 22 Jul 2003 18:10:50 +0100 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <3DCE059B-BC5A-11D7-8007-0030655234CE@cwi.nl> (Jack Jansen's message of "Tue, 22 Jul 2003 17:36:20 +0200") References: <3DCE059B-BC5A-11D7-8007-0030655234CE@cwi.nl> Message-ID: <2mwueao5b9.fsf@starship.python.net> Jack Jansen writes: > On Tuesday, Jul 22, 2003, at 17:17 Europe/Amsterdam, Skip Montanaro > wrote: > >> >> Jack> Skip: could you try linking your test program with a >> command line >> Jack> similar to what Python uses? >> >> No change. > > Grmpf. Next wild idea: could it have something to do with the way > the code referring to getaddrinfo() is loaded from a bundle, in > stead of being in the main executable? > > This is difficult to test in general, but you could try turning your > test program into a Python extension module by renaming main to > initfoobar() and importing it. Python will complain after importing > the module, but by that time you'll have the numbers:-) Nope, that runs like a bat out of hell too. Cheers, mwh -- I also feel it essential to note, [...], that Description Logics, non-Monotonic Logics, Default Logics and Circumscription Logics can all collectively go suck a cow. Thank you. -- http://advogato.org/person/Johnath/diary.html?start=4 From theller@python.net Tue Jul 22 18:18:35 2003 From: theller@python.net (Thomas Heller) Date: Tue, 22 Jul 2003 19:18:35 +0200 Subject: [Python-Dev] improved zipimport In-Reply-To: <1058890446.13235.50.camel@yyz> (Barry Warsaw's message of "22 Jul 2003 12:14:06 -0400") References: <16E1010E4581B049ABC51D4975CEDB88619AD3@UKDCX001.uk.int.atosorigin.com> <1058890446.13235.50.camel@yyz> Message-ID: Barry Warsaw writes: > On Tue, 2003-07-22 at 11:43, Moore, Paul wrote: > >> [Mumble, click] >> Ah yes. See http://www.python.org/sf/669036 - Just meant to get to this, >> but didn't manage to. On the other hand, the fact that it's logged as a bug >> may mean it makes sense to allow it. > > Yes, we're going to allow it. > > Thomas, be sure to also update the NEWS file. I will check it in after a little bit more testing, and I also want to write a testcase for test_zipimport. Where must this be committed? In the HEAD? And thanks, Thomas From tim.one@comcast.net Tue Jul 22 18:30:34 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 13:30:34 -0400 Subject: [Python-Dev] improved zipimport In-Reply-To: Message-ID: [Thomas Heller] > I will check it in after a little bit more testing, and I also want to > write a testcase for test_zipimport. > Where must this be committed? In the HEAD? Yes, in the head. From barry@python.org Tue Jul 22 18:30:57 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 13:30:57 -0400 Subject: [Python-Dev] improved zipimport In-Reply-To: References: <16E1010E4581B049ABC51D4975CEDB88619AD3@UKDCX001.uk.int.atosorigin.com> <1058890446.13235.50.camel@yyz> Message-ID: <1058895057.13235.69.camel@yyz> On Tue, 2003-07-22 at 13:18, Thomas Heller wrote: > I will check it in after a little bit more testing, and I also want to > write a testcase for test_zipimport. > Where must this be committed? In the HEAD? Yes, the head please. Thanks, -Barry From johnfabel@btinternet.com Tue Jul 22 20:15:14 2003 From: johnfabel@btinternet.com (John Abel) Date: Tue, 22 Jul 2003 20:15:14 +0100 Subject: [Python-Dev] PyConfig.h On Solaris In-Reply-To: References: <3F1C4808.2090102@btinternet.com> Message-ID: <3F1D8D42.4020605@btinternet.com> Hi! Just a quick update. As a final attempt, before I implemented Martin's suggestion, I chaged the order of the includes. Having Python.h last in the includes, solved everything (apart from a warning, about _FILE_OFFSET_BITS being redefined. If it's already defined by the OS, does pyconfig.h have to define it?). Is there somewhere to log things such as this? Does it warrant a bug report? Regards John Martin v. Löwis wrote: >John Abel writes: > > > >>Is there a way, to tell Python to compile a module in 32bit mode? >> >> > >You could edit pyconfig.h after configuring but before compiling >Python. I would advise against doing so. > > > >>Or, is there a workaround for this Solaris oddity? >> >> > >You could split your code into two files, with LFS-independent data >structures in-between them. IOW, define JA_psinfo_t, which has just >the fields of psinfo_t that you are interested in, using >LFS-independent data types. In the source file opening /proc, copy all >interesting fields in the data structure pointed-to by the caller, and >compile this without LFS. Then, in the Python module proper, call >these helper functions, passing JA_psinfo_t. > >AFAICT, it is only priovec_t, anyway, which is affected by the >incompatibility, so if you don't use that, you could just pass >psinfo_t through. I might be wrong here, though. > >Regards, >Martin > > >_______________________________________________ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev > > > From drifty@alum.berkeley.edu Tue Jul 22 20:20:07 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 12:20:07 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F10D7E7.3080304@ocf.berkeley.edu> References: <3F10D7E7.3080304@ocf.berkeley.edu> Message-ID: <3F1D8E67.8010609@ocf.berkeley.edu> Brett C. wrote: > Just a quick reminder, I am going off for a vacation and my brother's > wedding tomorrow (July 13) and won't have a definite Net connection > until July 22. > OK, I am back with vacation having gained a sister-in-law and possible housing in San Luis Obispo. > The bug #762934 (patch for configure.in to detect time.tzset better) is > still open. I uploaded my own version of the patch that is more > explicit in detecting whether the function works properly. It works for > me, but tzset has always worked properly for me. If someone with Red > Hat 6.2 can test it that would be great (that will close bug #763153). > This bug is still open. Skip and I have verified it works on OS X, but it *really* needs to be tested on a Red Hat 6.2 box. > The macostools error (bug #763708) is still happening and I still think > it could be an OS X bug and not ours. > This is still happening and I am working with Jack to solve this. > And after I updated my copy of CVS and tried out the patch for tzset > detection as mentioned above I got a failure in test_pep277.py (only > difference between CVS and my checkout is configure.in and only in the > tzset code and regrtest.py): These both have been solved. -Brett From barry@python.org Tue Jul 22 20:31:47 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 15:31:47 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1D8E67.8010609@ocf.berkeley.edu> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> Message-ID: <1058902307.13235.90.camel@yyz> On Tue, 2003-07-22 at 15:20, Brett C. wrote: > This bug is still open. Skip and I have verified it works on OS X, but > it *really* needs to be tested on a Red Hat 6.2 box. We may just be SOL here. No one at Pylabs has an installed copy of RH that old, and if no one here on python-dev steps up, there's not much we can do. This late in the game I'm inclined to postpone the patch unless we can find someone to test it. Even a patch that does no harm on existing systems isn't of much use if we can't verify that it fixes the bug. there's-always-2.3.1-ly y'rs, -Barry From skip@pobox.com Tue Jul 22 20:37:55 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 22 Jul 2003 14:37:55 -0500 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1D8E67.8010609@ocf.berkeley.edu> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> Message-ID: <16157.37523.384387.919749@montanaro.dyndns.org> Brett> This bug is still open. Skip and I have verified it works on OS Brett> X, but it *really* needs to be tested on a Red Hat 6.2 box. The thought occurred to me the other day that we ought to have a table on the website (probably on the Wiki) where people can list the kind of systems they have ready access to if they are willing to help with some tests. It would make it easier to locate people who can "configure ; make ; make test" on more obscure platforms. I'll set something up and let people know where it is. If folks on this list think it's a bad idea, I can easily dump the page. Skip From mwh@python.net Tue Jul 22 20:40:12 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 22 Jul 2003 20:40:12 +0100 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1D8E67.8010609@ocf.berkeley.edu> ("Brett C."'s message of "Tue, 22 Jul 2003 12:20:07 -0700") References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> Message-ID: <2mn0f6nyeb.fsf@starship.python.net> "Brett C." writes: > Brett C. wrote: >> Just a quick reminder, I am going off for a vacation and my >> brother's wedding tomorrow (July 13) and won't have a definite Net >> connection until July 22. >> > > OK, I am back with vacation having gained a sister-in-law and possible > housing in San Luis Obispo. > >> The bug #762934 (patch for configure.in to detect time.tzset better) >> is still open. I uploaded my own version of the patch that is more >> explicit in detecting whether the function works properly. It works >> for me, but tzset has always worked properly for me. If someone >> with Red Hat 6.2 can test it that would be great (that will close >> bug #763153). >> > > This bug is still open. Skip and I have verified it works on OS X, > but it *really* needs to be tested on a Red Hat 6.2 box. Hang on... I think the starship is RH 6.2... yep. I'll build and see what happens (tho' it's possible glibc or whatever has been upgraded). Cheers, M. -- Unfortunately, nigh the whole world is now duped into thinking that silly fill-in forms on web pages is the way to do user interfaces. -- Erik Naggum, comp.lang.lisp From barry@python.org Tue Jul 22 20:40:49 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 15:40:49 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16157.37523.384387.919749@montanaro.dyndns.org> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> Message-ID: <1058902849.13235.94.camel@yyz> On Tue, 2003-07-22 at 15:37, Skip Montanaro wrote: > Brett> This bug is still open. Skip and I have verified it works on OS > Brett> X, but it *really* needs to be tested on a Red Hat 6.2 box. > > The thought occurred to me the other day that we ought to have a table on > the website (probably on the Wiki) where people can list the kind of systems > they have ready access to if they are willing to help with some tests. It > would make it easier to locate people who can "configure ; make ; make test" > on more obscure platforms. +1. It also tells us which systems people care about . -Barry From jordan@krushen.com Tue Jul 22 20:41:34 2003 From: jordan@krushen.com (Jordan Krushen) Date: Tue, 22 Jul 2003 12:41:34 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <1058902307.13235.90.camel@yyz> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <1058902307.13235.90.camel@yyz> Message-ID: On 22 Jul 2003 15:31:47 -0400, Barry Warsaw wrote: > On Tue, 2003-07-22 at 15:20, Brett C. wrote: > >> This bug is still open. Skip and I have verified it works on OS X, but >> it *really* needs to be tested on a Red Hat 6.2 box. > > We may just be SOL here. No one at Pylabs has an installed copy of RH > that old, and if no one here on python-dev steps up, there's not much we > can do. I'm currently bored at work, so I'm downloading a 6.2 ISO to run in VMware, if that's acceptable for testing purposes. Just let me know exactly what to test, and I should be able to do that today. J. From fdrake@acm.org Tue Jul 22 20:42:31 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 22 Jul 2003 15:42:31 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16157.37523.384387.919749@montanaro.dyndns.org> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> Message-ID: <16157.37799.221673.5614@grendel.zope.com> Skip Montanaro writes: > I'll set something up and let people know where it is. If folks on this > list think it's a bad idea, I can easily dump the page. I think this is a good idea. Please put it in the dev/ area on the site; it should probably just be a .ht file in the pydotorg CVS. Any chance you're going to move your 404 report to dev/pydotorg/? ;-) Thanks! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From guido@python.org Tue Jul 22 20:45:20 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 22 Jul 2003 15:45:20 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: Your message of "Tue, 22 Jul 2003 15:40:49 EDT." <1058902849.13235.94.camel@yyz> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> Message-ID: <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> [Skip] > > The thought occurred to me the other day that we ought to have a > > table on the website (probably on the Wiki) where people can list > > the kind of systems they have ready access to if they are willing > > to help with some tests. It would make it easier to locate people > > who can "configure ; make ; make test" on more obscure platforms. Hm, what happened to the snake-farm at Lysator? Aren't they supposed to do exactly this? Is Neal around? I think he's our official rep there. --Guido van Rossum (home page: http://www.python.org/~guido/) From pje@telecommunity.com Tue Jul 22 20:51:22 2003 From: pje@telecommunity.com (Phillip J. Eby) Date: Tue, 22 Jul 2003 15:51:22 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <2mn0f6nyeb.fsf@starship.python.net> References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> Message-ID: <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> IIRC, it might be me who opened this bug in the first place, so of course I have a machine suitable for the test. :) In any case, my 'make test' of 2.3c1 fails with the test_time AEST thingy. If someone will once again give me step-by-step instructions for what they want done, I'll test it again. At 08:40 PM 7/22/03 +0100, Michael Hudson wrote: >"Brett C." writes: > > > Brett C. wrote: > >> Just a quick reminder, I am going off for a vacation and my > >> brother's wedding tomorrow (July 13) and won't have a definite Net > >> connection until July 22. > >> > > > > OK, I am back with vacation having gained a sister-in-law and possible > > housing in San Luis Obispo. > > > >> The bug #762934 (patch for configure.in to detect time.tzset better) > >> is still open. I uploaded my own version of the patch that is more > >> explicit in detecting whether the function works properly. It works > >> for me, but tzset has always worked properly for me. If someone > >> with Red Hat 6.2 can test it that would be great (that will close > >> bug #763153). > >> > > > > This bug is still open. Skip and I have verified it works on OS X, > > but it *really* needs to be tested on a Red Hat 6.2 box. > >Hang on... I think the starship is RH 6.2... yep. I'll build and see >what happens (tho' it's possible glibc or whatever has been upgraded). > >Cheers, >M. > >-- > Unfortunately, nigh the whole world is now duped into thinking that > silly fill-in forms on web pages is the way to do user interfaces. > -- Erik Naggum, comp.lang.lisp > >_______________________________________________ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev From martin@v.loewis.de Tue Jul 22 20:59:18 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 21:59:18 +0200 Subject: [Python-Dev] improved zipimport In-Reply-To: References: <1058886052.13235.19.camel@yyz> <1058888748.13235.42.camel@yyz> Message-ID: Thomas Heller writes: > It would be best if someone else who really uses zipimports would be > able to test it - I really don't want to break anything. Then 2.3 should go unchanged. If there is a way to construct proper zipfiles for zipimports, this should be sufficient. Any support for additional "kinds" of zipfiles should count as a new feature. Regards, Martin From martin@v.loewis.de Tue Jul 22 21:02:12 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 22:02:12 +0200 Subject: [Python-Dev] PyConfig.h On Solaris In-Reply-To: <3F1D8D42.4020605@btinternet.com> References: <3F1C4808.2090102@btinternet.com> <3F1D8D42.4020605@btinternet.com> Message-ID: John Abel writes: > Just a quick update. As a final attempt, before I implemented > Martin's suggestion, I chaged the order of the includes. Then you are operating Python out of its specification. See http://www.python.org/doc/current/api/includes.html Good luck, and be prepared for random crashes. > Having Python.h last in the includes, solved everything (apart from > a warning, about _FILE_OFFSET_BITS being redefined. If it's already > defined by the OS, does pyconfig.h have to define it?). Is there > somewhere to log things such as this? Does it warrant a bug report? There is no bug AFAICT. Regards, Martin From mwh@python.net Tue Jul 22 21:03:15 2003 From: mwh@python.net (Michael Hudson) Date: Tue, 22 Jul 2003 21:03:15 +0100 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> ("Phillip J. Eby"'s message of "Tue, 22 Jul 2003 15:51:22 -0400") References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> Message-ID: <2mk7aanxbw.fsf@starship.python.net> "Phillip J. Eby" writes: > IIRC, it might be me who opened this bug in the first place, so of > course I have a machine suitable for the test. :) Doesn't look like it. > In any case, my 'make test' of 2.3c1 fails with the test_time AEST > thingy. If someone will once again give me step-by-step instructions > for what they want done, I'll test it again. Well, test_time fails for me on the starship seeminly no matter waht I do (i.e. just check out from CVS or apply either of the patches mentioned in the report). This may be pilot error. Home time here. Various other locals have starship accounts, though (note you'll need to install autoconf 2.53 in ~/bin). Cheers, mwh -- Java sucks. [...] Java on TV set top boxes will suck so hard it might well inhale people from off their sofa until their heads get wedged in the card slots. --- Jon Rabone, ucam.chat From neal@metaslash.com Tue Jul 22 21:04:24 2003 From: neal@metaslash.com (Neal Norwitz) Date: Tue, 22 Jul 2003 16:04:24 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <20030722200424.GF10306@epoch.metaslash.com> On Tue, Jul 22, 2003 at 03:45:20PM -0400, Guido van Rossum wrote: > [Skip] > > > The thought occurred to me the other day that we ought to have a > > > table on the website (probably on the Wiki) where people can list > > > the kind of systems they have ready access to if they are willing > > > to help with some tests. It would make it easier to locate people > > > who can "configure ; make ; make test" on more obscure platforms. > > Hm, what happened to the snake-farm at Lysator? Aren't they supposed > to do exactly this? Is Neal around? I think he's our official rep there. Here. I was thinking Skip's idea would be bad since I'll be listed for a bunch of platforms. :-) RedHat 6.2 isn't in the snake farm. Right now, things are in pretty good shape on the snake farm builds (I watch them on a regular basis). Unfortunately, some of the problems deal with minor OS variations (like a specific patching being applied or not), so even having the "same" version of th OS isn't always enough. I have access to the following systems: RedHat: 8, 9 Solaris: 8 AIX: 4.2.1.0, 4.3.1.0, 4.3.3.0 HPUX: 11.00 A IRIX: 6.5 DecUNIX, OSF/1, Tru64: 5.0, 5.1 There's also the SF compile farm which has Linux 2.2, Max OSX 10.2, and Solaris 8. Free testdrive accounts can be setup for various configurations. For example, see http://testdrive.hp.com I've heard there are other accounts offered, but don't know any links. Neal From blunck@gst.com Tue Jul 22 21:05:57 2003 From: blunck@gst.com (Christopher Blunck) Date: Tue, 22 Jul 2003 16:05:57 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <1058902307.13235.90.camel@yyz> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <1058902307.13235.90.camel@yyz> Message-ID: <20030722200557.GA6369@homer.gst.com> I *think* I still have a copy of the ISOs laying around my house. I'll take a look and if I have available hardware, I'll spin it up. -c On Tue, Jul 22, 2003 at 03:31:47PM -0400, Barry Warsaw wrote: > On Tue, 2003-07-22 at 15:20, Brett C. wrote: > > > This bug is still open. Skip and I have verified it works on OS X, but > > it *really* needs to be tested on a Red Hat 6.2 box. > > We may just be SOL here. No one at Pylabs has an installed copy of RH > that old, and if no one here on python-dev steps up, there's not much we > can do. > > This late in the game I'm inclined to postpone the patch unless we can > find someone to test it. Even a patch that does no harm on existing > systems isn't of much use if we can't verify that it fixes the bug. > > there's-always-2.3.1-ly y'rs, > -Barry > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev -- 16:05:00 up 67 days, 5:40, 11 users, load average: 0.66, 0.32, 0.15 From skip@pobox.com Tue Jul 22 21:09:06 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 22 Jul 2003 15:09:06 -0500 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <16157.39394.738722.214026@montanaro.dyndns.org> >> The thought occurred to me the other day that we ought to have a >> table on the website (probably on the Wiki) where people can list the >> kind of systems they have ready access to if they are willing to help >> with some tests. It would make it easier to locate people who can >> "configure ; make ; make test" on more obscure platforms. Guido> Hm, what happened to the snake-farm at Lysator? Aren't they Guido> supposed to do exactly this? Is Neal around? I think he's our Guido> official rep there. Dunno. I was just thinking it would be great if Brett could check the table and fire off a quick note to someone who said they had 6.2. Skip From skip@pobox.com Tue Jul 22 21:10:29 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 22 Jul 2003 15:10:29 -0500 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <1058902849.13235.94.camel@yyz> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> Message-ID: <16157.39477.580648.181147@montanaro.dyndns.org> Brett> This bug is still open. Skip and I have verified it works on OS Brett> X, but it *really* needs to be tested on a Red Hat 6.2 box. Skip> The thought occurred to me the other day that we ought to have a Skip> table on the website (probably on the Wiki) where people can list Skip> the kind of systems they have ready access to if they are willing Skip> to help with some tests. Barry> +1. It also tells us which systems people care about . Okay, the minimal beginning is at http://www.python.org/cgi-bin/moinmoin/PythonTesters Feel free to add rows to the table. Skip From skip@pobox.com Tue Jul 22 21:10:05 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 22 Jul 2003 15:10:05 -0500 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16157.37799.221673.5614@grendel.zope.com> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <16157.37799.221673.5614@grendel.zope.com> Message-ID: <16157.39453.412154.232500@montanaro.dyndns.org> >> I'll set something up and let people know where it is. If folks on >> this list think it's a bad idea, I can easily dump the page. Fred> I think this is a good idea. Please put it in the dev/ area on Fred> the site; it should probably just be a .ht file in the pydotorg Fred> CVS. Well, my intent was to put it in the Wiki. I certainly don't want to be the rate-limiting factor in getting peoples' info in the table. Fred> Any chance you're going to move your 404 report to dev/pydotorg/? Fred> ;-) Sure. Skip From theller@python.net Tue Jul 22 21:12:45 2003 From: theller@python.net (Thomas Heller) Date: Tue, 22 Jul 2003 22:12:45 +0200 Subject: [Python-Dev] improved zipimport In-Reply-To: (Martin v.'s message of "22 Jul 2003 21:59:18 +0200") References: <1058886052.13235.19.camel@yyz> <1058888748.13235.42.camel@yyz> Message-ID: <4r1enww2.fsf@python.net> martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes: > Thomas Heller writes: > >> It would be best if someone else who really uses zipimports would be >> able to test it - I really don't want to break anything. > > Then 2.3 should go unchanged. If there is a way to construct proper > zipfiles for zipimports, this should be sufficient. Any support for > additional "kinds" of zipfiles should count as a new feature. It's already checked in. Thomas From fdrake@acm.org Tue Jul 22 21:14:04 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 22 Jul 2003 16:14:04 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16157.39453.412154.232500@montanaro.dyndns.org> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <16157.37799.221673.5614@grendel.zope.com> <16157.39453.412154.232500@montanaro.dyndns.org> Message-ID: <16157.39692.723774.759941@grendel.zope.com> Skip Montanaro writes: > Well, my intent was to put it in the Wiki. I certainly don't want to be the > rate-limiting factor in getting peoples' info in the table. Works for me! > Fred> Any chance you're going to move your 404 report to dev/pydotorg/? > Fred> ;-) > > Sure. Thanks! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From drifty@alum.berkeley.edu Tue Jul 22 21:21:32 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 13:21:32 -0700 Subject: [Python-Dev] cygwin errors In-Reply-To: References: Message-ID: <3F1D9CCC.4050009@ocf.berkeley.edu> Tim Peters wrote: > [Jason Tishler] > >>Just to confirm, the above is Win32 Python -- not Cygwin. Right? > > > Yes, it was Win32 Python -- and also Jeremy's Linux. It "got fixed" by > focing the locale to "C" at the end of test_logging.py. That's probably not > a correct fix, just a bandaid. Brett is on vacation, and I have no real > idea what strptime is trying to do with locale; it appears to be a bug that > strptime tries to be locale-independent but that the strptime test in > test_time.py fails if test_logging (which changes the locale) isn't hacked > to force locale (back?) to "C" at its end. > _strptime just uses locale to find out what language is used so as to make sure that improper info is not used if the language is changed between calls to time.strptime . I don't use it for anything else nor do I touch any settings. If there are any issues it probably is in time.strftime which uses the locale info much more. I can try to see what the problems are if someone can run:: >>> import time >>> time.strftime("%c") >>> import _strptime >>> _strptime.TimeRE()['c'] after running test_logging to trigger the failure. That will give me what strftime thinks the format for "%c" is and what strptime thinks it should be. -Brett From zooko@zooko.com Tue Jul 22 21:24:05 2003 From: zooko@zooko.com (Zooko) Date: 22 Jul 2003 16:24:05 -0400 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: Message from "Tim Peters" of "Tue, 22 Jul 2003 11:58:11 EDT." References: Message-ID: I wanted to see this bsddb3 explosion for myself, so I tried to build the module, but couldn't figure out how to do it. So I opened a bug report under the Build category: [ 775850 ] pybsddb build fails http://sourceforge.net/tracker/index.php?func=detail&aid=775850&group_id=5470&atid=105470 Regards, Zooko > [Tim] > >> The evidence suggests there are still potentially catastrophic bugs > >> in bsddb3! > > [martin@v.loewis.de] > > So far, I have interpreted all failures in test_bsddb3 as being > > related to the explicit use of transactions. Since the historic bsddb > > module does not provide an interface for transactions, I have always > > concluded that existing code won't be affected by these problems. > > I'm guessing we're talking about different things, then. These things have > been discussed recently here: > > + Reports of bsddb3 database corruption in spambayes. > > + Likewise in Richie Hindle's multithreaded test driver, plus > hardware faults. > > + Hangs and AssertionErrors in the tests from > Lib/bsddb/test/test_thread.py. > > Richie's program uses only our wrapper's __delitem__, __setitem__ and > __getitem__ implementations. spambayes does the same. While some tests in > test_thread.py use transactions, the AssertionError Skip reported was in a > test that does not use transactions: > > http://mail.python.org/pipermail/python-dev/2003-July/036920.html > > Fred and Barry also saw the same kind of AssertionErrors in > SimpleThreadBase.writerThread, on the same line. Finally, the hangs Barry > and I saw were in test02_SimpleLocks, which is also devoid of transactions. > > So I haven't seen any evidence of problems with transactions -- unless these > things use transactions implicitly in some way. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > From drifty@alum.berkeley.edu Tue Jul 22 21:29:40 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 13:29:40 -0700 Subject: [Python-Dev] 2.3rc1 delayed In-Reply-To: References: Message-ID: <3F1D9EB4.30201@ocf.berkeley.edu> Tim Peters wrote: > [Raymond Hettinger] > >>Please forgive if I'm stating the obvious, but the failing tests >>are the ones that should be changed, not the ones that are >>"polluting" the environment. >> >>When I was working on test_warnings.py, I had found that other >>tests had set warning filters without clearing them. Rather than >>alter the polluters, I fixed test_warnings so it either worked with >>existing filters or temporarily set its own -- that way the test would >>work in any combination with other tests. In a way, the polluters >>were helpful because they helped flag an unnecessary state >>dependency in the test_suite. >> >>So if test_strptime is going to be locale dependent, it should >>temporarily set what it expects to find. > > > I'm not sure it's as simple as that either. For example, _strptime.py's > LocaleTime class's .lang property caches the first value it sees, so that it > will continue returning the same thing even if the user changes locale. As > an American, I don't know whether that's a feature or a bug. Feature. A LocaleTime instance is not to be used if the lang attribute does not match what _strptime._getlang returns. _strptime.strptime checks this on each call to clear the cached TimeRE object it uses to generate its regexes. > Given all the > locale-aware code in _strptime.py, I have to guess that it *intended* to be > locale-independent, and it's obvious that the test_strptime.py test that > failed is trying like hell not to assume any particular locale is in effect: > > def test_lang(self): > # Make sure lang is set > self.failUnless(self.LT_ins.lang in > (locale.getdefaultlocale()[0], > locale.getlocale(locale.LC_TIME), > ''), > "Setting of lang failed") > > Your guess about what that's testing is better than mine . > The test is to make sure the lang attribute was set to what it should be set to; yes, it is that simple. And the self.LT_ins object is in the setUp method and is recreated after every call so there is no worry of a stale instance. -Brett From tim.one@comcast.net Tue Jul 22 21:40:11 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 16:40:11 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <3F1D9CCC.4050009@ocf.berkeley.edu> Message-ID: [Brett C.] > ... > I can try to see what the problems are if someone can run:: > > >>> import time > >>> time.strftime("%c") > >>> import _strptime > >>> _strptime.TimeRE()['c'] > > after running test_logging to trigger the failure. There is no failure anymore, because Jermey added if cur_locale: locale.setlocale(locale.LC_ALL, "C") to the end of test_logging.py. This almost certainly isn't a correct fix, though (test_logging should restore the locale to what it was before test_logging started just as a matter of cleaning up after itself, but it remains surprising that test_strptime fails if test_logging doesn't). If you revert his change, then, e.g., C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_logging test_strptime test_logging test_strptime test test_strptime failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_strptime.py", line 96, in test_lang "Setting of lang failed") File "C:\Code\python\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: Setting of lang failed 1 test OK. 1 test failed: test_strptime C:\Code\python\PCbuild> At the point test_strptime fails, on my box the relevant expressions have the following values: self.LT_ins.lang 'English_United States' locale.getdefaultlocale()[0] 'en_US' locale.getlocale(locale.LC_TIME) ['English_United States', '1252'] so self.failUnless(self.LT_ins.lang in (locale.getdefaultlocale()[0], locale.getlocale(locale.LC_TIME), ''), "Setting of lang failed") fails. It doesn't look like the test code expects locale.getlocale(locale.LC_TIME) to return a list, but I don't know what's expected here ... From tim.one@comcast.net Tue Jul 22 21:40:37 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 16:40:37 -0400 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: Message-ID: [Zooko] > I wanted to see this bsddb3 explosion for myself, so I tried to build > the module, but couldn't figure out how to do it. So I opened a bug > report under the Build category: > > [ 775850 ] pybsddb build fails > > http://www.python.org/sf/775850 You should probably add detailed info to that bug report about the flavor and version of Linux you're using, since nobody on Python-Dev has reported problems building 2.3. From jordan@krushen.com Tue Jul 22 21:50:39 2003 From: jordan@krushen.com (Jordan Krushen) Date: Tue, 22 Jul 2003 13:50:39 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <1058902307.13235.90.camel@yyz> Message-ID: On Tue, 22 Jul 2003 12:41:34 -0700, Jordan Krushen wrote: > I'm currently bored at work, so I'm downloading a 6.2 ISO to run in > VMware, if that's acceptable for testing purposes. Just let me know > exactly what to test, and I should be able to do that today. On a freshly-installed RedHat 6.2 VMware box (./configure, make, make test) : test_time test test_time failed -- Traceback (most recent call last): File "/var/src/Python-2.3c1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/var/src/Python-2.3c1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST 1 test failed: test_time 29 tests skipped: test_aepack test_al test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_largefile test_linuxaudiodev test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_urllibnet test_winreg test_winsound 2 skips unexpected on linux2: test_bsddb test_mpz J. From drifty@alum.berkeley.edu Tue Jul 22 21:56:04 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 13:56:04 -0700 Subject: [Python-Dev] cygwin errors In-Reply-To: References: Message-ID: <3F1DA4E4.50603@ocf.berkeley.edu> Tim Peters wrote: > [Brett C.] > >>... >>I can try to see what the problems are if someone can run:: >> >> >>> import time >> >>> time.strftime("%c") >> >>> import _strptime >> >>> _strptime.TimeRE()['c'] >> >>after running test_logging to trigger the failure. > > > There is no failure anymore, because Jermey added > > if cur_locale: > locale.setlocale(locale.LC_ALL, "C") > > to the end of test_logging.py. This almost certainly isn't a correct fix, > though (test_logging should restore the locale to what it was before > test_logging started just as a matter of cleaning up after itself, but it > remains surprising that test_strptime fails if test_logging doesn't). If > you revert his change, then, e.g., > > C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_logging > test_strptime > test_logging > test_strptime > test test_strptime failed -- Traceback (most recent call last): > File "C:\Code\python\lib\test\test_strptime.py", line 96, in test_lang > "Setting of lang failed") > File "C:\Code\python\lib\unittest.py", line 268, in failUnless > if not expr: raise self.failureException, msg > AssertionError: Setting of lang failed > > 1 test OK. > 1 test failed: > test_strptime > > C:\Code\python\PCbuild> > > > At the point test_strptime fails, on my box the relevant expressions have > the following values: > > self.LT_ins.lang 'English_United States' > locale.getdefaultlocale()[0] 'en_US' > locale.getlocale(locale.LC_TIME) ['English_United States', '1252'] > > so > > self.failUnless(self.LT_ins.lang in (locale.getdefaultlocale()[0], > locale.getlocale(locale.LC_TIME), > ''), > "Setting of lang failed") > > fails. It doesn't look like the test code expects > > locale.getlocale(locale.LC_TIME) > > to return a list, but I don't know what's expected here ... > Argh! The test is wrong. It should be locale.getlocale(locale.LC_TIME)[0] that is being checked against. Crap, sorry to have caused all of this trouble over such a stupid little mistake. I am personally amazed it took so long for the error to show up. I can check this minute change in, but what branch/tag/thing do you want it done to? -Brett From john.abel@pa.press.net Tue Jul 22 22:02:41 2003 From: john.abel@pa.press.net (John Abel) Date: Tue, 22 Jul 2003 22:02:41 +0100 Subject: [Python-Dev] PyConfig.h On Solaris References: <3F1C4808.2090102@btinternet.com><3F1D8D42.4020605@btinternet.com> Message-ID: <001601c35094$d66ebfb0$66656565@hallows> > John Abel writes: > > > Just a quick update. As a final attempt, before I implemented > > Martin's suggestion, I chaged the order of the includes. > > Then you are operating Python out of its specification. See > > http://www.python.org/doc/current/api/includes.html > > Good luck, and be prepared for random crashes. > > > Having Python.h last in the includes, solved everything (apart from > > a warning, about _FILE_OFFSET_BITS being redefined. If it's already > > defined by the OS, does pyconfig.h have to define it?). Is there > > somewhere to log things such as this? Does it warrant a bug report? > > There is no bug AFAICT. > OK, I can see why Python.h has to be first, but surely, abiding by the spec shouldn't prevent code from executing properly? Should I raise a bug report for this? I'm guessing that only Solaris is affected (though maybe other BSD-types are, too? AFAIK, only Solaris has the /proc oddity). I'd like to be able to produce compliant modules. I'd like to help, if I can. Regards John From tim.one@comcast.net Tue Jul 22 22:05:14 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 17:05:14 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <3F1DA4E4.50603@ocf.berkeley.edu> Message-ID: [Brett] > Argh! The test is wrong. It should be > locale.getlocale(locale.LC_TIME)[0] that is being checked against. > Crap, sorry to have caused all of this trouble over such a stupid > little mistake. I am personally amazed it took so long for the error > to show up. That's OK. There was another failure in test_time, but I don't remember that details anymore. > I can check this minute change in, but what branch/tag/thing do you > want it done to? The head, please. From drifty@alum.berkeley.edu Tue Jul 22 22:09:14 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 14:09:14 -0700 Subject: [Python-Dev] cygwin errors In-Reply-To: References: Message-ID: <3F1DA7FA.6090409@ocf.berkeley.edu> Tim Peters wrote: > [Brett] > >>Argh! The test is wrong. It should be >>locale.getlocale(locale.LC_TIME)[0] that is being checked against. >>Crap, sorry to have caused all of this trouble over such a stupid >>little mistake. I am personally amazed it took so long for the error >>to show up. > > > That's OK. There was another failure in test_time, but I don't remember > that details anymore. > Is it that tzset test that keeps failing that everyone who has Red Hat 6.2 seems to be about to test at some point today? > >>I can check this minute change in, but what branch/tag/thing do you >>want it done to? > > > The head, please. > Done. Should Jeremy's change to test_logging be backed out? -Brett From barry@python.org Tue Jul 22 22:08:07 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 17:08:07 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <3F1DA4E4.50603@ocf.berkeley.edu> References: <3F1DA4E4.50603@ocf.berkeley.edu> Message-ID: <1058908086.13235.136.camel@yyz> On Tue, 2003-07-22 at 16:56, Brett C. wrote: > Argh! The test is wrong. It should be > locale.getlocale(locale.LC_TIME)[0] that is being checked against. > Crap, sorry to have caused all of this trouble over such a stupid little > mistake. I am personally amazed it took so long for the error to show up. > > I can check this minute change in, but what branch/tag/thing do you want > it done to? Please check this into the head. We still don't understand why test_logging.py has to futz with the locale. -Barry From Jack.Jansen@cwi.nl Tue Jul 22 22:09:50 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 22 Jul 2003 23:09:50 +0200 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1D8E67.8010609@ocf.berkeley.edu> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> Message-ID: On dinsdag, 22 juli 2003, at 21:20PM, Brett C. wrote: > >> The macostools error (bug #763708) is still happening and I still >> think it could be an OS X bug and not ours. > > This is still happening and I am working with Jack to solve this. It turns out Brett was using an ucs4 build of Python, and the bug is related to that. So I've lowered the priority and changed the title. If someone sees the bug in a normal Python build or someone has good reason to find the bug critical even if it only affects ucs4 builds: please raise the priority again. But this won't be a trivial bug to fix (basically I think I'm using the pointers straight out of the PyUnicode objects and passing them to Apple routines, so fixing it would require allocating temporary buffers and all that jazz). From skip@pobox.com Tue Jul 22 22:17:09 2003 From: skip@pobox.com (Skip Montanaro) Date: Tue, 22 Jul 2003 16:17:09 -0500 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> Message-ID: <16157.43477.486546.182450@montanaro.dyndns.org> Jack> It turns out Brett was using an ucs4 build of Python, and the bug Jack> is related to that.... Dumb-ass question: What's a "ucs4 build of Python" and how does one create such a thing? I see no mention of ucs4 in the output from configure --help. Thx, Skip From martin@v.loewis.de Tue Jul 22 22:18:11 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 22 Jul 2003 23:18:11 +0200 Subject: [Python-Dev] PyConfig.h On Solaris In-Reply-To: <001601c35094$d66ebfb0$66656565@hallows> References: <3F1C4808.2090102@btinternet.com> <3F1D8D42.4020605@btinternet.com> <001601c35094$d66ebfb0$66656565@hallows> Message-ID: "John Abel" writes: > OK, I can see why Python.h has to be first, but surely, abiding by the spec > shouldn't prevent code from executing properly? Should I raise a bug report > for this? For what? That you can't compile a certain Solaris header, if the application adds some system-specifed #defines? That is a Solaris bug, not a Python bug. All system headers ought to work under _LARGEFILE_SOURCE and _FILE_OFFSET_BITS=64. > I'm guessing that only Solaris is affected (though maybe other > BSD-types are, too? AFAIK, only Solaris has the /proc oddity). I'd > like to be able to produce compliant modules. I'd like to help, if > I can. I don't see that Python can or should change here. We have to define _FILE_OFFSET_BITS, and we have to define it consistently across all object files, or else we can't free exchange data structures which contain off_t fields across functions. Regards, Martin From Jack.Jansen@cwi.nl Tue Jul 22 22:20:58 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 22 Jul 2003 23:20:58 +0200 Subject: [Python-Dev] Test_coercion failing on Panther for complex numbers Message-ID: <62D286F2-BC8A-11D7-A6B7-000A27B19B96@cwi.nl> I need a little guidance with bug #775892. I think it's non-serious, but I'm not sure (and I don't know how easy it is to fix). Test_coercion is failing on the beta for MacOSX 10.3. All the failures have the same form: the output is (XXX-0j) in stead of the expected (XXX+0j). From neal@metaslash.com Tue Jul 22 22:21:05 2003 From: neal@metaslash.com (Neal Norwitz) Date: Tue, 22 Jul 2003 17:21:05 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16157.43477.486546.182450@montanaro.dyndns.org> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.43477.486546.182450@montanaro.dyndns.org> Message-ID: <20030722212105.GG10306@epoch.metaslash.com> On Tue, Jul 22, 2003 at 04:17:09PM -0500, Skip Montanaro wrote: > > Jack> It turns out Brett was using an ucs4 build of Python, and the bug > Jack> is related to that.... > > Dumb-ass question: What's a "ucs4 build of Python" and how does one create > such a thing? I see no mention of ucs4 in the output from configure --help. ./configure --enable-unicode=ucs4 (Necessary for Tkinter on RH 9) From fdrake@acm.org Tue Jul 22 22:21:04 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 22 Jul 2003 17:21:04 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16157.43477.486546.182450@montanaro.dyndns.org> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.43477.486546.182450@montanaro.dyndns.org> Message-ID: <16157.43712.321957.286723@grendel.zope.com> Skip Montanaro writes: > Dumb-ass question: What's a "ucs4 build of Python" and how does one create > such a thing? I see no mention of ucs4 in the output from configure --help. Look at the --enable-unicode option. A ucs4 build is particularly desirable on RH9, since they're using a UCS4 build of Tcl/Tk. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From drifty@alum.berkeley.edu Tue Jul 22 22:25:59 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 14:25:59 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <16157.43477.486546.182450@montanaro.dyndns.org> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.43477.486546.182450@montanaro.dyndns.org> Message-ID: <3F1DABE7.4010203@ocf.berkeley.edu> Skip Montanaro wrote: > Jack> It turns out Brett was using an ucs4 build of Python, and the bug > Jack> is related to that.... > > Dumb-ass question: What's a "ucs4 build of Python" and how does one create > such a thing? I see no mention of ucs4 in the output from configure --help. > It is using --enable-unicode=ucs4 for configure. From my understanding that causes Python to store all strings internally as UCS-4 Unicode strings. Picked this up from Barry in an email to the list once and figured it sounded like a good idea. -Brett From kbk@shore.net Tue Jul 22 22:25:25 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Tue, 22 Jul 2003 17:25:25 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <2mk7aanxbw.fsf@starship.python.net> (Michael Hudson's message of "Tue, 22 Jul 2003 21:03:15 +0100") References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> Message-ID: Michael Hudson writes: > Well, test_time fails for me on the starship seeminly no matter waht I > do (i.e. just check out from CVS or apply either of the patches > mentioned in the report). This may be pilot error. Redhat 6.0 + libc.so.6 2.1.3 autoconf 2.53 Using 2.3c1, no patch: test_time test test_time failed -- Traceback (most recent call last): File "/home/kbk/PYTHON/python/dist/src/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/kbk/PYTHON/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ====================== Apply patch 55665: tzset_AEST.diff 2003-7-12 18:01 bcannon: =========================== What have I done?? Index: configure.in =================================================================== RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.425 diff -c -c -p -r1.425 configure.in *** configure.in 13 Jul 2003 09:46:13 -0000 1.425 --- configure.in 22 Jul 2003 21:18:33 -0000 *************** AC_CACHE_VAL(ac_cv_working_tzset, [ *** 2775,2794 **** AC_TRY_RUN([ #include #include int main() { ! int gmt_hour; ! int eastern_hour; ! time_t now; ! now = time((time_t*)NULL); putenv("TZ=UTC+0"); tzset(); ! gmt_hour = localtime(&now)->tm_hour; putenv("TZ=EST+5EDT,M4.1.0,M10.5.0"); tzset(); ! eastern_hour = localtime(&now)->tm_hour; ! if (eastern_hour == gmt_hour) exit(1); exit(0); } ], --- 2775,2805 ---- AC_TRY_RUN([ #include #include + #include int main() { ! /* Note that we need to ensure that not only does tzset(3) ! do 'something' with localtime, but it works as documented ! in the library reference and as expected by the test suite. */ ! time_t xmas = 1040774400; /* GMT-based */ ! putenv("TZ=UTC+0"); tzset(); ! if (localtime(&xmas)->tm_hour != 0) ! exit(1); ! putenv("TZ=EST+5EDT,M4.1.0,M10.5.0"); tzset(); ! if (localtime(&xmas)->tm_hour != 19) ! exit(1); ! ! putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0"); ! tzset(); ! if (localtime(&xmas)->tm_hour != 11) exit(1); + if (strcmp(localtime(&xmas)->tm_zone, "AEDT")) + exit(1); + exit(0); } ], =========================== ./configure make =========================== Run the test: [kbk@float ~/PYSRC]$ python2.3 -c "from test import test_time; > test_time.test_main()" test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... FAIL ====================================================================== FAIL: test_tzset (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- Ran 8 tests in 2.254s FAILED (failures=1) Traceback (most recent call last): File "", line 2, in ? File "/usr/local/lib/python2.3/test/test_time.py", line 125, in test_main test_support.run_unittest(TimeTestCase) File "/usr/local/lib/python2.3/test/test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "/usr/local/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST -- KBK From tim.one@comcast.net Tue Jul 22 22:28:03 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 17:28:03 -0400 Subject: [Python-Dev] Test_coercion failing on Panther for complex numbers In-Reply-To: <62D286F2-BC8A-11D7-A6B7-000A27B19B96@cwi.nl> Message-ID: [Jack Jansen] > I need a little guidance with bug #775892. I think it's non-serious, > but I'm not sure (and I don't know how easy it is to fix). > > Test_coercion is failing on the beta for MacOSX 10.3. All the failures > have the same form: the output is (XXX-0j) in stead of the expected > (XXX+0j). It isn't serious, and we've (you & I) been thru this failure before . If the compiler for this box has some sort of switch named along the lines of "don't used fused multiply-add", it should cure it. Or we could rewrite the test not to rely on the (more accidental than not, given the state of C compilers) sign of 0. From barry@python.org Tue Jul 22 22:29:47 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 17:29:47 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1DABE7.4010203@ocf.berkeley.edu> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.43477.486546.182450@montanaro.dyndns.org> <3F1DABE7.4010203@ocf.berkeley.edu> Message-ID: <1058909387.13235.138.camel@yyz> On Tue, 2003-07-22 at 17:25, Brett C. wrote: > Picked this up from Barry in an email to the list once and figured it > sounded like a good idea. Heh, I only need to do this so tkinter works on RH9. ;) -Barry From neal@metaslash.com Tue Jul 22 22:30:50 2003 From: neal@metaslash.com (Neal Norwitz) Date: Tue, 22 Jul 2003 17:30:50 -0400 Subject: [Python-Dev] Test_coercion failing on Panther for complex numbers In-Reply-To: <62D286F2-BC8A-11D7-A6B7-000A27B19B96@cwi.nl> References: <62D286F2-BC8A-11D7-A6B7-000A27B19B96@cwi.nl> Message-ID: <20030722213050.GH10306@epoch.metaslash.com> On Tue, Jul 22, 2003 at 11:20:58PM +0200, Jack Jansen wrote: > I need a little guidance with bug #775892. I think it's non-serious, > but I'm not sure (and I don't know how easy it is to fix). > > Test_coercion is failing on the beta for MacOSX 10.3. All the failures > have the same form: the output is (XXX-0j) in stead of the expected > (XXX+0j). This problem occurs on AIX and IRIX when using the vendor compilers IIRC. It's possible you can fix the problem by using a compiler flag which changes the math processing. This should be fixed generally sooner or later. Neal From tim.one@comcast.net Tue Jul 22 22:23:17 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 17:23:17 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <3F1DA7FA.6090409@ocf.berkeley.edu> Message-ID: [Tim] >> That's OK. There was another failure in test_time, but I don't >> remember that details anymore. [Brett] > Is it that tzset test that keeps failing that everyone who has Red Hat > 6.2 seems to be about to test at some point today? No -- see later email. > Done. Should Jeremy's change to test_logging be backed out? test_logging should clean up after itself as a matter of principle. It wasn't. I'm not sure it is now, though -- hardcoding locale to "C" doesn't necessarily restore the initial value. Nobody seems to understand why test_logging changed the locale to begin with, though! The easiest way for it clean up after itself would be not to do anything in need of cleaning up. From drifty@alum.berkeley.edu Tue Jul 22 22:35:10 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 14:35:10 -0700 Subject: [Python-Dev] cygwin errors In-Reply-To: References: Message-ID: <3F1DAE0E.2050803@ocf.berkeley.edu> Tim Peters wrote: > The other error here (which Jeremy also saw on Linux) came from running 3 > tests in a particular order. Here I'm running them with Jeremy's locale > hack in test_logging reverted (there is no failure when that hack is in > place): > > C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime > test_logging > test_time > test_strptime > test_logging > test_time > test test_time failed -- Traceback (most recent call last): > File "C:\Code\python\lib\test\test_time.py", line 49, in test_strptime > self.fail('conversion specifier: %r failed.' % format) > File "C:\Code\python\lib\unittest.py", line 260, in fail > raise self.failureException, msg > AssertionError: conversion specifier: ' %c' failed. > > 2 tests OK. > 1 test failed: > test_time > OK. This is where running: >>> import time >>> time.strftime("%c") >>> import _strptime >>> _strptime.TimeRE()['c'] can help me try to diagnose this (I can't reproduce this under OS X). This will give me what strftime is spitting out and what regex strptime would be using to match against it. -Brett From neal@metaslash.com Tue Jul 22 22:34:29 2003 From: neal@metaslash.com (Neal Norwitz) Date: Tue, 22 Jul 2003 17:34:29 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <20030722200424.GF10306@epoch.metaslash.com> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> Message-ID: <20030722213429.GI10306@epoch.metaslash.com> On Tue, Jul 22, 2003 at 04:04:24PM -0400, Neal Norwitz wrote: > > RedHat 6.2 isn't in the snake farm. Right now, things are in pretty > good shape on the snake farm builds (I watch them on a regular basis). Whoops, I lied. The snake-farm does have RedHat 6.2 that runs on an Alpha. test_time fails on it, as does test_grp, test_pwd, and test_struct in my builds. In the automated builds, only test_grp and test_time fail. I'll see what I can do about these, but I'm leaving for vacation tomorrow. Be back Sunday. Neal From kbk@shore.net Tue Jul 22 22:41:36 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Tue, 22 Jul 2003 17:41:36 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <2mk7aanxbw.fsf@starship.python.net> (Michael Hudson's message of "Tue, 22 Jul 2003 21:03:15 +0100") References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> Message-ID: Michael Hudson writes: >This may be pilot error. > And after I woke up and ran make install I got what appears to be the same thing, though I got it a little faster :-) [kbk@float ~/PYSRC]$ python2.3 -c "from test import test_time; > test_time.test_main() > " test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... FAIL ====================================================================== FAIL: test_tzset (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- Ran 8 tests in 2.206s FAILED (failures=1) Traceback (most recent call last): File "", line 2, in ? File "/usr/local/lib/python2.3/test/test_time.py", line 125, in test_main test_support.run_unittest(TimeTestCase) File "/usr/local/lib/python2.3/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/usr/local/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST -- KBK From tim.one@comcast.net Tue Jul 22 22:19:06 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 17:19:06 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: Message-ID: The other error here (which Jeremy also saw on Linux) came from running 3 tests in a particular order. Here I'm running them with Jeremy's locale hack in test_logging reverted (there is no failure when that hack is in place): C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test_logging test_time test test_time failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\Code\python\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. 2 tests OK. 1 test failed: test_time From drifty@alum.berkeley.edu Tue Jul 22 22:46:21 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 14:46:21 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> Message-ID: <3F1DB0AD.90407@ocf.berkeley.edu> Kurt B. Kaiser wrote: > Michael Hudson writes: > > >>Well, test_time fails for me on the starship seeminly no matter waht I >>do (i.e. just check out from CVS or apply either of the patches >>mentioned in the report). This may be pilot error. > > > Redhat 6.0 + > libc.so.6 2.1.3 > autoconf 2.53 > > > Using 2.3c1, no patch: > > test_time > test test_time failed -- Traceback (most recent call last): > File "/home/kbk/PYTHON/python/dist/src/Lib/test/test_time.py", line 107, in test_tzset > self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) > File "/home/kbk/PYTHON/python/dist/src/Lib/unittest.py", line 268, in failUnless > if not expr: raise self.failureException, msg > AssertionError: AEST > > ====================== > Apply patch 55665: tzset_AEST.diff 2003-7-12 18:01 bcannon: > > > > =========================== > What have I done?? > Did you run autoreconf? That is an important step since it regenerates configure from the patch file. -Brett From Jack.Jansen@cwi.nl Tue Jul 22 22:49:54 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Tue, 22 Jul 2003 23:49:54 +0200 Subject: [Python-Dev] Test_coercion failing on Panther for complex numbers In-Reply-To: References: Message-ID: <6E0614E7-BC8E-11D7-A6B7-000A27B19B96@cwi.nl> On dinsdag, 22 juli 2003, at 23:28PM, Tim Peters wrote: > [Jack Jansen] >> I need a little guidance with bug #775892. I think it's non-serious, >> but I'm not sure (and I don't know how easy it is to fix). >> >> Test_coercion is failing on the beta for MacOSX 10.3. All the failures >> have the same form: the output is (XXX-0j) in stead of the expected >> (XXX+0j). > > It isn't serious, and we've (you & I) been thru this failure before > . > If the compiler for this box has some sort of switch named along the > lines > of "don't used fused multiply-add", it should cure it. Ah... Long ago in a universe far from here... I remember, I had the same problem on MacOS9 at some point. But the strange thing with the current incarnation of the problem is that the exact same binary (build on OSX 10.2) passes test_coercion on 10.2 but fails it on 10.3. Could the C library be involved? From tim.one@comcast.net Tue Jul 22 22:50:49 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 17:50:49 -0400 Subject: [Python-Dev] cygwin errors In-Reply-To: <3F1DAE0E.2050803@ocf.berkeley.edu> Message-ID: [Tim] >> The other error here (which Jeremy also saw on Linux) came from >> running 3 tests in a particular order. Here I'm running them with >> Jeremy's locale hack in test_logging reverted (there is no failure >> when that hack is in place): >> >> C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime >> test_logging >> test_time >> test_strptime test_logging >> test_time >> test test_time failed -- Traceback (most recent call last): >> File "C:\Code\python\lib\test\test_time.py", line 49, in >> test_strptime self.fail('conversion specifier: %r failed.' % >> format) File "C:\Code\python\lib\unittest.py", line 260, in fail >> raise self.failureException, msg >> AssertionError: conversion specifier: ' %c' failed. >> >> 2 tests OK. >> 1 test failed: >> test_time >> [Brett C.] > OK. This is where running: > > >>> import time > >>> time.strftime("%c") > >>> import _strptime > >>> _strptime.TimeRE()['c'] > > can help me try to diagnose this (I can't reproduce this under OS X). > This will give me what strftime is spitting out and what regex > strptime would be using to match against it. After reverting Jeremy's hack to test_logging, and hacking regrtest.py to stop doing sys.exit(): C:\Code\python\PCbuild>python -i ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test_logging test_time test test_time failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\Code\python\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. 2 tests OK. 1 test failed: test_time >>> import time >>> time.strftime("%c") '07/22/2003 05:44:01 PM' >>> import _strptime >>> _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' >>> Now the same thing with Jeremy's test_logging hack restored: C:\Code\python\PCbuild>python -i ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test_logging test_time All 3 tests OK. >>> import time >>> time.strftime("%c") '07/22/03 17:47:26' >>> import _strptime >>> _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' >>> The regexp appears to be the same, but strftime's result has switched from (apparently) 12-hour + AM/PM time to 24-hour time. From john.abel@pa.press.net Tue Jul 22 22:48:58 2003 From: john.abel@pa.press.net (John Abel) Date: Tue, 22 Jul 2003 22:48:58 +0100 Subject: [Python-Dev] PyConfig.h On Solaris References: <3F1C4808.2090102@btinternet.com><3F1D8D42.4020605@btinternet.com><001601c35094$d66ebfb0$66656565@hallows> Message-ID: <002501c3509b$c2382c00$66656565@hallows> > > OK, I can see why Python.h has to be first, but surely, abiding by the spec > > shouldn't prevent code from executing properly? Should I raise a bug report > > for this? > > For what? That you can't compile a certain Solaris header, if the > application adds some system-specifed #defines? That is a Solaris bug, > not a Python bug. All system headers ought to work under > _LARGEFILE_SOURCE and _FILE_OFFSET_BITS=64. > > > I'm guessing that only Solaris is affected (though maybe other > > BSD-types are, too? AFAIK, only Solaris has the /proc oddity). I'd > > like to be able to produce compliant modules. I'd like to help, if > > I can. > > I don't see that Python can or should change here. We have to define > _FILE_OFFSET_BITS, and we have to define it consistently across all > object files, or else we can't free exchange data structures which > contain off_t fields across functions. > Martin, Thanks for your help. It's a shame that Sun don't hurry up, and deprecate the ioctl method of reading /proc, as it seems that where most of the bother comes from. Maybe that's why no-one else seems to have written anything for parsing of /proc (in Python, or Perl). The module I've written, only uses open, lseek, and read. When it's finally finished, I'll distribute it with a warning. Regards John PS, for those that are interested, I've included the working (non-compliant) code. I'd appreciate any pointers. /* psinfomodule.c - a Python module to return PS information */ #include #include #include #include #include #include #include "Python.h" static PyObject * psinfo_pidinfo(PyObject *self, PyObject *args) { PyObject *queryPid; char procBuf[32]; char cmdLine[255]; char cmdArgs[255]; psinfo_t psBuf; int fdPSFile; if (!PyArg_ParseTuple(args, "l:pidinfo", &queryPid) ) { return NULL; } (void)sprintf(procBuf,"/proc/%ld/psinfo", (long)queryPid); if ((fdPSFile = open(procBuf, O_RDONLY)) != -1 ) { if ( read(fdPSFile, &psBuf, sizeof(psBuf)) == sizeof(psBuf) ) { (void)sprintf(cmdLine, "%s", psBuf.pr_fname ); (void)sprintf(cmdArgs, "%s", psBuf.pr_psargs ); } else{ return NULL; } close(fdPSFile); } return Py_BuildValue( "ss", cmdLine, cmdArgs ); } static PyObject * psinfo_fullpidinfo(PyObject *self, PyObject *args) { PyObject *queryPid; char procBuf[50]; char asBuf[50]; char argStr[512], cmdArgs[1024]; char **argvp; int fdFile, counter; struct psinfo psBuf; if (!PyArg_ParseTuple(args, "i:pidinfo", &queryPid) ) { return NULL; } (void)sprintf(procBuf,"/proc/%i/psinfo", (int)queryPid); (void)sprintf(asBuf,"/proc/%i/as", (int)queryPid); if ((fdFile = open(procBuf, O_RDONLY)) != -1 ) { if (read(fdFile, &psBuf, sizeof(struct psinfo)) == -1 ) { return NULL; } close(fdFile); if ((fdFile = open(asBuf, O_RDONLY)) == -1 ) { return NULL; } else { argvp=(char **) malloc(sizeof(char *) * (psBuf.pr_argc + 1)); if (lseek(fdFile, psBuf.pr_argv, SEEK_SET) == -1) { return NULL; } if (read(fdFile, argvp, sizeof(char *) * (psBuf.pr_argc + 1)) == -1 ) { printf( "Read Failed" ); return NULL; } for ( counter=0; counter < psBuf.pr_argc; counter++ ) { if (lseek(fdFile, argvp[ counter ], SEEK_SET) == -1) { printf( "2nd LSeek Failed"); return NULL; } if (read(fdFile, argStr, 512) == -1) { printf( "Read Of AS File Failed"); return NULL; } strcat( cmdArgs, argStr ); strcat( cmdArgs, " " ); } close(fdFile); } } else { return NULL; } return Py_BuildValue( "s", cmdArgs ); } static struct PyMethodDef PSInfoMethods[]={ { "pidinfo", psinfo_pidinfo, METH_VARARGS, "Display Details For A Given PID" }, { "fullpidinfo", psinfo_fullpidinfo, METH_VARARGS, "Display Full Arg Details For A Given PID" }, { NULL, NULL, 0, NULL } }; void initpsinfo(void) { (void)Py_InitModule("psinfo", PSInfoMethods); } From kbk@shore.net Tue Jul 22 22:54:41 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Tue, 22 Jul 2003 17:54:41 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1DB0AD.90407@ocf.berkeley.edu> ("Brett C."'s message of "Tue, 22 Jul 2003 14:46:21 -0700") References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> <3F1DB0AD.90407@ocf.berkeley.edu> Message-ID: "Brett C." writes: > Did you run autoreconf? That is an important step since it > regenerates configure from the patch file. No, I just deleted config.status. Hang on, I'll try again. -- KBK From tim.one@comcast.net Tue Jul 22 23:00:35 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 18:00:35 -0400 Subject: [Python-Dev] Test_coercion failing on Panther for complex numbers In-Reply-To: <6E0614E7-BC8E-11D7-A6B7-000A27B19B96@cwi.nl> Message-ID: [Jack Jansen] > Ah... Long ago in a universe far from here... I remember, I had the > same problem on MacOS9 at some point. And I believed it was a design error in the FPU's fused multiply-add implementation. > But the strange thing with the current incarnation of the problem is > that the exact same binary (build on OSX 10.2) passes test_coercion on > 10.2 but fails it on 10.3. Could the C library be involved? Absolutely. This is how a string gets created from a complex: PyOS_snprintf(buf, bufsz, "(%.*g%+.*gj)", precision, v->cval.real, precision, v->cval.imag); IOW, the C library produces the "+" or "-" here, and C libraries are utterly inconsistent about whether they print -0.0 with a "+" or a "-" sign. I believe it's an FPU bug that -0.0 occurs in this test, but there are too many accidents to be worth the pain of fighting here, and the test should be rewritten not to produce these ambiguous (in practice although not in theory) cases to begin with (but after 2.3). From blunck@gst.com Tue Jul 22 23:16:30 2003 From: blunck@gst.com (Christopher Blunck) Date: Tue, 22 Jul 2003 18:16:30 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <20030722200424.GF10306@epoch.metaslash.com> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> Message-ID: <20030722221630.GA7422@homer.gst.com> On Tue, Jul 22, 2003 at 04:04:24PM -0400, Neal Norwitz wrote: > On Tue, Jul 22, 2003 at 03:45:20PM -0400, Guido van Rossum wrote: > > [Skip] > > > > The thought occurred to me the other day that we ought to have a > > > > table on the website (probably on the Wiki) where people can list > > > > the kind of systems they have ready access to if they are willing > > > > to help with some tests. It would make it easier to locate people > > > > who can "configure ; make ; make test" on more obscure platforms. > > > > Hm, what happened to the snake-farm at Lysator? Aren't they supposed > > to do exactly this? Is Neal around? I think he's our official rep there. > > Here. I was thinking Skip's idea would be bad since I'll be listed > for a bunch of platforms. :-) > > RedHat 6.2 isn't in the snake farm. Right now, things are in pretty > good shape on the snake farm builds (I watch them on a regular basis). > > Unfortunately, some of the problems deal with minor OS variations > (like a specific patching being applied or not), so even having the > "same" version of th OS isn't always enough. > > I have access to the following systems: > RedHat: 8, 9 > Solaris: 8 > AIX: 4.2.1.0, 4.3.1.0, 4.3.3.0 > HPUX: 11.00 A > IRIX: 6.5 > DecUNIX, OSF/1, Tru64: 5.0, 5.1 Neal- I have an old SGI Indigo box that's running an ancient version of IRIX (I know it is 5.x, but it *may* be 4.x). Would you like to have it to look over? ;-) Jokingly (I think it only has a 800Mb disk!), -c -- 18:10:00 up 67 days, 7:45, 8 users, load average: 0.18, 0.24, 0.20 From kbk@shore.net Tue Jul 22 23:18:56 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Tue, 22 Jul 2003 18:18:56 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1DB0AD.90407@ocf.berkeley.edu> ("Brett C."'s message of "Tue, 22 Jul 2003 14:46:21 -0700") References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> <3F1DB0AD.90407@ocf.berkeley.edu> Message-ID: "Brett C." writes: > Did you run autoreconf? That is an important step since it > regenerates configure from the patch file. ==================== autoreconf ./configure make make install ==================== [kbk@float ~/PYSRC]$ lsl config* -rw-r--r-- 1 kbk users 105368 Jul 22 17:55 config.log -rwxr-xr-x 1 kbk users 52705 Jul 22 17:55 config.status* -rw-r--r-- 1 kbk users 13585 Jul 22 17:12 config22Jul03.log -rw-r--r-- 1 kbk users 13546 Jul 22 17:55 config22Jul03b.log -rwxr-xr-x 1 kbk users 502876 Jul 22 17:52 configure* -rw-r--r-- 1 kbk users 82844 Jul 22 17:07 configure.in [kbk@float ~/PYSRC]$ python2.3 -c "from test import test_time; > test_time.test_main()" test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... FAIL ====================================================================== FAIL: test_tzset (test.test_time.TimeTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- Ran 8 tests in 2.094s FAILED (failures=1) Traceback (most recent call last): File "", line 2, in ? File "/usr/local/lib/python2.3/test/test_time.py", line 125, in test_main test_support.run_unittest(TimeTestCase) File "/usr/local/lib/python2.3/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/usr/local/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST [kbk@float ~/PYSRC]$ lsl `which python2.3` -rwxr-xr-x 2 root root 2506493 Jul 22 18:03 /usr/local/bin/ python2.3* [kbk@float ~/PYSRC]$ lsl /usr/local/lib/python2.3/test/test_time.p* -rw-r--r-- 1 root root 4651 Jul 22 18:03 /usr/local/lib/pyth on2.3/test/test_time.py -rw-r--r-- 1 root root 5216 Jul 22 18:05 /usr/local/lib/python2 .3/test/test_time.pyc -rw-r--r-- 1 root root 5216 Jul 22 18:06 /usr/local/lib/python2 .3/test/test_time.pyo -- KBK From jordan@krushen.com Tue Jul 22 23:35:30 2003 From: jordan@krushen.com (Jordan Krushen) Date: Tue, 22 Jul 2003 15:35:30 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <1058902307.13235.90.camel@yyz> Message-ID: On Tue, 22 Jul 2003 13:50:39 -0700, Jordan Krushen wrote: > On a freshly-installed RedHat 6.2 VMware box (./configure, make, make > test) : > > 1 test failed: > test_time After patching with tzset4.diff and running autoreconf (after installing autoconf 2.57): 1 test failed: test_time After patching with tzset_AEST.diff and running autoreconf: 1 test failed: test_time No luck. J. From drifty@alum.berkeley.edu Tue Jul 22 23:40:53 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 15:40:53 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> <3F1DB0AD.90407@ocf.berkeley.edu> Message-ID: <3F1DBD75.9060504@ocf.berkeley.edu> Kurt B. Kaiser wrote: > "Brett C." writes: > > >>Did you run autoreconf? That is an important step since it >>regenerates configure from the patch file. > > > > ==================== > autoreconf > ./configure > make > make install > > ==================== > > [kbk@float ~/PYSRC]$ lsl config* > -rw-r--r-- 1 kbk users 105368 Jul 22 17:55 config.log > -rwxr-xr-x 1 kbk users 52705 Jul 22 17:55 config.status* > -rw-r--r-- 1 kbk users 13585 Jul 22 17:12 config22Jul03.log > -rw-r--r-- 1 kbk users 13546 Jul 22 17:55 config22Jul03b.log > -rwxr-xr-x 1 kbk users 502876 Jul 22 17:52 configure* > -rw-r--r-- 1 kbk users 82844 Jul 22 17:07 configure.in > > > [kbk@float ~/PYSRC]$ python2.3 -c "from test import test_time; > >>test_time.test_main()" > > test_asctime (test.test_time.TimeTestCase) ... ok > test_clock (test.test_time.TimeTestCase) ... ok > test_conversions (test.test_time.TimeTestCase) ... ok > test_data_attributes (test.test_time.TimeTestCase) ... ok > test_sleep (test.test_time.TimeTestCase) ... ok > test_strftime (test.test_time.TimeTestCase) ... ok > test_strptime (test.test_time.TimeTestCase) ... ok > test_tzset (test.test_time.TimeTestCase) ... FAIL > > ====================================================================== > FAIL: test_tzset (test.test_time.TimeTestCase) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset > self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) > File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless > if not expr: raise self.failureException, msg > AssertionError: AEST > > ---------------------------------------------------------------------- > Ran 8 tests in 2.094s > > FAILED (failures=1) > Traceback (most recent call last): > File "", line 2, in ? > File "/usr/local/lib/python2.3/test/test_time.py", line 125, in test_main > test_support.run_unittest(TimeTestCase) > File "/usr/local/lib/python2.3/test/test_support.py", line 262, in run_unittest > run_suite(suite, testclass) > File "/usr/local/lib/python2.3/test/test_support.py", line 247, in run_suite > raise TestFailed(err) > test.test_support.TestFailed: Traceback (most recent call last): > File "/usr/local/lib/python2.3/test/test_time.py", line 107, in test_tzset > self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) > File "/usr/local/lib/python2.3/unittest.py", line 268, in failUnless > if not expr: raise self.failureException, msg > AssertionError: AEST > > [kbk@float ~/PYSRC]$ lsl `which python2.3` > -rwxr-xr-x 2 root root 2506493 Jul 22 18:03 /usr/local/bin/ > python2.3* > > > [kbk@float ~/PYSRC]$ lsl /usr/local/lib/python2.3/test/test_time.p* > -rw-r--r-- 1 root root 4651 Jul 22 18:03 /usr/local/lib/pyth > on2.3/test/test_time.py > -rw-r--r-- 1 root root 5216 Jul 22 18:05 /usr/local/lib/python2 > .3/test/test_time.pyc > -rw-r--r-- 1 root root 5216 Jul 22 18:06 /usr/local/lib/python2 > .3/test/test_time.pyo > Nuts. Well, then I am stumped on how to fix this tzset problem. The damn autoconf code should have failed and thus time.tzset should not have been compiled. Any suggestions? -Brett From neal@metaslash.com Tue Jul 22 23:42:47 2003 From: neal@metaslash.com (Neal Norwitz) Date: Tue, 22 Jul 2003 18:42:47 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <20030722213429.GI10306@epoch.metaslash.com> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> <20030722213429.GI10306@epoch.metaslash.com> Message-ID: <20030722224247.GJ10306@epoch.metaslash.com> The patch below fixes test_time on RedHat 6.2/Alpha. Since I don't understand the code, I haven't the slighest clue if the patch is correct or not. But I do know what (365 * 24 * 3600) is. :-) I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. 1 year + 6 hours in seconds. What's that? I've copied Stuart Bishop on this message as I believe he wrote all this code. The patches in http://python.org/sf/762934 haven't made the tests pass. I'm not real comfortable including this in 2.3. Although the worst that should happen is that it gives incorrect results (which may very well be happening now). If this does get checked in while I'm away, you can verify the test succeeds by going to this page: http://www.lysator.liu.se/xenofarm/python/latest.html The RedHat 6.2/Alpha host is asmodean. Click the red dot in the asmodean row and python test column. Verify that test_time no longer fails. Neal -- Index: Modules/timemodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/timemodule.c,v retrieving revision 2.138 diff -w -u -r2.138 timemodule.c --- Modules/timemodule.c 1 Jul 2003 05:16:08 -0000 2.138 +++ Modules/timemodule.c 22 Jul 2003 22:36:35 -0000 @@ -600,7 +600,7 @@ #else /* !HAVE_TZNAME || __GLIBC__ || __CYGWIN__*/ #ifdef HAVE_STRUCT_TM_TM_ZONE { -#define YEAR ((time_t)((365 * 24 + 6) * 3600)) +#define YEAR ((time_t)(365 * 24 * 3600)) time_t t; struct tm *p; long janzone, julyzone; From drifty@alum.berkeley.edu Tue Jul 22 23:52:54 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 15:52:54 -0700 Subject: [Python-Dev] test_strptime; test_logging; test_time failure (was: cygwin errors) In-Reply-To: References: Message-ID: <3F1DC046.1020706@ocf.berkeley.edu> Tim Peters wrote: > [Brett C.] > >>OK. This is where running: >> >> >>> import time >> >>> time.strftime("%c") >> >>> import _strptime >> >>> _strptime.TimeRE()['c'] >> >>can help me try to diagnose this (I can't reproduce this under OS X). >>This will give me what strftime is spitting out and what regex >>strptime would be using to match against it. > > > After reverting Jeremy's hack to test_logging, and hacking regrtest.py to > stop doing sys.exit(): > > C:\Code\python\PCbuild>python -i ../lib/test/regrtest.py test_strptime > test_logging > test_time > test_strptime > test_logging > test_time > test test_time failed -- Traceback (most recent call last): > File "C:\Code\python\lib\test\test_time.py", line 49, in test_strptime > self.fail('conversion specifier: %r failed.' % format) > File "C:\Code\python\lib\unittest.py", line 260, in fail > raise self.failureException, msg > AssertionError: conversion specifier: ' %c' failed. > > 2 tests OK. > 1 test failed: > test_time > >>>>import time >>>>time.strftime("%c") > > '07/22/2003 05:44:01 PM' > >>>>import _strptime >>>>_strptime.TimeRE()['c'] > > '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| > [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) > :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' > > > Now the same thing with Jeremy's test_logging hack restored: > > C:\Code\python\PCbuild>python -i ../lib/test/regrtest.py test_strptime > test_logging > test_time > test_strptime > test_logging > test_time > All 3 tests OK. > >>>>import time >>>>time.strftime("%c") > > '07/22/03 17:47:26' > >>>>import _strptime >>>>_strptime.TimeRE()['c'] > > '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| > [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) > :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' > > > The regexp appears to be the same, but strftime's result has switched from > (apparently) 12-hour + AM/PM time to 24-hour time. > OK, the only thing I can think of is that the locale info has changed ever so subtly and the checking of locale.getlocale(locale.LC_TIME)[0] or locale.getdefaultlocale()[0] is not cutting it. Next thing to try is to see what values locale.getlocale(locale.LC_TIME) and locale.getdefaultlocale() have (notice I am asking for the full value and not just the 0 item) after each test is run. It is possible the cache in _strptime is not being cleared because it is not picking up the change in locale by only checking the 0 item. If there is not some obvious difference in values then the cache will have to be deleted and strptime performance will drop but the problem will go away. -Brett From drifty@alum.berkeley.edu Tue Jul 22 23:57:14 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 15:57:14 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <1058902307.13235.90.camel@yyz> Message-ID: <3F1DC14A.7040304@ocf.berkeley.edu> Jordan Krushen wrote: > On Tue, 22 Jul 2003 13:50:39 -0700, Jordan Krushen > wrote: > >> On a freshly-installed RedHat 6.2 VMware box (./configure, make, make >> test) : >> >> 1 test failed: >> test_time > > > > After patching with tzset4.diff and running autoreconf (after installing > autoconf 2.57): > > 1 test failed: > test_time > > > After patching with tzset_AEST.diff and running autoreconf: > > 1 test failed: > test_time > > > No luck. > Thanks for the help, Jordan. Looks like the patch doesn't do the trick. -Brett From drifty@alum.berkeley.edu Wed Jul 23 00:20:22 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 16:20:22 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <20030722224247.GJ10306@epoch.metaslash.com> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> <20030722213429.GI10306@epoch.metaslash.com> <20030722224247.GJ10306@epoch.metaslash.com> Message-ID: <3F1DC6B6.6030803@ocf.berkeley.edu> Neal Norwitz wrote: > The patch below fixes test_time on RedHat 6.2/Alpha. Since I don't > understand the code, I haven't the slighest clue if the patch is > correct or not. But I do know what (365 * 24 * 3600) is. :-) > I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. > 1 year + 6 hours in seconds. What's that? > And why does ``t = (time((time_t *)0) / YEAR) * YEAR;`` on line 608 have to divide by YEAR and then multiply by YEAR? Shouldn't those cancel out? The idea seeems reasonable if you stare at the code since the division might be causing the time_t to wrap around the year when it divides by 2 and thus get the wrong part of the year. But as Neal said I would defer to Stuart for saying whether this is a good fix or not. -Brett From tim.one@comcast.net Wed Jul 23 00:20:11 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 19:20:11 -0400 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure (was: cygwin errors) In-Reply-To: <3F1DC046.1020706@ocf.berkeley.edu> Message-ID: Note that I'm on Win98SE now (previous email today was on Win2K). Under current CVS, but with regrtest hacked not to do sys.exit(): C:\Code\python\PCbuild>python -i ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test_logging test_time All 3 tests OK. >>> import forbrett time.strftime("%c") '07/22/03 19:11:50' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) (None, None) >>> Again, but reverting Jeremy's test_logging locale fiddling: C:\Code\python\PCbuild>python -i ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test_logging test_time test test_time failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. 2 tests OK. 1 test failed: test_time >>> import forbrett time.strftime("%c") '07/22/2003 07:14:31 PM' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) ['English_United States', '1252'] >>> This is forbrett.py: """ def dump(tag, value): import pprint print tag pprint.pprint(value) print import time dump('time.strftime("%c")', time.strftime("%c")) import _strptime dump("_strptime.TimeRE()['c']", _strptime.TimeRE()['c']) import locale dump("locale.getdefaultlocale()", locale.getdefaultlocale()) dump("locale.getlocale(locale.LC_TIME)", locale.getlocale(locale.LC_TIME)) """ [Brett C.] > OK, the only thing I can think of is that the locale info has changed > ever so subtly and the checking of locale.getlocale(locale.LC_TIME)[0] > or locale.getdefaultlocale()[0] is not cutting it. Next thing to try > is to see what values locale.getlocale(locale.LC_TIME) and > locale.getdefaultlocale() have (notice I am asking for the full value > and not just the 0 item) after each test is run. It is possible the > cache in _strptime is not being cleared because it is not picking up > the change in locale by only checking the 0 item. > > If there is not some obvious difference in values then the cache will > have to be deleted and strptime performance will drop but the problem > will go away. Barry agrees . From guido@python.org Wed Jul 23 00:24:25 2003 From: guido@python.org (Guido van Rossum) Date: Tue, 22 Jul 2003 19:24:25 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: Your message of "Tue, 22 Jul 2003 16:20:22 PDT." <3F1DC6B6.6030803@ocf.berkeley.edu> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> <20030722213429.GI10306@epoch.metaslash.com> <20030722224247.GJ10306@epoch.metaslash.com> <3F1DC6B6.6030803@ocf.berkeley.edu> Message-ID: <200307222324.h6MNOPv15652@pcp02138704pcs.reston01.va.comcast.net> > And why does ``t = (time((time_t *)0) / YEAR) * YEAR;`` on line 608 have > to divide by YEAR and then multiply by YEAR? Shouldn't those cancel out? I guess it should have used // instead of /. (X//Y)*Y is a standard way to round X down to a whole multiple of Y, and I presume that's what the code here does. --Guido van Rossum (home page: http://www.python.org/~guido/) From drifty@alum.berkeley.edu Wed Jul 23 00:33:54 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 16:33:54 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <200307222324.h6MNOPv15652@pcp02138704pcs.reston01.va.comcast.net> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> <20030722213429.GI10306@epoch.metaslash.com> <20030722224247.GJ10306@epoch.metaslash.com> <3F1DC6B6.6030803@ocf.berkeley.edu> <200307222324.h6MNOPv15652@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <3F1DC9E2.50405@ocf.berkeley.edu> Guido van Rossum wrote: >>And why does ``t = (time((time_t *)0) / YEAR) * YEAR;`` on line 608 have >>to divide by YEAR and then multiply by YEAR? Shouldn't those cancel out? > > > I guess it should have used // instead of /. (X//Y)*Y is a standard > way to round X down to a whole multiple of Y, and I presume that's > what the code here does. > Didn't know C had a flooring divide operator. Good to know. -Brett From tim.one@comcast.net Wed Jul 23 00:38:38 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 19:38:38 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1DC9E2.50405@ocf.berkeley.edu> Message-ID: [Brett] >>> And why does ``t = (time((time_t *)0) / YEAR) * YEAR;`` on line 608 >>> have to divide by YEAR and then multiply by YEAR? Shouldn't those >>> cancel out? [Guido] >> I guess it should have used // instead of /. (X//Y)*Y is a standard >> way to round X down to a whole multiple of Y, and I presume that's >> what the code here does. [Brett] > Didn't know C had a flooring divide operator. Good to know. It doesn't. If Guido were still my boss, I'd say he was pulling your leg. But since he left us, I'll just diplomatically say he's an idiot . If dividend and divisor are both positive and integer, C's / is flooring division. From drifty@alum.berkeley.edu Wed Jul 23 00:40:35 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 16:40:35 -0700 Subject: [Python-Dev] Re: test_strptime; test_logging; test_time failure (was: cygwin errors) In-Reply-To: References: Message-ID: <3F1DCB73.10601@ocf.berkeley.edu> Tim Peters wrote: > Note that I'm on Win98SE now (previous email today was on Win2K). > > Under current CVS, but with regrtest hacked not to do sys.exit(): > > C:\Code\python\PCbuild>python -i ../lib/test/regrtest.py test_strptime > test_logging > test_time > test_strptime > test_logging > test_time > All 3 tests OK. > >>>>import forbrett > > time.strftime("%c") > '07/22/03 19:11:50' > > _strptime.TimeRE()['c'] > '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| > [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) > :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' > > locale.getdefaultlocale() > ('en_US', 'cp1252') > > locale.getlocale(locale.LC_TIME) > (None, None) > > > > Again, but reverting Jeremy's test_logging locale fiddling: > > C:\Code\python\PCbuild>python -i ../lib/test/regrtest.py test_strptime > test_logging > test_time > test_strptime > test_logging > test_time > test test_time failed -- Traceback (most recent call last): > File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime > self.fail('conversion specifier: %r failed.' % format) > File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail > raise self.failureException, msg > AssertionError: conversion specifier: ' %c' failed. > > 2 tests OK. > 1 test failed: > test_time > >>>>import forbrett > > time.strftime("%c") > '07/22/2003 07:14:31 PM' > > _strptime.TimeRE()['c'] > '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| > [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) > :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' > > locale.getdefaultlocale() > ('en_US', 'cp1252') > > locale.getlocale(locale.LC_TIME) > ['English_United States', '1252'] > > > > > This is forbrett.py: > > """ > def dump(tag, value): > import pprint > print tag > pprint.pprint(value) > print > > import time > dump('time.strftime("%c")', > time.strftime("%c")) > > import _strptime > dump("_strptime.TimeRE()['c']", > _strptime.TimeRE()['c']) > > > import locale > dump("locale.getdefaultlocale()", > locale.getdefaultlocale()) > > dump("locale.getlocale(locale.LC_TIME)", > locale.getlocale(locale.LC_TIME)) > """ > > [Brett C.] > >>OK, the only thing I can think of is that the locale info has changed >>ever so subtly and the checking of locale.getlocale(locale.LC_TIME)[0] >>or locale.getdefaultlocale()[0] is not cutting it. Next thing to try >>is to see what values locale.getlocale(locale.LC_TIME) and >>locale.getdefaultlocale() have (notice I am asking for the full value >>and not just the 0 item) after each test is run. It is possible the >>cache in _strptime is not being cleared because it is not picking up >>the change in locale by only checking the 0 item. >> I should have been more explicit; I meant after *every* individual test and not after the battery of tests. Either way we can do a quick check, Tim, if you can try out this patch:: Index: Lib/_strptime.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/_strptime.py,v retrieving revision 1.21 diff -u -r1.21 _strptime.py --- Lib/_strptime.py 13 Jul 2003 01:31:38 -0000 1.21 +++ Lib/_strptime.py 22 Jul 2003 23:37:03 -0000 @@ -27,11 +27,11 @@ def _getlang(): # Figure out what the current language is set to. - current_lang = locale.getlocale(locale.LC_TIME)[0] + current_lang = locale.getlocale(locale.LC_TIME) if current_lang: return current_lang else: - current_lang = locale.getdefaultlocale()[0] + current_lang = locale.getdefaultlocale() if current_lang: return current_lang else: We can see if that fixes it. Obviously ignore the test_strptime failures that will pop up because of this. If this does not fix it, then bye-bye caching. >>If there is not some obvious difference in values then the cache will >>have to be deleted and strptime performance will drop but the problem >>will go away. > > > Barry agrees . Oh good. Last thing I would want is Benevolent Dictator For A Release to disagree with me; must be because we are both American and not Dutch. =) -Brett From drifty@alum.berkeley.edu Wed Jul 23 00:43:08 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 22 Jul 2003 16:43:08 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: References: Message-ID: <3F1DCC0C.4070205@ocf.berkeley.edu> Tim Peters wrote: > [Brett] > >>>>And why does ``t = (time((time_t *)0) / YEAR) * YEAR;`` on line 608 >>>>have to divide by YEAR and then multiply by YEAR? Shouldn't those >>>>cancel out? > > > [Guido] > >>>I guess it should have used // instead of /. (X//Y)*Y is a standard >>>way to round X down to a whole multiple of Y, and I presume that's >>>what the code here does. > > > [Brett] > >>Didn't know C had a flooring divide operator. Good to know. > > > It doesn't. If Guido were still my boss, I'd say he was pulling your leg. > But since he left us, I'll just diplomatically say he's an idiot . > =) But he is still your BDFL so be careful how to tread, Tim. =) > If dividend and divisor are both positive and integer, C's / is flooring > division. > That's what I figured. Although isn't that assuming time_t is an int or long or something? But the entire chunk of code seems to assuming that so what is one more spot of code. =) -brett From tim.one@comcast.net Wed Jul 23 01:20:57 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 20:20:57 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1DCC0C.4070205@ocf.berkeley.edu> Message-ID: >> If dividend and divisor are both positive and integer, C's / is >> flooring division. [Brett C.] > That's what I figured. Although isn't that assuming time_t is an int > or long or something? The grownup phrase is "integral type" . You're right that it's a dubious assumption: all C requires of time_t is that it resolves to an arithmetic type. "Arithmetic type" is the union of the integral, real, and (in C99) complex types. With FPUs much faster than they used to be, and 32-bit ints running out of room to store seconds since 1970: >>> import datetime as d >>> print d.datetime(1970, 1, 1) + d.timedelta(seconds=2**31-1) 2038-01-19 03:14:07 >>> I wouldn't be surprised to see some systems switching to doubles for time_t. Probably not this decade, although the JavaScript (ECMAScript) time type was deliberately designed to work beautifully when stored in an IEEE-754 double, and has much greater range and precision than the typical POSIX time type. > But the entire chunk of code seems to assuming that so what is one > more spot of code. =) I'll be dead by 2038 -- this is my generation's way of giving employment security to yours . From tim.one@comcast.net Wed Jul 23 01:45:00 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 20:45:00 -0400 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure (was: cygwin errors) In-Reply-To: <3F1DCB73.10601@ocf.berkeley.edu> Message-ID: [Brett C.] > Either way we can do a quick check, Tim, if you can try out this > patch:: > > Index: Lib/_strptime.py > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Lib/_strptime.py,v > retrieving revision 1.21 > diff -u -r1.21 _strptime.py > --- Lib/_strptime.py 13 Jul 2003 01:31:38 -0000 1.21 > +++ Lib/_strptime.py 22 Jul 2003 23:37:03 -0000 > @@ -27,11 +27,11 @@ > > def _getlang(): > # Figure out what the current language is set to. > - current_lang = locale.getlocale(locale.LC_TIME)[0] > + current_lang = locale.getlocale(locale.LC_TIME) > if current_lang: > return current_lang > else: > - current_lang = locale.getdefaultlocale()[0] > + current_lang = locale.getdefaultlocale() > if current_lang: > return current_lang > else: Sorry, it didn't help: C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test test_strptime failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_strptime.py", line 96, in test_lang "Setting of lang failed") File "C:\CODE\PYTHON\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: Setting of lang failed test_logging test_time test test_time failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. 1 test OK. 2 tests failed: test_strptime test_time C:\Code\python\PCbuild> > I should have been more explicit; I meant after *every* individual > test and not after the battery of tests. OK, and back to an unpatched _strptime.py. With the current CVS locale-restoration code (which differs from what it was half an hour ago, but should have the same effect): C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime test_logging test_time time.strftime("%c") '07/22/03 20:38:57' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) (None, None) test_strptime time.strftime("%c") '07/22/03 20:38:58' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) (None, None) test_logging time.strftime("%c") '07/22/03 20:38:59' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) (None, None) test_time time.strftime("%c") '07/22/03 20:39:01' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) (None, None) All 3 tests OK. Again, without restoring locale in test_logging: C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime test_logging test_time time.strftime("%c") '07/22/03 20:39:09' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) (None, None) test_strptime time.strftime("%c") '07/22/03 20:39:10' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) (None, None) test_logging time.strftime("%c") '07/22/2003 08:39:11 PM' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) ['English_United States', '1252'] test_time test test_time failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. time.strftime("%c") '07/22/2003 08:39:13 PM' _strptime.TimeRE()['c'] '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' locale.getdefaultlocale() ('en_US', 'cp1252') locale.getlocale(locale.LC_TIME) ['English_United States', '1252'] 2 tests OK. 1 test failed: test_time C:\Code\python\PCbuild> From dave@psax.org Wed Jul 23 01:51:01 2003 From: dave@psax.org (Dave Barry) Date: Tue, 22 Jul 2003 17:51:01 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <20030722224247.GJ10306@epoch.metaslash.com> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> <20030722213429.GI10306@epoch.metaslash.com> <20030722224247.GJ10306@epoch.metaslash.com> Message-ID: <20030723005101.GA28999@mikamyla.com> Quothe Neal Norwitz , on Tue, Jul 22, 2003: > I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. > 1 year + 6 hours in seconds. What's that? I know nothing about this code, but it would make sense to assume that the extra + 6 hours was intended to account for leap years, 6 * 4 == 24 hours, or 1 extra day every 4 years. Dave -- 454e4420434f4d4d554e49434154494f4e SCO From gward@python.net Wed Jul 23 03:04:31 2003 From: gward@python.net (Greg Ward) Date: Tue, 22 Jul 2003 22:04:31 -0400 Subject: [Python-Dev] optparse 1.4.2 in 2.3: any chance? Message-ID: <20030723020431.GA2139@cthulhu.gerg.ca> I'm so out of the loop I didn't even know 2.3c1 was out until I checked www.python.org/2.3 tonight. ;-( Unfortunately, I was really really hoping to get Optik up to version 1.4.2 in time for Python 2.3. The only changes over 1.4.1 are various small refactorings to make Optik/optparse more easily extensible. This should have no effect on people merely using optparse, and anyone extending it (ie. subclassing Option and/or OptionParser) will win -- unless they're extending it by doing evil things like replacing another module's globals. Given that I won't have a minute to work on this stuff until next Monday (July 28) at the earliest, do I have any hope of getting it into 2.3final? Or should I just face reality and make optparse 1.4.2 the first checkin on the 2.3-maint branch? Greg -- Greg Ward http://www.gerg.ca/ Quick!! Act as if nothing has happened! From barry@python.org Wed Jul 23 03:59:46 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 22:59:46 -0400 Subject: [Python-Dev] Re: test_strptime; test_logging; test_time failure (was: cygwin errors) In-Reply-To: <3F1DCB73.10601@ocf.berkeley.edu> References: <3F1DCB73.10601@ocf.berkeley.edu> Message-ID: <1058929186.20090.8.camel@geddy> On Tue, 2003-07-22 at 19:40, Brett C. wrote: > > Barry agrees . > > Oh good. Last thing I would want is Benevolent Dictator For A Release > to disagree with me; must be because we are both American and not Dutch. =) So's Tim. It's a conspiracy . who-am-i-to-disagree-with-the-guy-i-keep-from-starving-to-death-every-day-ly y'rs, -Barry From tim.one@comcast.net Wed Jul 23 04:22:08 2003 From: tim.one@comcast.net (Tim Peters) Date: Tue, 22 Jul 2003 23:22:08 -0400 Subject: [Python-Dev] optparse 1.4.2 in 2.3: any chance? In-Reply-To: <20030723020431.GA2139@cthulhu.gerg.ca> Message-ID: [Greg Ward] > I'm so out of the loop I didn't even know 2.3c1 was out until I > checked www.python.org/2.3 tonight. ;-( Unfortunately, I was really > really hoping to get Optik up to version 1.4.2 in time for Python > 2.3. The only changes over 1.4.1 are various small refactorings to > make Optik/optparse more easily extensible. This should have no > effect on people merely using optparse, and anyone extending it (ie. > subclassing Option and/or OptionParser) will win -- unless they're > extending it by doing evil things like replacing another module's > globals. > > Given that I won't have a minute to work on this stuff until next > Monday (July 28) at the earliest, do I have any hope of getting it > into 2.3final? If that's so, I'm afraid not. We're trying like hell to get 2.3 final out before August 1, to meet an Apple deadline (we're pretending their schedule won't slip either, of course). 2.3c2 will be released this Thursday night, and 2.3 final no later than the Thursday after, so 2.3c2 is the last chance to put in anything that isn't a show-stopping critical bugfix. 2.3c2 will be old news by Monday. From barry@python.org Wed Jul 23 04:41:30 2003 From: barry@python.org (Barry Warsaw) Date: 22 Jul 2003 23:41:30 -0400 Subject: [Python-Dev] optparse 1.4.2 in 2.3: any chance? In-Reply-To: <20030723020431.GA2139@cthulhu.gerg.ca> References: <20030723020431.GA2139@cthulhu.gerg.ca> Message-ID: <1058931690.20090.28.camel@geddy> On Tue, 2003-07-22 at 22:04, Greg Ward wrote: > Given that I won't have a minute to work on this stuff until next Monday > (July 28) at the earliest, do I have any hope of getting it into > 2.3final? Sorry Greg, I think there's no hope. 7/31 is a drop dead date and we want to hedge our bets in case SF bellies up that day by trying to get 2.3 final out a day or two ahead of that. I want the tree antarctic frozen on 7/24 with only absolutely most critical patches until 2.3 final. -Barry From python@rcn.com Wed Jul 23 05:45:50 2003 From: python@rcn.com (Raymond Hettinger) Date: Wed, 23 Jul 2003 00:45:50 -0400 Subject: [Python-Dev] Vacation and possibly a new bug References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> <20030722213429.GI10306@epoch.metaslash.com> <20030722224247.GJ10306@epoch.metaslash.com> <20030723005101.GA28999@mikamyla.com> Message-ID: <000001c350d6$d7674a80$125ffea9@oemcomputer> [Brett] Didn't know C had a flooring divide operator. Good to know. . . . [Neal Norwitz] > > I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. > > 1 year + 6 hours in seconds. What's that? [Dave Barry] > I know nothing about this code, but it would make sense to assume that > the extra + 6 hours was intended to account for leap years, 6 * 4 == 24 > hours, or 1 extra day every 4 years. I wasn't worried before this conversation began, but now ... Raymond Hettinger From kbk@shore.net Wed Jul 23 06:00:52 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Wed, 23 Jul 2003 01:00:52 -0400 Subject: [Python-Dev] Serious CallTip Bug in IDLE Message-ID: Python Bug 775541 Introduced by Python Patch 769142 as applied. I believe this needs to be fixed for rc2. See Python Patch 776062: http://sourceforge.net/tracker/index.php?func=detail&aid=776062&group_id=5470&atid=305470 -- KBK From zen@shangri-la.dropbear.id.au Wed Jul 23 06:11:51 2003 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Wed, 23 Jul 2003 15:11:51 +1000 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <20030722224247.GJ10306@epoch.metaslash.com> Message-ID: <2B29460B-BCCC-11D7-AF09-000A95A06FC6@shangri-la.dropbear.id.au> On Wednesday, July 23, 2003, at 08:42 AM, Neal Norwitz wrote: > > The patch below fixes test_time on RedHat 6.2/Alpha. Since I don't > understand the code, I haven't the slighest clue if the patch is > correct or not. But I do know what (365 * 24 * 3600) is. :-) > I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. > 1 year + 6 hours in seconds. What's that? > > I've copied Stuart Bishop on this message as I believe he wrote > all this code. The patches in http://python.org/sf/762934 haven't > made the tests pass. I'm following this thread (from an out of sync timezone). I didn't change much in timemodule.c - I just shuffled some things around a bit and added the tzset function (see the comment at the start of inittimezone()). I don't know why YEAR is defined as 365 days + 6 hours either. I think it is there to account for leap years as others have mentioned. It would be interesting to see what happens if a Redhat6.2 user runs test_time.py with 'xmas2002 =3D 1040774400.0' changed to 'xmas2002 =3D 914508000.0' in case it is a Y2K bug we only just=20 noticed :-) I can't see why removing the '+6' would make any difference at all, unless your OS doesn't understand leap years and your DST changeovers are =B18 days of 1st Jan or 1 Jul (which is not the case for the = AEST/AEDT timezone being tested). I think the existing algorithm is broken, as it assumes that midnight Jan 1st UTC is always non-DST, and 'around July 1st UTC' always DST in the northern hemisphere (reversing this in the southern hemisphere). I'm sure there is at least one country where this isn't true :-) bcannon's tzset_AEST.diff patch can be improved (it doesn't check if the system believes the whole year is entirely in DST). It also needs to do the following: time_t midyear =3D xmas - (365 * 24 * 3600 / 2); if (strcmp(localtime(&midyear)->tm_zone, "AEST")) exit(1); I'll make a patch when anon-cvs gets back up, unless someone beats me to it. > I'm not real comfortable including this in 2.3. Although the > worst that should happen is that it gives incorrect results > (which may very well be happening now). --=20 Stuart Bishop http://shangri-la.dropbear.id.au/ From kbk@shore.net Wed Jul 23 07:12:18 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Wed, 23 Jul 2003 02:12:18 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <2B29460B-BCCC-11D7-AF09-000A95A06FC6@shangri-la.dropbear.id.au> (Stuart Bishop's message of "Wed, 23 Jul 2003 15:11:51 +1000") References: <2B29460B-BCCC-11D7-AF09-000A95A06FC6@shangri-la.dropbear.id.au> Message-ID: Stuart Bishop writes: > It would be interesting to see what happens if a Redhat6.2 user > runs test_time.py with 'xmas2002 = 1040774400.0' changed > to 'xmas2002 = 914508000.0' in case it is a Y2K bug we only just > noticed :-) Tried it on 6.2. No joy, same error. -- KBK From theller@python.net Wed Jul 23 07:41:26 2003 From: theller@python.net (Thomas Heller) Date: Wed, 23 Jul 2003 08:41:26 +0200 Subject: [Python-Dev] improved zipimport In-Reply-To: <4r1enww2.fsf@python.net> (Thomas Heller's message of "Tue, 22 Jul 2003 22:12:45 +0200") References: <1058886052.13235.19.camel@yyz> <1058888748.13235.42.camel@yyz> <4r1enww2.fsf@python.net> Message-ID: Thomas Heller writes: > martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes: > >> Thomas Heller writes: >> >>> It would be best if someone else who really uses zipimports would be >>> able to test it - I really don't want to break anything. >> >> Then 2.3 should go unchanged. If there is a way to construct proper >> zipfiles for zipimports, this should be sufficient. Any support for >> additional "kinds" of zipfiles should count as a new feature. > > It's already checked in. Should it be backed out again? Can the powers please decide? Thanks, Thomas From mwh@python.net Wed Jul 23 09:08:28 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 23 Jul 2003 09:08:28 +0100 Subject: [Python-Dev] Test_coercion failing on Panther for complex numbers In-Reply-To: <6E0614E7-BC8E-11D7-A6B7-000A27B19B96@cwi.nl> (Jack Jansen's message of "Tue, 22 Jul 2003 23:49:54 +0200") References: <6E0614E7-BC8E-11D7-A6B7-000A27B19B96@cwi.nl> Message-ID: <2mbrvloebn.fsf@starship.python.net> Jack Jansen writes: > On dinsdag, 22 juli 2003, at 23:28PM, Tim Peters wrote: > >> [Jack Jansen] >>> I need a little guidance with bug #775892. I think it's non-serious, >>> but I'm not sure (and I don't know how easy it is to fix). >>> >>> Test_coercion is failing on the beta for MacOSX 10.3. All the failures >>> have the same form: the output is (XXX-0j) in stead of the expected >>> (XXX+0j). >> >> It isn't serious, and we've (you & I) been thru this failure before >> . >> If the compiler for this box has some sort of switch named along the >> lines >> of "don't used fused multiply-add", it should cure it. > > Ah... Long ago in a universe far from here... I remember, I had the > same problem on MacOS9 at some point. > > But the strange thing with the current incarnation of the problem is > that the exact same binary (build on OSX 10.2) passes test_coercion on > 10.2 but fails it on 10.3. Could the C library be involved? Or the compiler. Is Panther using the same gcc 3.3 as the last dev tools update? Cheers, mwh -- This is not to say C++ = bad, Lisp = good. It's to say C++ = bad irrespective of everything else. -- Alain Picard, comp.lang.lisp From mwh@python.net Wed Jul 23 09:11:35 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 23 Jul 2003 09:11:35 +0100 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1DBD75.9060504@ocf.berkeley.edu> ("Brett C."'s message of "Tue, 22 Jul 2003 15:40:53 -0700") References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> <3F1DB0AD.90407@ocf.berkeley.edu> <3F1DBD75.9060504@ocf.berkeley.edu> Message-ID: <2m8yqpoe6g.fsf@starship.python.net> "Brett C." writes: > Nuts. Well, then I am stumped on how to fix this tzset problem. The > damn autoconf code should have failed and thus time.tzset should not > have been compiled. > > Any suggestions? Not worrying about it too much? Cheers, mwh -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925 From Jack.Jansen@cwi.nl Wed Jul 23 09:21:16 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 23 Jul 2003 10:21:16 +0200 Subject: [Python-Dev] Serious CallTip Bug in IDLE In-Reply-To: Message-ID: On Wednesday, Jul 23, 2003, at 07:00 Europe/Amsterdam, Kurt B. Kaiser wrote: > Python Bug 775541 > > Introduced by Python Patch 769142 as applied. > > I believe this needs to be fixed for rc2. > > See Python Patch 776062: > > http://sourceforge.net/tracker/ > index.php?func=detail&aid=776062&group_id=5470&atid=305470 +1 -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From mwh@python.net Wed Jul 23 12:58:52 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 23 Jul 2003 12:58:52 +0100 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <16156.42473.441618.555308@montanaro.dyndns.org> (Skip Montanaro's message of "Mon, 21 Jul 2003 21:48:09 -0500") References: <16156.27381.925389.777799@montanaro.dyndns.org> <16156.42473.441618.555308@montanaro.dyndns.org> Message-ID: <2mznj5mp37.fsf@starship.python.net> Skip Montanaro writes: [the hoary old bind()-in-a-loop-is-slow-on-OS-X problem] > I think we've concluded that it's okay to ship 2.3 with this problem > unresolved, however I'm completely befuddled at the moment. I wrote this > simple program: I spent a while playing with this last night, to no particular resolution. A few observations: 1) It would be nice to find out what lookupd is up to during the loop. I couldn't find out how to get it to tell me (for one thing, the lookupd(8) manpage seems to be very out of date wrt. locating config info). 2) One obvious difference between the slow Python program and the fast C program is that Python has calls to bind() in between the calls to getaddrinfo()... maybe this (or something else) causes lookupd to toss its cache for some reason? 3) We're not the first to bump into this: http://mailman.mit.edu/pipermail/krb5-bugs/2003-March/000701.html http://mailman.mit.edu/pipermail/krb5-bugs/2003-March/000708.html That bug doesn't seem to resolved beyond "blame Apple" (hmm, familiar :-). I don't think there's much we can do about this, unless there's a NetInfo wizard in the house. Cheers, M. -- The Internet is full. Go away. -- http://www.disobey.com/devilshat/ds011101.htm From barry@python.org Wed Jul 23 13:05:19 2003 From: barry@python.org (Barry Warsaw) Date: 23 Jul 2003 08:05:19 -0400 Subject: [Python-Dev] Serious CallTip Bug in IDLE In-Reply-To: References: Message-ID: <1058961919.29634.1.camel@anthem> On Wed, 2003-07-23 at 01:00, Kurt B. Kaiser wrote: > Python Bug 775541 > > Introduced by Python Patch 769142 as applied. > > I believe this needs to be fixed for rc2. > > See Python Patch 776062: > > http://sourceforge.net/tracker/index.php?func=detail&aid=776062&group_id=5470&atid=305470 Go for it Kurt, and thanks! -Barry From Jack.Jansen@cwi.nl Wed Jul 23 13:19:27 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 23 Jul 2003 14:19:27 +0200 Subject: [Python-Dev] posixpath.ismount() on non-posix systems Message-ID: I've just filed bug #776207: test_posixpath fails on MacOS9. The problem is that it expects posixpath.ismount('/') to return true. But on OS9 it returns false. I'm unsure as to the correct behaviour of this on non-posix systems, does anyone have a suggestion? How does it behave on Windows? Should test_posixpath maybe only run some of the tests on non-posix systems? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From Jack.Jansen@cwi.nl Wed Jul 23 13:25:45 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 23 Jul 2003 14:25:45 +0200 Subject: [Python-Dev] MacPython-OS9 test failures Message-ID: Barry (and others), I added a couple of bug reports for things that fail in MacPython-OS9. My personal feeling is that it's best to leave fixing these until the unix/windows/MacOSX release of Python 2.3 has been done. This has the disadvantage that MacPython-OS9 and the rest of the pythons are built from slightly different source trees, but we've done that in the past and no-one seems to be bothered by it. The alternative would be to fix the problems now, with any destabilizing results that may have. Opinions? -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From mwh@python.net Wed Jul 23 13:36:35 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 23 Jul 2003 13:36:35 +0100 Subject: [Python-Dev] posixpath.ismount() on non-posix systems In-Reply-To: (Jack Jansen's message of "Wed, 23 Jul 2003 14:19:27 +0200") References: Message-ID: <2mn0f5mncc.fsf@starship.python.net> Jack Jansen writes: > I've just filed bug #776207: test_posixpath fails on MacOS9. The > problem is that it expects posixpath.ismount('/') to return > true. But on OS9 it returns false. I'm unsure as to the correct > behaviour of this on non-posix systems, does anyone have a > suggestion? How does it behave on Windows? Should test_posixpath > maybe only run some of the tests on non-posix systems? This last seems the right answer. Cheers, mwh -- Presumably pronging in the wrong place zogs it. -- Aldabra Stoddart, ucam.chat From walter@livinglogic.de Wed Jul 23 13:36:55 2003 From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=) Date: Wed, 23 Jul 2003 14:36:55 +0200 Subject: [Python-Dev] posixpath.ismount() on non-posix systems In-Reply-To: References: Message-ID: <3F1E8167.8060705@livinglogic.de> Jack Jansen wrote: > I've just filed bug #776207: test_posixpath fails on MacOS9. The problem > is that it expects posixpath.ismount('/') to return true. Checking ismount() was added as part of the port to PyUnit. > But on OS9 it returns > false. I'm unsure as to the correct behaviour of this on non-posix systems, > does anyone have a suggestion? How does it behave on Windows? Should > test_posixpath > maybe only run some of the tests on non-posix systems? If there isn't any path that reliably returns True or False the only test we could do is: assert_(isinstance(posixpath.ismount("/"), bool) This would at least cover the code. Bye, Walter Dörwald From barry@python.org Wed Jul 23 13:40:09 2003 From: barry@python.org (Barry Warsaw) Date: 23 Jul 2003 08:40:09 -0400 Subject: [Python-Dev] Re: MacPython-OS9 test failures In-Reply-To: References: Message-ID: <1058964009.29634.5.camel@anthem> On Wed, 2003-07-23 at 08:25, Jack Jansen wrote: > Barry (and others), > I added a couple of bug reports for things that fail in MacPython-OS9. > My personal feeling > is that it's best to leave fixing these until the unix/windows/MacOSX > release of Python 2.3 > has been done. This has the disadvantage that MacPython-OS9 and the > rest of the pythons > are built from slightly different source trees, but we've done that in > the past and > no-one seems to be bothered by it. That's not too bad, given that it should all sync up again for 2.3.1. I'd feel more comfortable with this option. -Barry From walter@livinglogic.de Wed Jul 23 14:41:39 2003 From: walter@livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=) Date: Wed, 23 Jul 2003 15:41:39 +0200 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <20030722213429.GI10306@epoch.metaslash.com> References: <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <16157.37523.384387.919749@montanaro.dyndns.org> <1058902849.13235.94.camel@yyz> <200307221945.h6MJjK414954@pcp02138704pcs.reston01.va.comcast.net> <20030722200424.GF10306@epoch.metaslash.com> <20030722213429.GI10306@epoch.metaslash.com> Message-ID: <3F1E9093.4030701@livinglogic.de> Neal Norwitz wrote: > On Tue, Jul 22, 2003 at 04:04:24PM -0400, Neal Norwitz wrote: > >> RedHat 6.2 isn't in the snake farm. Right now, things are in pretty >> good shape on the snake farm builds (I watch them on a regular basis). > > > Whoops, I lied. The snake-farm does have RedHat 6.2 that runs on an > Alpha. test_time fails on it, as does test_grp, test_pwd, and > test_struct in my builds. In the automated builds, only test_grp and > test_time fail. I've checked both test_pwd and test_grp on SFs alpha box in the compile farm and both run OK. It seems that grp.getgrall() doesn't return proper entries in the snakefarm build (looking at http://www.lysator.liu.se/xenofarm/python/files/757_17/python-testlog.txt). The docstring for grp states that the passwd entry is a string, but the code sets the passwd entry to Py_None if p->gr_passwd is NULL. So should we fix the documentation and the test for 2.3? Bye, Walter Dörwald From guido@python.org Wed Jul 23 15:00:11 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 23 Jul 2003 10:00:11 -0400 Subject: [Python-Dev] Until Monday... Message-ID: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> I'm going into the intense phase of our move now; my internet will soon be disconnected. I'll resurface Monday in California. In order to avoid having a huge backlog of email, I'm turning off delivery on my python-dev and python-checkins subscriptions. If you send a message guido@python.org, I should be able to get it Monday afternoon. I wish everyone, but especially Barry and the remaining two at PythonLabs, well with the release; you have my cell phone number! --Guido van Rossum (home page: http://www.python.org/~guido/) From lannert@uni-duesseldorf.de Wed Jul 23 15:34:50 2003 From: lannert@uni-duesseldorf.de (Detlef Lannert) Date: Wed, 23 Jul 2003 16:34:50 +0200 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: <20030722204201.11589.74038.Mailman@mail.python.org> References: <20030722204201.11589.74038.Mailman@mail.python.org> Message-ID: <20030723163450.E22274@lannert.rz.uni-duesseldorf.de> Tim Peters: > [Zooko] > > I wanted to see this bsddb3 explosion for myself, so I tried to build > > the module, but couldn't figure out how to do it. So I opened a bug > > report under the Build category: > > > > [ 775850 ] pybsddb build fails > > > > http://www.python.org/sf/775850 > > You should probably add detailed info to that bug report about the flavor > and version of Linux you're using, since nobody on Python-Dev has reported > problems building 2.3. This is maybe not the same problem that Zooko had, but bsddb doesn't build on my Linux 2.4.10 (SuSE 7.3) box either where Sleepycat db-4.1.25 was installed from the sources. It puts db.h under /usr/local/include per default where Python's setup.py doesn't find it. It used to be sufficient for me to add this directory to the db4 incdirs (see patch below) until 2.3c1 -- but this doesn't work for the CVS version any more. And yes, test_time fails with "AssertionError: AEST", too. For 2.3c1 as well as for current CVS. Detlef *** setup.py.orig Thu Jul 10 14:48:39 2003 --- setup.py Wed Jul 23 14:38:43 2003 *************** *** 490,495 **** --- 490,496 ---- '/opt/sfw/include/db4', '/sw/include/db4', '/usr/include/db4', + '/usr/local/include', )}, 'db3': {'libs': ('db-3.3', 'db-3.2', 'db-3.1', 'db3',), 'libdirs': ('/usr/local/BerkeleyDB.3.3/lib', From skip@pobox.com Wed Jul 23 16:15:39 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 23 Jul 2003 10:15:39 -0500 Subject: [Python-Dev] Until Monday... In-Reply-To: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> References: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <16158.42651.536961.248459@montanaro.dyndns.org> Guido> I wish everyone, but especially Barry and the remaining two at Guido> PythonLabs, well with the release; you have my cell phone number! Did I miss something? There were five at PythonLabs: Guido, Tim, Barry, Jeremy and Fred. Now Guido's leaving, but it seems there are only three left behind. Someone else apparently moved. What'd I miss? Skip From fdrake@acm.org Wed Jul 23 16:32:29 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 23 Jul 2003 11:32:29 -0400 Subject: [Python-Dev] posixpath.ismount() on non-posix systems In-Reply-To: References: Message-ID: <16158.43661.127599.602771@grendel.zope.com> Jack Jansen writes: > I've just filed bug #776207: test_posixpath fails on MacOS9. The > problem is that it expects posixpath.ismount('/') to return > true. But on OS9 it returns false. I'm unsure as to the correct > behaviour of this on non-posix systems, does anyone have a > suggestion? How does it behave on Windows? Should test_posixpath > maybe only run some of the tests on non-posix systems? There are two groups of functions in the *path module implementations: what I call "path algebra" functions, that only implement string operations specific to paths in the native syntax of the various platforms, and functions that have to care about the system they're running on, and understand the relevant set of filesystem semantics. I practice, it's really convenient to keep these together, but the tests should probably be re-examined. Tests of pure string operations should be run regardless of the platform on which the tests are running, and tests of functions that care about the host platform should only be run on the appropriate platforms. posixpath.ismount() should definately not be getting run on non-posix platforms. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From barry@python.org Wed Jul 23 16:43:54 2003 From: barry@python.org (Barry Warsaw) Date: 23 Jul 2003 11:43:54 -0400 Subject: [Python-Dev] Until Monday... In-Reply-To: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> References: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <1058975034.1062.1.camel@geddy> On Wed, 2003-07-23 at 10:00, Guido van Rossum wrote: > I'm going into the intense phase of our move now; my internet will > soon be disconnected. I'll resurface Monday in California. In order > to avoid having a huge backlog of email, I'm turning off delivery on > my python-dev and python-checkins subscriptions. If you send a > message guido@python.org, I should be able to get it Monday afternoon. > > I wish everyone, but especially Barry and the remaining two at > PythonLabs, well with the release; you have my cell phone number! So Fred, do you think it's too late to get that braces patch into Python 2.3? shh!-don't-tell-guido-ly y'rs, -Barry P.S. Good luck with the move. Hopefully Python as you know it will still be here when you get back . From tim.one@comcast.net Wed Jul 23 16:45:11 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 23 Jul 2003 11:45:11 -0400 Subject: [Python-Dev] Until Monday... In-Reply-To: <16158.42651.536961.248459@montanaro.dyndns.org> Message-ID: [Skip] > Did I miss something? There were five at PythonLabs: Guido, Tim, > Barry, Jeremy and Fred. Now Guido's leaving, but it seems there are > only three left behind. Someone else apparently moved. What'd I > miss? Jeremy is also in the midst of moving to a different state, although he'll still be working for Zope Corp. From guido@python.org Wed Jul 23 16:53:44 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 23 Jul 2003 11:53:44 -0400 Subject: [Python-Dev] Until Monday... References: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> <1058975034.1062.1.camel@geddy> Message-ID: <003b01c35132$a796d300$0181a8c0@reston01.va.comcast.net> > So Fred, do you think it's too late to get that braces patch into Python > 2.3? More to the point, at OSCON, the Perl folks auctioned off that I would check conditional expressions into CVS [*]. As soon as the PSF receives its half of the proceeds I'll do it. > shh!-don't-tell-guido-ly y'rs, > -Barry > > P.S. Good luck with the move. Hopefully Python as you know it will > still be here when you get back . Thanks! How about setting my python.org mail to forward to python.net? --Guido van Rossum (home page: http://www.python.org/~guido/) [*] On a branch. Don't tell the Perl folks. :) From skip@pobox.com Wed Jul 23 17:03:25 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 23 Jul 2003 11:03:25 -0500 Subject: [Python-Dev] Until Monday... In-Reply-To: <003b01c35132$a796d300$0181a8c0@reston01.va.comcast.net> References: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> <1058975034.1062.1.camel@geddy> <003b01c35132$a796d300$0181a8c0@reston01.va.comcast.net> Message-ID: <16158.45517.264067.516624@montanaro.dyndns.org> Guido> More to the point, at OSCON, the Perl folks auctioned off that I Guido> would check conditional expressions into CVS [*]. As soon as the Guido> PSF receives its half of the proceeds I'll do it. Speaking of which, wasn't there supposed to be a pie throwing contest between Guido and Dan Sugalski at OSCON? Who got pie-eyed? Skip From guido@python.org Wed Jul 23 17:19:03 2003 From: guido@python.org (Guido van Rossum) Date: Wed, 23 Jul 2003 12:19:03 -0400 Subject: [Python-Dev] Until Monday... References: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> <1058975034.1062.1.camel@geddy> <003b01c35132$a796d300$0181a8c0@reston01.va.comcast.net> <16158.45517.264067.516624@montanaro.dyndns.org> Message-ID: <004e01c35136$22b9ed80$0181a8c0@reston01.va.comcast.net> > Speaking of which, wasn't there supposed to be a pie throwing contest > between Guido and Dan Sugalski at OSCON? Who got pie-eyed? No, we just announced the pie-throwing to be held at OSCON 2004. I'll make the slides available as soon as my desktop machine is back on the net (in 2 weeks or so). --Guido van Rossum (home page: http://www.python.org/~guido/) From apurv_anand@hotmail.com Wed Jul 23 17:27:45 2003 From: apurv_anand@hotmail.com (Apurv Anand) Date: Wed, 23 Jul 2003 21:57:45 +0530 Subject: [Python-Dev] Cannot import... Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C35165.72CC3C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Need Help. I am writing a wrapper for a small .c function using SWIG The problem i am facing is that I am not able to import the module = generated by SWIG. Is there any special setting to be done to import custom modules in = Windows (Windows2000 to be specific) Below is the error that appears: File "", line 1, in ? File "example.py", line 4, in ? import _example ImportError: No module named _example thanks, apurv ------=_NextPart_000_000B_01C35165.72CC3C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Need Help.
 
I am writing a wrapper for a small .c = function=20 using SWIG
The problem i am facing is that I am = not able to=20 import the module generated by SWIG.
 
Is there any special setting to be done = to import=20 custom modules in Windows (Windows2000 to be specific)
 
Below is the error that = appears:
 
  File "<stdin>", line 1, in = ?
 =20 File "example.py", line 4, in ?
    import=20 _example
ImportError: No module named _example
 
thanks,
apurv
------=_NextPart_000_000B_01C35165.72CC3C40-- From skip@pobox.com Wed Jul 23 17:24:29 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 23 Jul 2003 11:24:29 -0500 Subject: [Python-Dev] Until Monday... In-Reply-To: <004e01c35136$22b9ed80$0181a8c0@reston01.va.comcast.net> References: <200307231400.h6NE0Bx16956@pcp02138704pcs.reston01.va.comcast.net> <1058975034.1062.1.camel@geddy> <003b01c35132$a796d300$0181a8c0@reston01.va.comcast.net> <16158.45517.264067.516624@montanaro.dyndns.org> <004e01c35136$22b9ed80$0181a8c0@reston01.va.comcast.net> Message-ID: <16158.46781.163573.94687@montanaro.dyndns.org> >> Speaking of which, wasn't there supposed to be a pie throwing contest >> between Guido and Dan Sugalski at OSCON? Who got pie-eyed? Guido> No, we just announced the pie-throwing to be held at OSCON 2004. Ah, good. There's still time to get psyco into the core. ;-) Skip From skip@pobox.com Wed Jul 23 17:46:36 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 23 Jul 2003 11:46:36 -0500 Subject: [Python-Dev] Cannot import... In-Reply-To: References: Message-ID: <16158.48108.776750.306751@montanaro.dyndns.org> Apurv> Need Help. Apurv, This mailing list is for issues related to the development of Python itself, not for questions about how to use Python. Please try python-list@python.org or its twin Usenet newsgroup, comp.lang.python. -- Skip Montanaro Got gigs? http://www.musi-cal.com/ Got spam? http://spambayes.sf.net/ From just@letterror.com Wed Jul 23 19:37:51 2003 From: just@letterror.com (Just van Rossum) Date: Wed, 23 Jul 2003 14:37:51 -0400 Subject: [Python-Dev] improved zipimport In-Reply-To: Message-ID: Thomas Heller wrote: > Thomas Heller writes: > > > martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes: > > > >> Thomas Heller writes: > >> > >>> It would be best if someone else who really uses zipimports would be > >>> able to test it - I really don't want to break anything. > >> > >> Then 2.3 should go unchanged. If there is a way to construct proper > >> zipfiles for zipimports, this should be sufficient. Any support for > >> additional "kinds" of zipfiles should count as a new feature. > > > > It's already checked in. > > Should it be backed out again? > Can the powers please decide? I'm going to test it with my stuff today or tomorrow. I would very much like this to go in. It's had a bug report for a long time, and since it's a *property* of zip files they can be prepended with arbitrary junk, it's indeed a bug fix, not a new feature. Just From drifty@alum.berkeley.edu Wed Jul 23 19:58:45 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Wed, 23 Jul 2003 11:58:45 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <2m8yqpoe6g.fsf@starship.python.net> References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> <3F1DB0AD.90407@ocf.berkeley.edu> <3F1DBD75.9060504@ocf.berkeley.edu> <2m8yqpoe6g.fsf@starship.python.net> Message-ID: <3F1EDAE5.4070003@ocf.berkeley.edu> Michael Hudson wrote: > "Brett C." writes: > > >>Nuts. Well, then I am stumped on how to fix this tzset problem. The >>damn autoconf code should have failed and thus time.tzset should not >>have been compiled. >> >>Any suggestions? > > > Not worrying about it too much? > Yeah, I am there in terms of getting this done in time for 2.3 . If it takes this much effort for people to dig up a RH 6.2 system I suspect most people have upgraded by now. I don't think we are going to get a thorough enough of a testing of this patch so I am going to stop worrying about this and redirect it to worrying about moving in a month. -Brett From barry@python.org Wed Jul 23 20:57:49 2003 From: barry@python.org (Barry Warsaw) Date: 23 Jul 2003 15:57:49 -0400 Subject: [Python-Dev] improved zipimport In-Reply-To: References: Message-ID: <1058990268.1763.13.camel@geddy> On Wed, 2003-07-23 at 14:37, Just van Rossum wrote: > > Should it be backed out again? > > Can the powers please decide? > > I'm going to test it with my stuff today or tomorrow. I would very much > like this to go in. It's had a bug report for a long time, and since > it's a *property* of zip files they can be prepended with arbitrary > junk, it's indeed a bug fix, not a new feature. Yes, at this point, leave it in. -Barry From barry@python.org Wed Jul 23 21:02:01 2003 From: barry@python.org (Barry Warsaw) Date: 23 Jul 2003 16:02:01 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <3F1EDAE5.4070003@ocf.berkeley.edu> References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> <3F1DB0AD.90407@ocf.berkeley.edu> <3F1DBD75.9060504@ocf.berkeley.edu> <2m8yqpoe6g.fsf@starship.python.net> <3F1EDAE5.4070003@ocf.berkeley.edu> Message-ID: <1058990521.1763.19.camel@geddy> On Wed, 2003-07-23 at 14:58, Brett C. wrote: > Yeah, I am there in terms of getting this done in time for 2.3 . If it > takes this much effort for people to dig up a RH 6.2 system I suspect > most people have upgraded by now. I don't think we are going to get a > thorough enough of a testing of this patch so I am going to stop > worrying about this and redirect it to worrying about moving in a month. +1, or really +0.0.1 :) there's-always-2.3.1-ly y'rs, -Barry From drifty@alum.berkeley.edu Wed Jul 23 21:04:59 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Wed, 23 Jul 2003 13:04:59 -0700 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: References: Message-ID: <3F1EEA6B.6010001@ocf.berkeley.edu> Tim Peters wrote: > [Brett C.] >>I should have been more explicit; I meant after *every* individual >>test and not after the battery of tests. > > > OK, and back to an unpatched _strptime.py. With the current CVS > locale-restoration code (which differs from what it was half an hour ago, > but should have the same effect): > > > > Again, without restoring locale in test_logging: > > C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime > test_logging > test_time > time.strftime("%c") > '07/22/03 20:39:09' > So no AM/PM. > _strptime.TimeRE()['c'] > '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| > [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) > :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' > > locale.getdefaultlocale() > ('en_US', 'cp1252') > > locale.getlocale(locale.LC_TIME) > (None, None) > Note value of here. > test_strptime > time.strftime("%c") > '07/22/03 20:39:10' > > _strptime.TimeRE()['c'] > '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| > [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) > :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' > > locale.getdefaultlocale() > ('en_US', 'cp1252') > > locale.getlocale(locale.LC_TIME) > (None, None) > > test_logging > time.strftime("%c") > '07/22/2003 08:39:11 PM' > > _strptime.TimeRE()['c'] > '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| > [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) > :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' > > locale.getdefaultlocale() > ('en_US', 'cp1252') > > locale.getlocale(locale.LC_TIME) > ['English_United States', '1252'] > > test_time > test test_time failed -- Traceback (most recent call last): > File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime > self.fail('conversion specifier: %r failed.' % format) > File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail > raise self.failureException, msg > AssertionError: conversion specifier: ' %c' failed. > > time.strftime("%c") > '07/22/2003 08:39:13 PM' > test_logging does its magic and now AM/PM appears. > _strptime.TimeRE()['c'] > '(?P1[0-2]|0[1-9]|[1-9])/(?P3[0-1]|[1-2]\\d|0[1-9]| > [1-9]| [1-9])/(?P\\d\\d)\\s*(?P2[0-3]|[0-1]\\d|\\d) > :(?P[0-5]\\d|\\d):(?P6[0-1]|[0-5]\\d|\\d)' > > locale.getdefaultlocale() > ('en_US', 'cp1252') > > locale.getlocale(locale.LC_TIME) > ['English_United States', '1252'] > And now locale.getlocale(locale.LC_TIME) returns a different value! > 2 tests OK. > 1 test failed: > test_time > > C:\Code\python\PCbuild> > So this should be solvable by changing some comparison code and what is used to represent the language. I will have a look and see if I can figure out where this is going wrong. If I don't have it fixed by the end of today I will rip out the caching code and just leave a fix for 2.3.1 and 2.4 . -Brett From drifty@alum.berkeley.edu Wed Jul 23 21:18:22 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Wed, 23 Jul 2003 13:18:22 -0700 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <1058990521.1763.19.camel@geddy> References: <3F1D8E67.8010609@ocf.berkeley.edu> <3F10D7E7.3080304@ocf.berkeley.edu> <3F1D8E67.8010609@ocf.berkeley.edu> <5.1.1.6.0.20030722154938.030269c0@telecommunity.com> <2mk7aanxbw.fsf@starship.python.net> <3F1DB0AD.90407@ocf.berkeley.edu> <3F1DBD75.9060504@ocf.berkeley.edu> <2m8yqpoe6g.fsf@starship.python.net> <3F1EDAE5.4070003@ocf.berkeley.edu> <1058990521.1763.19.camel@geddy> Message-ID: <3F1EED8E.2090209@ocf.berkeley.edu> Barry Warsaw wrote: > On Wed, 2003-07-23 at 14:58, Brett C. wrote: > > >>Yeah, I am there in terms of getting this done in time for 2.3 . If it >>takes this much effort for people to dig up a RH 6.2 system I suspect >>most people have upgraded by now. I don't think we are going to get a >>thorough enough of a testing of this patch so I am going to stop >>worrying about this and redirect it to worrying about moving in a month. > > > +1, or really +0.0.1 :) > Half of the plutocracy has spoken, which is enough for me. > there's-always-2.3.1-ly y'rs, > -Barry > > Yep. It never ends! -Brett From drifty@alum.berkeley.edu Wed Jul 23 21:35:27 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Wed, 23 Jul 2003 13:35:27 -0700 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: <3F1EEA6B.6010001@ocf.berkeley.edu> References: <3F1EEA6B.6010001@ocf.berkeley.edu> Message-ID: <3F1EF18F.2050007@ocf.berkeley.edu> This is a multi-part message in MIME format. --------------020902050401080502050405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Brett C. wrote: > So this should be solvable by changing some comparison code and what is > used to represent the language. I will have a look and see if I can > figure out where this is going wrong. If I don't have it fixed by the > end of today I will rip out the caching code and just leave a fix for > 2.3.1 and 2.4 . > Tim (or someone else who can replicate the problem), can you give the attached patch a try? This should fix the problem. There are new tests on top of a proposed fix. If this doesn't solve it then I am giving up on getting the caching to work for this release. -Brett --------------020902050401080502050405 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="strptime.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="strptime.diff" Index: Lib/_strptime.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/_strptime.py,v retrieving revision 1.21 diff -u -r1.21 _strptime.py --- Lib/_strptime.py 13 Jul 2003 01:31:38 -0000 1.21 +++ Lib/_strptime.py 23 Jul 2003 20:31:07 -0000 @@ -27,15 +27,7 @@ def _getlang(): # Figure out what the current language is set to. - current_lang = locale.getlocale(locale.LC_TIME)[0] - if current_lang: - return current_lang - else: - current_lang = locale.getdefaultlocale()[0] - if current_lang: - return current_lang - else: - return '' + return locale.getlocale(locale.LC_TIME) class LocaleTime(object): """Stores and handles locale-specific information related to time. @@ -103,7 +95,10 @@ raise TypeError("timezone names must contain 2 items") else: self.__timezone = self.__pad(timezone, False) - self.__lang = lang + if lang: + self.__lang = lang + else: + self.__lang = _getlang() def __pad(self, seq, front): # Add '' to seq to either front (is True), else the back. @@ -196,13 +191,7 @@ LC_time = property(__get_LC_time, __set_nothing, doc="Format string for locale's time representation ('%X' format)") - def __get_lang(self): - # Fetch self.lang. - if not self.__lang: - self.__calc_lang() - return self.__lang - - lang = property(__get_lang, __set_nothing, + lang = property(lambda self: self.__lang, __set_nothing, doc="Language used for instance") def __calc_weekday(self): @@ -295,11 +284,6 @@ time_zones.append(time.tzname[0]) self.__timezone = self.__pad(time_zones, 0) - def __calc_lang(self): - # Set self.__lang by using __getlang(). - self.__lang = _getlang() - - class TimeRE(dict): """Handle conversion from format directives to regexes.""" @@ -416,10 +400,13 @@ global _locale_cache global _regex_cache locale_time = _locale_cache.locale_time - # If the language changes, caches are invalidated, so clear them - if locale_time.lang != _getlang(): + # If the language changes, caches are invalidated, so clear them. + # Also assume that if we can't figure out locale (as represented by + # (None, None)) then we just clear the cache to be safe. + if (_getlang() == (None, None)) or (locale_time.lang != _getlang()): _locale_cache = TimeRE() _regex_cache.clear() + locale_time = _locale_cache.locale_time format_regex = _regex_cache.get(format) if not format_regex: # Limit regex cache size to prevent major bloating of the module; Index: Lib/test/test_strptime.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_strptime.py,v retrieving revision 1.18 diff -u -r1.18 test_strptime.py --- Lib/test/test_strptime.py 22 Jul 2003 21:07:16 -0000 1.18 +++ Lib/test/test_strptime.py 23 Jul 2003 20:31:07 -0000 @@ -8,6 +8,11 @@ import _strptime +class getlang_Tests(unittest.TestCase): + """Test _getlang""" + def test_basic(self): + self.failUnlessEqual(_strptime._getlang(), locale.getlocale(locale.LC_TIME)) + class LocaleTime_Tests(unittest.TestCase): """Tests for _strptime.LocaleTime.""" @@ -89,11 +94,9 @@ "empty strings") def test_lang(self): - # Make sure lang is set - self.failUnless(self.LT_ins.lang in (locale.getdefaultlocale()[0], - locale.getlocale(locale.LC_TIME)[0], - ''), - "Setting of lang failed") + # Make sure lang is set to what _getlang() returns + # Assuming locale has not changed between now and when self.LT_ins was created + self.failUnlessEqual(self.LT_ins.lang, _strptime._getlang()) def test_by_hand_input(self): # Test passed-in initialization value checks @@ -411,14 +414,44 @@ "Calculation of day of the week failed;" "%s != %s" % (result.tm_wday, self.time_tuple.tm_wday)) +class Cache_Tests(unittest.TestCase): + """Make sure handling of cache is correct""" + def test_normal_clearing(self): + # Make sure the cache is cleared properly when lang value is different + time_re = _strptime.TimeRE(locale_time=_strptime.LocaleTime(lang='Ni')) + _strptime._locale_cache = time_re + _strptime.strptime(time.strftime("%c"), "%c") + self.failIfEqual(id(_strptime._locale_cache), id(time_re)) + self.failUnlessEqual(len(_strptime._regex_cache), 1) + + def test_NoneNone_clearing(self): + # Make sure cache changes when lang is set to (None, None) + time_re = _strptime.TimeRE(locale_time=_strptime.LocaleTime(lang=(None, None))) + _strptime_locale_cache = time_re + _strptime.strptime(time.strftime("%c"), "%c") + self.failIfEqual(id(time_re), id(_strptime._locale_cache)) + self.failUnlessEqual(len(_strptime._regex_cache), 1) + + def test_use_new_cache(self): + # Make sure that when a new cache value is guaranteed to be created + # that it is used + time_re = _strptime.TimeRE(locale_time=_strptime.LocaleTime( + LC_date_time = "%d", + lang="Ni") + ) + _strptime._locale_cache = time_re + self.failUnlessRaises(ValueError, _strptime.strptime, "23", "%c") + def test_main(): test_support.run_unittest( + getlang_Tests, LocaleTime_Tests, TimeRETests, StrptimeTests, Strptime12AMPMTests, JulianTests, - CalculationTests + CalculationTests, + Cache_Tests ) --------------020902050401080502050405-- From tim.one@comcast.net Wed Jul 23 21:47:27 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 23 Jul 2003 16:47:27 -0400 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: <3F1EF18F.2050007@ocf.berkeley.edu> Message-ID: [Brett C.] > Tim (or someone else who can replicate the problem), can you give the > attached patch a try? Yes, and happy to do so, but can't for several hours. Later tonight. From Jack.Jansen@cwi.nl Wed Jul 23 22:33:13 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 23 Jul 2003 23:33:13 +0200 Subject: [Python-Dev] posixpath.ismount() on non-posix systems In-Reply-To: <16158.43661.127599.602771@grendel.zope.com> Message-ID: <43AF16AC-BD55-11D7-A35F-000A27B19B96@cwi.nl> On woensdag, jul 23, 2003, at 17:32 Europe/Amsterdam, Fred L. Drake, Jr. wrote: > There are two groups of functions in the *path module implementations: > what I call "path algebra" functions, that only implement string > operations specific to paths in the native syntax of the various > platforms, and functions that have to care about the system they're > running on, and understand the relevant set of filesystem semantics. > > I practice, it's really convenient to keep these together, but the > tests should probably be re-examined. Tests of pure string operations > should be run regardless of the platform on which the tests are > running, and tests of functions that care about the host platform > should only be run on the appropriate platforms. > > posixpath.ismount() should definately not be getting run on non-posix > platforms. Fully agreed here. How about the following solution: we leave test_posixpath as-is for 2.3 and I add a note to the MacPython-OS9 readme that this failure is expected, and then we fix the test in this way for 2.3.1? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From fdrake@acm.org Wed Jul 23 22:38:14 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 23 Jul 2003 17:38:14 -0400 Subject: [Python-Dev] posixpath.ismount() on non-posix systems In-Reply-To: <43AF16AC-BD55-11D7-A35F-000A27B19B96@cwi.nl> References: <16158.43661.127599.602771@grendel.zope.com> <43AF16AC-BD55-11D7-A35F-000A27B19B96@cwi.nl> Message-ID: <16159.70.217627.804122@grendel.zope.com> Jack Jansen writes: > Fully agreed here. How about the following solution: we leave > test_posixpath as-is for 2.3 and I add a note to the MacPython-OS9 > readme that this failure is expected, and then we fix the test in > this way for 2.3.1? Sounds good to me! Changing code in 2.3 for this isn't worth the risk. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From barry@python.org Wed Jul 23 22:44:07 2003 From: barry@python.org (Barry Warsaw) Date: 23 Jul 2003 17:44:07 -0400 Subject: [Python-Dev] posixpath.ismount() on non-posix systems In-Reply-To: <43AF16AC-BD55-11D7-A35F-000A27B19B96@cwi.nl> References: <43AF16AC-BD55-11D7-A35F-000A27B19B96@cwi.nl> Message-ID: <1058996647.1763.97.camel@geddy> On Wed, 2003-07-23 at 17:33, Jack Jansen wrote: > > Fully agreed here. How about the following solution: we leave > test_posixpath > as-is for 2.3 and I add a note to the MacPython-OS9 readme that this > failure > is expected, and then we fix the test in this way for 2.3.1? +1 -Barry From janssen@parc.com Wed Jul 23 22:58:26 2003 From: janssen@parc.com (Bill Janssen) Date: Wed, 23 Jul 2003 14:58:26 PDT Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: Your message of "Wed, 23 Jul 2003 04:58:52 PDT." <2mznj5mp37.fsf@starship.python.net> Message-ID: <03Jul23.145838pdt."58611"@synergy1.parc.xerox.com> > 1) It would be nice to find out what lookupd is up to during the loop. > I couldn't find out how to get it to tell me (for one thing, the > lookupd(8) manpage seems to be very out of date wrt. locating > config info). > > 2) One obvious difference between the slow Python program and the fast > C program is that Python has calls to bind() in between the calls > to getaddrinfo()... maybe this (or something else) causes lookupd > to toss its cache for some reason? I'm sure Jack has better data than this, but NetInfo can be the source of much delay, on 10.2.x, because it runs old and rather poorly written "plugins" to gather data to resolve address info. The solution appears to be: make sure that your local NetInfo DB doesn't have a "locations" key, and that you have enabled "BSD Configuration Files", and disabled "NetInfo", using the "Directory Access" app. This can speed up address info lookups by two orders of magnitude. Bill From Jack.Jansen@cwi.nl Wed Jul 23 23:13:01 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 24 Jul 2003 00:13:01 +0200 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <03Jul23.145838pdt."58611"@synergy1.parc.xerox.com> Message-ID: On woensdag, jul 23, 2003, at 23:58 Europe/Amsterdam, Bill Janssen wrote: >> 1) It would be nice to find out what lookupd is up to during the loop. >> I couldn't find out how to get it to tell me (for one thing, the >> lookupd(8) manpage seems to be very out of date wrt. locating >> config info). >> >> 2) One obvious difference between the slow Python program and the fast >> C program is that Python has calls to bind() in between the calls >> to getaddrinfo()... maybe this (or something else) causes lookupd >> to toss its cache for some reason? > > I'm sure Jack has better data than this, but NetInfo can be the source > of much delay, on 10.2.x, because it runs old and rather poorly > written "plugins" to gather data to resolve address info. The > solution appears to be: make sure that your local NetInfo DB doesn't > have a "locations" key, and that you have enabled "BSD Configuration > Files", and disabled "NetInfo", using the "Directory Access" app. > This can speed up address info lookups by two orders of magnitude. You seriously overestimate me, Bill. "Jack" and "BSD" are the two words I recognize in the paragraph above:-) But seriously: I don't think this is the core problem (as C code that we think is equivalent runs like a bat out of hell), and we can't really ask people to muck with their configuration only to make Python getaddrinfo() calls run faster. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From skip@pobox.com Wed Jul 23 23:28:38 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 23 Jul 2003 17:28:38 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <03Jul23.145838pdt."58611"@synergy1.parc.xerox.com> References: <2mznj5mp37.fsf@starship.python.net> <03Jul23.145838pdt."58611"@synergy1.parc.xerox.com> Message-ID: <16159.3094.518692.945222@montanaro.dyndns.org> Bill, Thanks for the (net)info. This will be useful information to put somewhere in the release notes. Skip From skip@pobox.com Wed Jul 23 23:30:50 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 23 Jul 2003 17:30:50 -0500 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: References: <03Jul23.145838pdt."58611"@synergy1.parc.xerox.com> Message-ID: <16159.3226.11330.405278@montanaro.dyndns.org> Jack> But seriously: I don't think this is the core problem (as C code Jack> that we think is equivalent runs like a bat out of hell), and we Jack> can't really ask people to muck with their configuration only to Jack> make Python getaddrinfo() calls run faster. Well, to be fair, my C code *only* calls getaddrinfo(), not anything else which might tickle netinfo/lookupd. Someone else (mwh? I seem to have deleted the note) found strong evidence that Kerberos can be similarly plagued. Skip From tim.one@comcast.net Thu Jul 24 00:57:42 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 23 Jul 2003 19:57:42 -0400 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: <3F1EF18F.2050007@ocf.berkeley.edu> Message-ID: [Brett C.] > Tim (or someone else who can replicate the problem), can you give the > attached patch a try? This should fix the problem. There are new > tests on top of a proposed fix. If this doesn't solve it then I am > giving up on getting the caching to work for this release. Sorry, no joy! With the patch, and removing test_logging's restoration of locale, the symptom remains the same: C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test_logging test_time test test_time failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\CODE\PYTHON\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. 2 tests OK. 1 test failed: test_time Remove test_strptime, or test_logging, from the mix, and test_time passes. There's a different failure mode if the order of the first two is swapped: C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_logging test_strptime test_time test_logging test_strptime test test_strptime failed -- Traceback (most recent call last): File "C:\CODE\PYTHON\lib\test\test_strptime.py", line 433, in test_NoneNone_cl earing self.failUnlessEqual(len(_strptime._regex_cache), 1) File "C:\CODE\PYTHON\lib\unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 4 != 1 test_time 2 tests OK. 1 test failed: test_strptime From greg@cosc.canterbury.ac.nz Thu Jul 24 01:15:59 2003 From: greg@cosc.canterbury.ac.nz (Greg Ewing) Date: Thu, 24 Jul 2003 12:15:59 +1200 (NZST) Subject: [Python-Dev] posixpath.ismount() on non-posix systems In-Reply-To: <3F1E8167.8060705@livinglogic.de> Message-ID: <200307240015.h6O0Fx524936@oma.cosc.canterbury.ac.nz> Jack Jansen wrote: > Should test_posixpath maybe only run some of the tests on non-posix > systems? Seems to me it doesn't make sense to test posixpath.ismount on a non-posix system, since it examines the file system. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ From tim.one@comcast.net Thu Jul 24 03:59:01 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 23 Jul 2003 22:59:01 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F13027ABA9B@its-xchg4.massey.ac.nz> Message-ID: [copying to Python-Dev because it relates to a recent thread there too] [Meyer, Tony] > No doubt I should ask this on python-list not here, but since Tim > would probably be the one to answer it anyway... :) Why does the > setlocale() function give that impression? If LC_NUMERIC should > always be "C", shouldn't setlocale(LC_NUMERIC, x) raise some sort of > exception? Reading the locale module docs should make it clearer. If it's still unclear after reading the docs, ask again . For a concrete example of why it's still useful to "pretend" to change LC_NUMERIC, see below (the locale module functions are sensitive to the change, and the code below couldn't be written otherwise). > Maybe Outlook is at fault here? I've certainly seen that some of the > Outlook/COM/MAPI calls make changes to the locale. In particular, > mapi.MAPILogonEx() does - it changes the locale to whatever Outlook > (i.e. Windows) thinks it is. Could this then be screwing things up > for us? Oh yes. A .pyc file contains a compiled form of Python code objects. Part of what's in a .pyc file is the "marshal" form of numeric literals referenced by the source code. It so happens that marshal stores float literals as strings (repr-style). The unmarshaling code (executed when a .pyc file is loaded) is written in C, and uses C's atof() to convert these strings back to C doubles. atof() is locale-sensitive, so can screw up royally if LC_NUMERIC isn't "C" at the time a module is loaded. Here's a little program we can use to predict this kind of damage: """ import marshal, locale def damage(afloat, lcnumeric): s = marshal.dumps(afloat) print repr(afloat), "->", repr(s) # Now emulate unmarshaling that under a given locale. # Strip the type code and byte count. assert s[0] == 'f' raw = s[2:] print "Under locale %r that loads as" % lcnumeric, locale.setlocale(locale.LC_NUMERIC, lcnumeric) print repr(locale.atof(raw)) locale.setlocale(locale.LC_NUMERIC, "C") """ For example, running damage(0.001, "German") displays: """ 0.001 -> 'f\x050.001' Under locale 'German' that loads as 1.0 """ while damage(0.001, "C") displays what Python needs to happen instead: """ 0.001 -> 'f\x050.001' Under locale 'C' that loads as 0.001 """ So all kinds of bad things *can* happen. I'm still baffled by the spambayes logfile, though, because the failing assert is here: def set_stages(self, stages): self.stages = [] start_pos = 0.0 for name, prop in stages: stage = name, start_pos, prop start_pos += prop self.stages.append(stage) assert (abs(start_pos-1.0)) < 0.001, \ "Proportions must add to 1.0 (%g,%r)" % (start_pos, stages) and the failing call is here: self.set_stages( (("", 1.0),) ) Under a locale that ignores periods, string -> double 0.0 -> 0.0 1.0 -> 10.0 0.001 -> 1.0 So the assert above would act like assert (abs(start_pos-10.0)) < 1.0, \ and the call would act like self.set_stages( (("", 10.0),) ) start_pos - 10.0 would still be 0 then, and the assert should not fail. >From the logfile, we also know that start_pos was actually 1.0 in the failing case, and that the "1.0" at the call site also loaded as expected: AssertionError: Proportions must add to 1.0 (1,(('', 1.0),)) If the literals in this line alone got screwed up: assert (abs(start_pos-1.0)) < 0.001, \ that would fit all the symptoms. Then start_pos would be 1.0, 10.0 would get subtracted from that, and 9.0 is not less than 1.0. So we should change the assert to show us also the value of start_pos-1.0. If that's -9.0, I'll be baffled for a different reason. PS: For fun, look at what this displays: damage(0.1, "German") If you guessed 1.0 was the final loaded result, you're not even close to the right universe . From tim.one@comcast.net Thu Jul 24 04:43:39 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 23 Jul 2003 23:43:39 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <001601c35192$3b0982e0$f502a8c0@eden> Message-ID: [Mark Hammond] > Hrm - OK - I bit the bullet, and re-booted as German locale. If I > remove all calls to setlocale(), I can provoke come *very* strange > math errors. > Both: > > File "E:\src\spambayes\Outlook2000\manager.py", line 664, in score > return self.bayes.spamprob(bayes_tokenize(email), evidence) > File "E:\src\spambayes\spambayes\classifier.py", line 236, in > chi2_spamprob > S = ln(S) + Sexp * LN2 > exceptions.OverflowError: math range error Can you investigate this one a bit deeper? My guess is that S *= 1.0 - prob in the loop before is treating 1.0 as 10.0 due to the .pyc-file locale-dependent loading problem I detailed earlier, and that S is overflowing to infinity as a result. Printing S inside the loop would shed best light on this, and printing S when the OverflowError occurs would nail it: >>> import math >>> S = 1e200 * 1e200 >>> S 1.#INF >>> math.log(S) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error >>> Not all platforms will raise OverflowError on log(infinity), but Windows Python does. No platform other than Windows displays infinity as 1.#INF, by the way (that's what MS C produces). From tim.one@comcast.net Thu Jul 24 04:51:49 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 23 Jul 2003 23:51:49 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <001601c35192$3b0982e0$f502a8c0@eden> Message-ID: [Mark Hammond] > ... > Googling for this, I found a mail Tim should find either interesting > or terrifying - it mentions not only locale issues, but floating point > exception masks: > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&threadm= > %23MuH%23LU8BHA.2344%40tkmsftngp04 Heh. I'm only surprised the guy got pointed to printer drivers so fast! In Dragon's core speech recognition engine, we had mounds of paranoid code assuming that any call to anything we didn't write would screw up the FPU control registers. Driver writers seem to believe they need to fiddle every bit the hardware exposes, but they're incompetent to do so . Python has ignored this issue so far -- just as it's ignored almost all 754 issues. I'm surprised that nobody in PythonLand has ever reported a bug of this nature. Maybe those who experience it just write it off to general Windows flakiness ... but it shouldn't matter to spambayes. The fp arithmetic in spambayes should never overflow, underflow, or divide by 0, no matter how extreme the inputs -- and I know what each of the bits in the FPU control registers actually do . From tim.one@comcast.net Thu Jul 24 04:55:40 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 23 Jul 2003 23:55:40 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <001601c35192$3b0982e0$f502a8c0@eden> Message-ID: [Mark Hammond] > ... > Hrm - OK - I bit the bullet, and re-booted as German locale. If I > remove all calls to setlocale(), I can provoke come *very* strange > math errors. Both: > > ... > - and in the "training" dialog, I can reproduce the original bug: > > File "E:\src\spambayes\Outlook2000\dialogs\AsyncDialog.py", line > 45, in set_stages > assert (abs(start_pos-1.0)) < 0.001, \ > AssertionError: Proportions must add to 1.0 (1.0,(('', 1.0),)) That one is still baffling to me, for reasons explained in great detail before (if none of the float literals in this file get screwed, *or* if all of them get screwed by locale, this assert shouldn't fail -- locale has to be screwing up some of the float literals but not others, and that possibility remains baffling to me). Note that I checked in a new version of this assert that displays more info when it fails. From T.A.Meyer@massey.ac.nz Thu Jul 24 05:02:37 2003 From: T.A.Meyer@massey.ac.nz (Meyer, Tony) Date: Thu, 24 Jul 2003 16:02:37 +1200 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F13027ABC63@its-xchg4.massey.ac.nz> > > File > "E:\src\spambayes\Outlook2000\dialogs\AsyncDialog.py", line 45, > > in set_stages > > assert (abs(start_pos-1.0)) < 0.001, \ > > AssertionError: Proportions must add to 1.0 (1.0,(('', 1.0),)) >=20 > That one is still baffling to me, for reasons explained in > great detail before (if none of the float literals in this=20 > file get screwed, *or* if all of them get screwed by locale,=20 > this assert shouldn't fail -- locale has to be screwing up=20 > some of the float literals but not others, and that=20 > possibility remains baffling to me). Note that I checked in=20 > a new version of this assert that displays more info when it fails. I tried with that version, and then added a print of my own. I get: 1.0 0.0 0.0 0.0 False Traceback (most recent call last): [...] File "D:\cvs\spambayes\spambayes\Outlook2000\dialogs\AsyncDialog.py", line 46, in set_stages assert abs(start_pos-1.0) < 0.001, ( AssertionError: Proportions must add to 1.0 (1.0,(('', 1.0),),0.0) I added as line 45: print start_pos, start_pos-1.0, abs(start_pos-1.0), 0.001, 0.0 < 0.001 So it's 0.0 < 0.001 that fails. Got to go to a meeting now, will try more afterwards. =3DTony Meyer From mhammond@skippinet.com.au Thu Jul 24 05:13:04 2003 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 24 Jul 2003 14:13:04 +1000 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: Message-ID: <003701c35199$e1bf90a0$f502a8c0@eden> [Tim] > [Mark Hammond] > > Hrm - OK - I bit the bullet, and re-booted as German locale. If I > > remove all calls to setlocale(), I can provoke come *very* strange > > math errors. > > Both: > > > > File "E:\src\spambayes\Outlook2000\manager.py", line 664, in score > > return self.bayes.spamprob(bayes_tokenize(email), evidence) > > File "E:\src\spambayes\spambayes\classifier.py", line 236, in > > chi2_spamprob > > S = ln(S) + Sexp * LN2 > > exceptions.OverflowError: math range error > > Can you investigate this one a bit deeper? My guess is that > > S *= 1.0 - prob > > in the loop before is treating 1.0 as 10.0 due to the .pyc-file > locale-dependent loading problem I detailed earlier, and that S is > overflowing to infinity as a result. Printing S inside the > loop would shed > best light on this, and printing S when the OverflowError > occurs would nail > it: OK, the code now looks like: print repr(S), repr(H) S = ln(S) + Sexp * LN2 H = ln(H) + Hexp * LN2 And I tested on a hammy mail. I got: 3,0955714375167259e-015 0.0 ... File "E:\src\spambayes\spambayes\classifier.py", line 238, in chi2_spamprob H = ln(H) + Hexp * LN2 exceptions.OverflowError: math range error A spam yields: 0.0 0.0 File "E:\src\spambayes\spambayes\classifier.py", line 237, in chi2_spamprob S = ln(S) + Sexp * LN2 exceptions.OverflowError: math range error Interestingly, S in the first one uses a comma, while all the zeroes got '.' Clueless ly, Mark. From tim.one@comcast.net Thu Jul 24 05:21:13 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 00:21:13 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F13027ABC63@its-xchg4.massey.ac.nz> Message-ID: [Meyer, Tony] OK, you did this print: print start_pos, start_pos-1.0, abs(start_pos-1.0), 0.001, 0.0 < 0.001 and it displayed 1.0 0.0 0.0 0.0 False > ... > So it's 0.0 < 0.001 that fails. And specifically because "0.001" is being treated as exactly 0. Which locale was in effect? This is starting to get odd . From tim.one@comcast.net Thu Jul 24 05:34:37 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 00:34:37 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <003701c35199$e1bf90a0$f502a8c0@eden> Message-ID: [Mark Hammond] > OK, the code now looks like: > > print repr(S), repr(H) > S = ln(S) + Sexp * LN2 > H = ln(H) + Hexp * LN2 > > And I tested on a hammy mail. I got: > > 3,0955714375167259e-015 0.0 > ... > File "E:\src\spambayes\spambayes\classifier.py", line 238, in > chi2_spamprob > H = ln(H) + Hexp * LN2 > exceptions.OverflowError: math range error So H == 0.0 is the culprit. Unexpected! > A spam yields: > 0.0 0.0 > File "E:\src\spambayes\spambayes\classifier.py", line 237, in > chi2_spamprob > S = ln(S) + Sexp * LN2 > exceptions.OverflowError: math range error So S == 0.0 irritated math.log first. Equally unexpected . > Interestingly, S in the first one uses a comma, while all the zeroes > got '.' > > Clueless ly, Well, the last one is easy: *Python* adds the dot to 0. Python's repr() for floats *generally* acts like C's %.17g, except for repr(a_float_that_happens_to_be_an_exect_integer) plus a couple others you don't want to hear about . Then C does >>> "%.17g" % 0.0 '0' >>> and that violates Guido's desire that the *type* of an object be apparent from its repr. So Python's format_float (in floatobject.c) first lets C have a crack at it, and if C's sprintf didn't stick in a radix point, Python appends its own, plus a trailing zero: *cp++ = '.'; *cp++ = '0'; *cp++ = '\0'; Back to spambayes, H and S can't become zero . The only way they could is if a computed probability is 0.0 or 1.0, and that's never supposed to happen. Printing 'prob' in the loop would tell us whether that's so, but, if it is so, the true cause could be in a ton of other code. From mhammond@skippinet.com.au Thu Jul 24 06:03:55 2003 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 24 Jul 2003 15:03:55 +1000 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: Message-ID: <000d01c351a0$fbdb8230$f502a8c0@eden> I had yet *more* code fail which I felt sure was due to the locale issue. I added a print locale.getlocale() directly before the failing code. As expected, it indicated 'us' - but then the code started working. Digging into the source deeper, it becomes apparent that locale.getlocale() is useless for us here. If an external application has set the locale, locale.getlocale() will have the effect of *restoring* the locale to what Python previously thought it was. This value is then returned. [Also note that setlocale() leaks the "remembered" value each subsequent call to change the locale] Consider: * Python script calls locale.setlocale(LC_NUMERIC, "us") * _locale module remembers "us", but leaves with the CRT locale left to 'C' * Python script calls external function (MAPI). This changes the CRT locale. * Python script then calls locale.getlocale() to see what the locale is. * Python restores to the remembered 'us' from (1) above. It then queries the locale (which seems strange given it just set it!) 'us' is returned, and the locale has been changed back to it. However, we have no clue what the CRT thought the locale was. So that means all my investigation of how the locale changed underneath us via MAPI is completely invalid :( On the plus side, it seems that simply querying the current locale is enough to get the CRT back into whatever state a Python script ever set it to, and get stuff running again. Unfortunately, I'm having trouble working out exactly where that would be - but will fiddle a little more. Mark. From T.A.Meyer@massey.ac.nz Thu Jul 24 06:06:57 2003 From: T.A.Meyer@massey.ac.nz (Meyer, Tony) Date: Thu, 24 Jul 2003 17:06:57 +1200 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F13027ABCCC@its-xchg4.massey.ac.nz> > > So it's 0.0 < 0.001 that fails. > And specifically because "0.001" is being treated as exactly > 0. Yes. Changing the print to: print 0.0, 0.001, 0.0 < 0.001, 0.0 =3D=3D 0.001, 0.0 > 0.001 gives: 0.0 0.0 False True False In addition, a print of: print 0.0, 0.001, 0.0 < 0.001, 0.0 =3D=3D 0.001, 0.1, 0.01, = 0.0001 gives: 0.0 0.0 False True 0.0 0.0 0.0 > Which locale was in effect? This is starting to get odd . German_Germany.1252 =3DTony Meyer From T.A.Meyer@massey.ac.nz Thu Jul 24 06:13:37 2003 From: T.A.Meyer@massey.ac.nz (Meyer, Tony) Date: Thu, 24 Jul 2003 17:13:37 +1200 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F13027ABCD4@its-xchg4.massey.ac.nz> > I added a print locale.getlocale() directly > before the failing code. As expected, it indicated 'us' -=20 > but then the code started working. FWIW: I'm experiencing something like this too. If I run Tim's damage script (while I have Outlook open, but I'm not sure if that matters) then the code starts working (and, annoyingly, I have to restart to break it again). How 0.1 becomes 0[.0] in German, when the damage script says it should equal 1x10^16, I still don't know. =3DTony Meyer From tim.one@comcast.net Thu Jul 24 06:42:56 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 01:42:56 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F13027ABCD4@its-xchg4.massey.ac.nz> Message-ID: [Meyer, Tony] > ... > How 0.1 becomes 0[.0] in German, when the damage script says it should > equal 1x10^16, I still don't know. The "damage" script is apparently incorrect. I added a sys.muckit() function to my Python, like so (in sysmodule.c): static PyObject * sys_muckit(PyObject *self, PyObject *args) { #include setlocale(LC_NUMERIC, "german"); Py_INCREF(Py_None); return Py_None; } Then >>> import marshal >>> s = marshal.dumps(0.001) >>> s 'f\x050.001' >>> marshal.loads(s) 0.001 >>> import sys >>> sys.muckit() >>> marshal.loads(s) 0.0 >>> So when the marshaled representation of 0.001 is loaded under "german" LC_NUMERIC here, we get back exactly 0.0. I'm not sure why. More, now that I've screwed up the locale: >>> 0.001 0.0 >>> 0.1 0.0 >>> 1.0 1.0 >>> 0.99999999 0.0 >>> 123.456 123.0 >>> 1e20 1e+020 >>> 2.34e20 2.0 >> So the obvious answers are: 1. When LC_NUMERIC is "german", MS C's atof() stops at the first period it sees. 2. Python's emulation of locale-aware atof (function atof in file Lib/locale.py) doesn't correctly emulate the platform C atof() in this case. I don't know why that is (and am waaaaay out of time for today), but the "damage" script used locale.atof(), so drew wrong conclusions about MS locale reality. From drifty@alum.berkeley.edu Thu Jul 24 07:15:37 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Wed, 23 Jul 2003 23:15:37 -0700 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: References: Message-ID: <3F1F7989.9040504@ocf.berkeley.edu> Tim Peters wrote: > [Brett C.] > >>Tim (or someone else who can replicate the problem), can you give the >>attached patch a try? This should fix the problem. There are new >>tests on top of a proposed fix. If this doesn't solve it then I am >>giving up on getting the caching to work for this release. > > > Sorry, no joy! OK, then I am ripping out the caching mechanism and will have it committed by midnight PT. -Brett From T.A.Meyer@massey.ac.nz Thu Jul 24 07:17:56 2003 From: T.A.Meyer@massey.ac.nz (Meyer, Tony) Date: Thu, 24 Jul 2003 18:17:56 +1200 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F13027ABCEB@its-xchg4.massey.ac.nz> > So when the marshalled representation of 0.001 is loaded under > "german" LC_NUMERIC here, we get back exactly 0.0. I'm not=20 > sure why. When I call "marshal.dumps(0.1)" from AsyncDialog (or anywhere in the Outlook code) I get "f\x030.0", which fits with what you have. > So the obvious answers are: (Glad you posted this - I was wading through the progress of marshalling (PyOS_snprintf etc) and getting rapidly lost). > 1. When LC_NUMERIC is "german", MS C's atof() stops at the first > period it sees. This is the case: """ #include #include #include int main() { float f; setlocale(LC_NUMERIC, "german"); f =3D atof("0.1"); printf("%f\n", f); } """ Gives me with gcc version 3.2 20020927 (prerelease): 0.100000 Gives me with Microsoft C++ Builder (I don't have Visual C++ handy, but I suppose it would be the same): 0,00000 The help file for Builder does say that this is the correct behaviour - it will stop when it finds an unrecognised character - here '.' is unrecognised (because we are in German), so it stops. Does this then mean that this is a Python bug? Or because Python tells us not to change the c locale and we (Outlook) are, it's our fault/problem? Presumably what we'll have to do for a solution is just what Mark is doing now - find the correct place to put a call that (re)sets the c locale to English. =3DTony Meyer From mwh@python.net Thu Jul 24 10:06:08 2003 From: mwh@python.net (Michael Hudson) Date: Thu, 24 Jul 2003 10:06:08 +0100 Subject: [Python-Dev] New branch for r23c2 work In-Reply-To: <03Jul23.145838pdt."58611"@synergy1.parc.xerox.com> (Bill Janssen's message of "Wed, 23 Jul 2003 14:58:26 PDT") References: <03Jul23.145838pdt."58611"@synergy1.parc.xerox.com> Message-ID: <2my8yol2f3.fsf@starship.python.net> Bill Janssen writes: >> 1) It would be nice to find out what lookupd is up to during the loop. >> I couldn't find out how to get it to tell me (for one thing, the >> lookupd(8) manpage seems to be very out of date wrt. locating >> config info). >> >> 2) One obvious difference between the slow Python program and the fast >> C program is that Python has calls to bind() in between the calls >> to getaddrinfo()... maybe this (or something else) causes lookupd >> to toss its cache for some reason? > > I'm sure Jack has better data than this, but NetInfo can be the source > of much delay, on 10.2.x, because it runs old and rather poorly > written "plugins" to gather data to resolve address info. The > solution appears to be: make sure that your local NetInfo DB doesn't > have a "locations" key, and that you have enabled "BSD Configuration > Files", and disabled "NetInfo", using the "Directory Access" app. > This can speed up address info lookups by two orders of magnitude. Already tried that (should have said). No difference. Cheers, mwh -- Good? Bad? Strap him into the IETF-approved witch-dunking apparatus immediately! -- NTK now, 21/07/2000 From fdrake@acm.org Thu Jul 24 12:46:43 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 24 Jul 2003 07:46:43 -0400 Subject: [Python-Dev] Doc/ tree on trunk closed Message-ID: <16159.50979.38979.687400@grendel.zope.com> I'm closing the Doc/ tree on the trunk until Python 2.4 final has been released. Not even typo corrections should go in at this point. Thanks! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From cben@techunix.technion.ac.il Thu Jul 24 12:53:54 2003 From: cben@techunix.technion.ac.il (Beni Cherniavsky) Date: Thu, 24 Jul 2003 14:53:54 +0300 (IDT) Subject: [Python-Dev] Re: [Doc-SIG] Doc/ tree on trunk closed In-Reply-To: <16159.50979.38979.687400@grendel.zope.com> References: <16159.50979.38979.687400@grendel.zope.com> Message-ID: Fred L. Drake, Jr. wrote on 2003-07-24: > > I'm closing the Doc/ tree on the trunk until Python 2.4 final has been > released. Not even typo corrections should go in at this point. > s/2.4/2.3/, right? It's a meta-typo ... -- Beni Cherniavsky From fdrake@acm.org Thu Jul 24 13:00:59 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 24 Jul 2003 08:00:59 -0400 Subject: [Python-Dev] Re: [Doc-SIG] Doc/ tree on trunk closed In-Reply-To: References: <16159.50979.38979.687400@grendel.zope.com> Message-ID: <16159.51835.108668.704443@grendel.zope.com> Beni Cherniavsky writes: > s/2.4/2.3/, right? It's a meta-typo ... Actually, really closing it until 2.4 is out would certainly encourage stability from one version to the next... and make it easier to complete 2.4! But yeah, that was a typo. ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From barry@python.org Thu Jul 24 13:09:26 2003 From: barry@python.org (Barry Warsaw) Date: 24 Jul 2003 08:09:26 -0400 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: <3F1F7989.9040504@ocf.berkeley.edu> References: <3F1F7989.9040504@ocf.berkeley.edu> Message-ID: <1059048565.11764.45.camel@anthem> On Thu, 2003-07-24 at 02:15, Brett C. wrote: > OK, then I am ripping out the caching mechanism and will have it > committed by midnight PT. Did you update the NEWS file? -Barry From pinard@iro.umontreal.ca Thu Jul 24 14:22:14 2003 From: pinard@iro.umontreal.ca (Francois Pinard) Date: 24 Jul 2003 09:22:14 -0400 Subject: [Python-Dev] Re: Doc/ tree on trunk closed In-Reply-To: <16159.50979.38979.687400@grendel.zope.com> References: <16159.50979.38979.687400@grendel.zope.com> Message-ID: [Fred L. Drake, Jr.] > I'm closing the Doc/ tree on the trunk until Python 2.4 final has been > released. Not even typo corrections should go in at this point. Beware, beware! `2.4' might be a typo for `2.3'. It would be pretty sad for all of us if you were standing by _that_ typo! :-) -- François Pinard http://www.iro.umontreal.ca/~pinard From tim.one@comcast.net Thu Jul 24 16:20:17 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 11:20:17 -0400 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: <3F1EF18F.2050007@ocf.berkeley.edu> Message-ID: [Brett C.] > OK, then I am ripping out the caching mechanism and will have it > committed by midnight PT. It was a mistake to check this in without confirming first that it actually cured the problem. In fact, the same failure still occurs when test_logging's restoration of locale is removed: C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime test_logging test_time test_strptime test_logging test_time test test_time failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_time.py", line 49, in test_strptime self.fail('conversion specifier: %r failed.' % format) File "C:\Code\python\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: conversion specifier: ' %c' failed. 2 tests OK. 1 test failed: test_time The other failure mode has gone away (switching the order of the first two tests), though: C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_logging test_strptime test_time test_logging test_strptime test_time All 3 tests OK. There's no more time for this, so anything more should wait for 2.3.1. From tim.one@comcast.net Thu Jul 24 19:53:32 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 14:53:32 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F13027ABCEB@its-xchg4.massey.ac.nz> Message-ID: [Tony Meyer] > ... > (Glad you posted this - I was wading through the progress of > marshalling (PyOS_snprintf etc) and getting rapidly lost). It's the unmarshalling code that's relevant -- that just passes a string to atof(). >> 1. When LC_NUMERIC is "german", MS C's atof() stops at the first >> period it sees. > This is the case: > """ > #include > #include > #include > > int main() > { > float f; > setlocale(LC_NUMERIC, "german"); > f = atof("0.1"); > printf("%f\n", f); > } > """ > > Gives me with gcc version 3.2 20020927 (prerelease): > 0.100000 It's possible that glibc doesn't recognize "german" as a legitimate locale name (so that the setlocale() call had no effect). > Gives me with Microsoft C++ Builder (I don't have Visual C++ handy, > but I suppose it would be the same): > 0,00000 > > The help file for Builder does say that this is the correct behaviour > - it will stop when it finds an unrecognised character - here '.' is > unrecognised (because we are in German), so it stops. atof does have to stop at the first unrecognized character, but atof is locale-dependent, so which characters are and aren't recognized depends on the locale. After I set locale to "german" on Win2K: >>> import locale >>> locale.setlocale(locale.LC_NUMERIC, "german") 'German_Germany.1252' MS tells me that the decimal_point character is ',' and the thousands_sep character is '.': >>> import pprint >>> pprint.pprint(locale.localeconv()) {'currency_symbol': '', 'decimal_point': ',', HERE 'frac_digits': 127, 'grouping': [3, 0], 'int_curr_symbol': '', 'int_frac_digits': 127, 'mon_decimal_point': '', 'mon_grouping': [], 'mon_thousands_sep': '', 'n_cs_precedes': 127, 'n_sep_by_space': 127, 'n_sign_posn': 127, 'negative_sign': '', 'p_cs_precedes': 127, 'p_sep_by_space': 127, 'p_sign_posn': 127, 'positive_sign': '', 'thousands_sep': '.'} AND HERE >>> Python believes that the locale-specified thousands_sep character should be ignored, and that's what locale.atof() does. It may well be a bug in MS's atof() that it doesn't ignore the current thousands_sep character -- I don't have time now to look up the rules in the C standard, and it doesn't matter to spambayes either way (whether we load .001 as 0.0 as 1.0 is a disaster either way). > Does this then mean that this is a Python bug? That Microsoft's atof() doesn't ignore the thousands_sep character is certainly not Pyton's bug . > Or because Python tells us not to change the c locale and we (Outlook) > are, it's our fault/problem? The way we're using Python with Outlook doesn't meet the documented requirements for using Python, so for now everything that goes wrong here is our problem. It would be better if Python didn't use locale-dependent string<->float conversions internally, but that's just not the case (yet). > Presumably what we'll have to do for a solution is just what Mark is > doing now - find the correct place to put a call that (re)sets the c > locale to English. Python requires that the (true -- from the C library's POV) LC_NUMERIC category be "C" locale. That isn't English (although it looks a lot like it to Germans ), and we don't care about any category other than LC_NUMERIC here. From barry@python.org Thu Jul 24 20:05:35 2003 From: barry@python.org (Barry Warsaw) Date: 24 Jul 2003 15:05:35 -0400 Subject: [Python-Dev] Cutting the 2.3c2 tonight 8pm EDT Message-ID: <1059073534.30958.62.camel@yyz> Just a reminder that I'm going to be cutting the 2.3c2 release tonight. I'm shooting for starting at 8pm EDT, but that partly depends on family obligations. Tim of course will be working on the Windows installer, and I believe Fred's all done with the docs. Still, please consider the tree frozen until further notice. I'll be on irc #python-dev when I get home so please email or irc me if there are any last minute fixes needed. -Barry From skip@pobox.com Thu Jul 24 20:50:15 2003 From: skip@pobox.com (Skip Montanaro) Date: Thu, 24 Jul 2003 14:50:15 -0500 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: References: <1ED4ECF91CDED24C8D012BCF2B034F13027ABCEB@its-xchg4.massey.ac.nz> Message-ID: <16160.14455.351819.187013@montanaro.dyndns.org> Jeez, this locale crap makes Unicode look positively delightful... The SB Windows triumvirate (Mark, Tim, Tony) seem to have narrowed down the problem quite a bit. Is there some way to worm around it? I take it with the unmarshalling problem it's not sufficient to specify floating point values without decimal points (e.g., 0.12 == 1e-1+2e-2). Is the proposed early specification of a locale in the config file sufficient to make things work? A foreign user of the nascent CSV module beat us up a bit during development about not supporting different locales (I guess in Brazil the default separator is a semicolon, which makes sense if your decimal "point" is a comma). Thank God we ignored him! ;-) Skip From drifty@alum.berkeley.edu Thu Jul 24 21:11:13 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Thu, 24 Jul 2003 13:11:13 -0700 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: References: Message-ID: <3F203D61.5060104@ocf.berkeley.edu> Tim Peters wrote: > [Brett C.] > >>OK, then I am ripping out the caching mechanism and will have it >>committed by midnight PT. > > > It was a mistake to check this in without confirming first that it actually > cured the problem. In fact, the same failure still occurs when > test_logging's restoration of locale is removed: > Yes, it was a mistake on my part. This was an instance of me becoming very frustrated with myself and just wanting to get this thing solved and stop being the last nagging issue for this release. Sorry to everyone (and especially the plutocratic release team of Tim and Barry) for causing all of this grief. > > There's no more time for this, so anything more should wait for 2.3.1. > Well, I think I found the actual problem. Guess what the TimeRE had as its parameter list for __init__ : ``locale_time = LocaleTime()`` . Aaaaaahhhhhh!!!!!! I can't believe I didn't spot that sooner! The damn caching was probably working but every instance was using the default value that is created at module initialization instead of recreating it on every instantiation of TimeRE. Barry OK'ed fixing this and I am still going to leave the caching out. I need to really go over this module and work on it with my new Dutch knowledge of Python for 2.4 to get rid of these nagging newbie mistakes that I initially made in this module. -Brett From tim.one@comcast.net Thu Jul 24 21:37:16 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 16:37:16 -0400 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: <3F203D61.5060104@ocf.berkeley.edu> Message-ID: [Tim "Hairy Thunderer" Peters] >> It was a mistake to check this in without confirming first that it >> actually cured the problem. In fact, the same failure still occurs >> when test_logging's restoration of locale is removed: [Brett C.] > Yes, it was a mistake on my part. This was an instance of me becoming > very frustrated with myself and just wanting to get this thing solved > and stop being the last nagging issue for this release. Sorry to > everyone (and especially the plutocratic release team of Tim and > Barry) for causing all of this grief. OK, that's enough groveling -- thanks! Not all mistakes are catastrophes, and this one was pretty minor. > ... > Well, I think I found the actual problem. Guess what the TimeRE had > as its parameter list for __init__ : ``locale_time = LocaleTime()`` . > Aaaaaahhhhhh!!!!!! I can't believe I didn't spot that sooner! The > damn caching was probably working but every instance was using the > default value that is created at module initialization instead of > recreating it on every instantiation of TimeRE. Ah. As most people suspected, then, it was really Guido's fault! Default arguments should only be used as low-level speed hacks to avoid lookups in the builtin namespace. > Barry OK'ed fixing this and I am still going to leave the caching out. > I need to really go over this module and work on it with my new Dutch > knowledge of Python for 2.4 to get rid of these nagging newbie > mistakes that I initially made in this module. You did fine, Brett, and I'm glad we've got _strptime.py. Overall, it was almost a win . BTW, I can confirm that the goofy locale-related buglets have gone away now on Win2K. From drifty@alum.berkeley.edu Thu Jul 24 21:49:31 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Thu, 24 Jul 2003 13:49:31 -0700 Subject: [Python-Dev] RE: test_strptime; test_logging; test_time failure In-Reply-To: References: Message-ID: <3F20465B.5020704@ocf.berkeley.edu> Tim Peters wrote: > [Tim "Hairy Thunderer" Peters] > >>>It was a mistake to check this in without confirming first that it >>>actually cured the problem. In fact, the same failure still occurs >>>when test_logging's restoration of locale is removed: > > > [Brett C.] > >>Yes, it was a mistake on my part. This was an instance of me becoming >>very frustrated with myself and just wanting to get this thing solved >>and stop being the last nagging issue for this release. Sorry to >>everyone (and especially the plutocratic release team of Tim and >>Barry) for causing all of this grief. > > > OK, that's enough groveling -- thanks! Not all mistakes are catastrophes, > and this one was pretty minor. > Damn. And I had this poetic apology letter that would have brought everyone to tears. OK, I will stop apologizing for my mistake now. > >>... >>Well, I think I found the actual problem. Guess what the TimeRE had >>as its parameter list for __init__ : ``locale_time = LocaleTime()`` . >>Aaaaaahhhhhh!!!!!! I can't believe I didn't spot that sooner! The >>damn caching was probably working but every instance was using the >>default value that is created at module initialization instead of >>recreating it on every instantiation of TimeRE. > > > Ah. As most people suspected, then, it was really Guido's fault! Default > arguments should only be used as low-level speed hacks to avoid lookups in > the builtin namespace. > I know I have learned my lesson: set initial values to None unless it is a constant type for default parameter values. > >>Barry OK'ed fixing this and I am still going to leave the caching out. >>I need to really go over this module and work on it with my new Dutch >>knowledge of Python for 2.4 to get rid of these nagging newbie >>mistakes that I initially made in this module. > > > You did fine, Brett, and I'm glad we've got _strptime.py. Overall, it was > almost a win . BTW, I can confirm that the goofy locale-related > buglets have gone away now on Win2K. > Damn it. Now I have to get something in that is a complete win. =) Glad to hear it's fixed now. -Brett From T.A.Meyer@massey.ac.nz Thu Jul 24 23:26:25 2003 From: T.A.Meyer@massey.ac.nz (Meyer, Tony) Date: Fri, 25 Jul 2003 10:26:25 +1200 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F13027ABDD8@its-xchg4.massey.ac.nz> [Tim Peters on Freitag, 25. Juli 2003] > > (Glad you posted this - I was wading through the progress of > > marshalling (PyOS_snprintf etc) and getting rapidly lost). > It's the unmarshalling code that's relevant -- that just=20 > passes a string to atof(). So it is :) Amazingly how much clearer things are in the morning. Or after reading your explanation. One of the two ;) > > Gives me with gcc version 3.2 20020927 (prerelease): > > 0.100000 > It's possible that glibc doesn't recognize "german" as a=20 > legitimate locale name (so that the setlocale() call had no effect). Ah yes, should have thought of that. I can't get it to accept anything apart from "C" although mingw does and gives the same result as MS C. > atof does have to stop at the first unrecognized character,=20 > but atof is locale-dependent, so which characters are and aren't=20 > recognized depends on the locale. As you said, the difference is whether the thousands separator is ignored or not. (Trying to atof "1,000" gives me 1.0, just in the regular old C locale, *and* in "en"). So Python's locale.atof is better than C's, because it properly takes the thousands separator into account. Python does behave correctly, too - locale.atof("1,000") gives me an exception ("C"), 1000.0 ("en") and 1.0 ("german"). > it doesn't matter to spambayes > either way (whether we load .001 as 0.0 as 1.0 is a disaster either way). True, although I am finding this interesting and learning something, which is good for me :) > The way we're using Python with Outlook doesn't meet the documented > requirements for using Python, so for now everything that=20 > goes wrong here is our problem. Well, Mark's problem ;) > It would be better if Python didn't use locale-dependent > string<->float conversions internally, but that's just not=20 > the case (yet). Is this likely to become the case? (In 2.4, for example?) > Python requires that the (true -- from the C library's POV) LC_NUMERIC > category be "C" locale. That isn't English (although it looks a lot > like it to Germans ), and we don't care about any category other > than LC_NUMERIC here. My mistake. I should have said "C" and not "English". (It is proving a little difficult (for me, at least) finding a place where the C locale can be put back to "C" so that the plugin works.). =3DTony Meyer From mhammond@skippinet.com.au Thu Jul 24 23:57:01 2003 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 25 Jul 2003 08:57:01 +1000 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: <16160.14455.351819.187013@montanaro.dyndns.org> Message-ID: <020901c35236$e5576f10$f502a8c0@eden> > Jeez, this locale crap makes Unicode look positively delightful... This seems to be coming to a conclusion. Not a completely satisfactory one, but one nonetheless. Short story for the python-dev crew: * Some Windows programs are known to run with the CRT locale set to other than "C" - specifically, set to the locale of the user. * If this happens, the marshal module will load floating point literals incorrectly. * Thus, once this happens, if a .pyc file is imported, the floating point literals in that .pyc are wrong. Confusion reigns. The "best" solution to this probably involves removing Python being dependent on the locale - there is even an existing patch for that. To the SpamBayes specifics: > The SB Windows triumvirate (Mark, Tim, Tony) seem to have > narrowed down the > problem quite a bit. Is there some way to worm around it? I > take it with > the unmarshalling problem it's not sufficient to specify > floating point > values without decimal points (e.g., 0.12 == 1e-1+2e-2). I have a version working for the original bug reporter. While on our machines, we can reproduce the locale being switched at MAPILogon time, my instrumented version also shows that for some people at least, Outlook itself will also change it back some time before delivering UI events to us. Today I hope to produce a less-instrumented version with the fix I intend leaving in, and asking the OP to re-test. We *do* still have the "social" problem of what locale conventions to use for Config files, but that has nothing to do with our tools... Mark. From python@rcn.com Fri Jul 25 03:26:19 2003 From: python@rcn.com (Raymond Hettinger) Date: Thu, 24 Jul 2003 22:26:19 -0400 Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827 References: Message-ID: <003f01c35254$2260b700$b5b9958d@oemcomputer> > + - Removed caching of TimeRE (and thus LocaleTime) in _strptime.py to > + fix a locale related bug in the test suite. Although another patch > + was needed to actually fix the problem, the cache code was not > + restored. FWIW, I would feel safer if the cache code were restored. That code has been around for while and the one defect is known. In contrast, the "ripping it out" touched a lot of code and has not been thoroughly reviewed. Raymond From barry@python.org Fri Jul 25 04:01:05 2003 From: barry@python.org (Barry Warsaw) Date: 24 Jul 2003 23:01:05 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 Message-ID: <1059102065.12996.22.camel@anthem> Python 2.3c2 is the second and last release candidate for Python 2.3. There have been a bunch of bug fixes and memory leak plugs since the first release candidate, but no new features. As described in PEP 283, Python 2.3 final will be released before the end of July 2003. We are planning for Tuesday 29-Jul-2003 if everything looks good. We highly encourage everyone to rigorously test this release candidate. Only critical bug fixes will be allowed from here to the final release, but we want this release to be as stable as possible. Highlights since rc1 include: - It is now possible to import from zipfiles containing additional data bytes before the zip compatible archive. Zipfiles containing a comment at the end are still unsupported. - Fixed leaks in pyexpat and locale, and a long standing bug in the parser module. - The MacOSX build is now built with -mno-fused-madd to fix test_coercion on Panther (OSX 10.3). For more highlights, see http://www.python.org/2.3/highlights.html Other new stuff since Python 2.2: - Many new and improved library modules, e.g. sets, heapq, datetime, textwrap, optparse, logging, bsddb, bz2, tarfile, ossaudiodev, and a new random number generator based on the highly acclaimed Mersenne Twister algorithm (with a period of 2**19937-1!). - New builtin enumerate(): an iterator yielding (index, item) pairs. - Extended slices, e.g. "hello"[::-1] returns "olleh". - Universal newlines mode for reading files (converts \r, \n and \r\n all into \n). - Source code encoding declarations. (PEP 263) - Import from zip files. (PEP 273 and PEP 302) - FutureWarning issued for "unsigned" operations on ints. (PEP 237) - Faster list.sort() is now stable. - Unicode filenames on Windows. - Karatsuba long multiplication (running time O(N**1.58) instead of O(N**2)). To report problems, use the SourceForge bug tracker: http://sourceforge.net/tracker/?group_id=5470&atid=105470 brought-to-you-by-the-letter-'D'-for-drifty-ly y'rs, -Barry From tim.one@comcast.net Fri Jul 25 04:08:34 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 23:08:34 -0400 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <16160.14455.351819.187013@montanaro.dyndns.org> Message-ID: [Skip Montanaro] > Jeez, this locale crap makes Unicode look positively delightful... Yes, it does! locale is what you get when someone complains they like to use ampersands instead commas to separate thousands, and a committee thinks "hey! we've got all these great functions already, so why change them? instead we'll add mounds of hidden global state that affects lots of ancient functions in radical ways!". Make sure it's as hostile to threads as possible, decline to define any standard locale names beyond "C" and the empty string, and decline to define what anything except the "C" locale name means, and you're almost there. The finishing touches come in the function definitions, like this in strtod(): In other than the "C" locale, additional locale-specific subject sequence forms may be accepted. What those may be aren't constrained in any way, of course. locale can be cool in a monolithic, single-threaded, one-platform program, provided the platform C made up rules you can live with for the locales you care about. It's more of an API framework than a solution, and portable programs really can't use it except via forcing locale back to "C" every chance they get . > The SB Windows triumvirate (Mark, Tim, Tony) seem to have narrowed > down the problem quite a bit. Is there some way to worm around it? > I take it with the unmarshalling problem it's not sufficient to > specify floating point values without decimal points (e.g., 0.12 == > 1e-1+2e-2). When true division becomes the default, things like 12/100 should work reliably regardless of locale -- i.e., don't use any float literals, and you can't get screwed by locale float-literal quirks. Today, absurd spellings like float(12)/100 can accomplish the same. Changing Python is a better solution. The rule that an embedded Python requires that LC_NUMERIC be "C" isn't livable -- embedded Python is a fly trying to stare down an elephant, in Outlook's case. I dragged python-dev into this to illustrate that it's a very real problem in a very popular kick-ass Python app. Note that this same problem was discussed in more abstract terms by others here within the last few weeks, and I hope that making it more concrete helps get the point across. The float-literal-in-.pyc problem could be addressed in several ways. Binary pickles, and the struct module, use a portable binary float format that isn't subject to locale quirks. I think marshal should be changed to use that too, by adding an additional marshal float format (so old marshals would continue to be readable, but new marshals may not be readable under older Pythons). Note that text-mode pickles of floats are vulnerable to locale nightmares too. > Is the proposed early specification of a locale in the config file > sufficient to make things work? I doubt it, as Outlook can switch locale any time it feels like it. We can't control that. I think we should set a line-tracing hook, and force locale back to "C" on every callback . > A foreign user of the nascent CSV module beat us up a bit during > development about not supporting different locales (I guess in Brazil > the default separator is a semicolon, which makes sense if your > decimal "point" is a comma). Thank God we ignored him! ;-) Ya, foreigners are no damn good . From barry@python.org Fri Jul 25 04:09:53 2003 From: barry@python.org (Barry Warsaw) Date: 24 Jul 2003 23:09:53 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <1059102065.12996.22.camel@anthem> References: <1059102065.12996.22.camel@anthem> Message-ID: <1059102593.12996.26.camel@anthem> On Thu, 2003-07-24 at 23:01, Barry Warsaw wrote: > As described in PEP 283, > Python 2.3 final will be released before the end of July 2003. We are > planning for Tuesday 29-Jul-2003 if everything looks good. Please note! I've updated PEP 283 to reflect my hope that we can put out 2.3 final next Tuesday the 29th. We don't want to cut it so close that we get screwed if SF takes a holiday on the 31st. I think we're very very close (discussions about the timeRE cache later), so I hope we can hit this date. If anybody feels otherwise, now's the time to bark loudly! -Barry From aahz@pythoncraft.com Fri Jul 25 04:14:46 2003 From: aahz@pythoncraft.com (Aahz) Date: Thu, 24 Jul 2003 23:14:46 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <1059102593.12996.26.camel@anthem> References: <1059102065.12996.22.camel@anthem> <1059102593.12996.26.camel@anthem> Message-ID: <20030725031445.GA9648@panix.com> On Thu, Jul 24, 2003, Barry Warsaw wrote: > On Thu, 2003-07-24 at 23:01, Barry Warsaw wrote: >> >> As described in PEP 283, >> Python 2.3 final will be released before the end of July 2003. We are >> planning for Tuesday 29-Jul-2003 if everything looks good. > > Please note! I've updated PEP 283 to reflect my hope that we can put > out 2.3 final next Tuesday the 29th. We don't want to cut it so close > that we get screwed if SF takes a holiday on the 31st. I think we're > very very close (discussions about the timeRE cache later), so I hope we > can hit this date. If anybody feels otherwise, now's the time to bark > loudly! This is fine with me, but I'd like the official docs to still state that the release takes place on 7/31. This will facilitate coordiantion of the press releases, I think. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From barry@python.org Fri Jul 25 04:22:48 2003 From: barry@python.org (Barry Warsaw) Date: 24 Jul 2003 23:22:48 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <20030725031445.GA9648@panix.com> References: <1059102065.12996.22.camel@anthem> <1059102593.12996.26.camel@anthem> <20030725031445.GA9648@panix.com> Message-ID: <1059103367.12996.33.camel@anthem> On Thu, 2003-07-24 at 23:14, Aahz wrote: > This is fine with me, but I'd like the official docs to still state that > the release takes place on 7/31. This will facilitate coordiantion of > the press releases, I think. Here's another option: we do absolutely everything we need to do that involves SF on the 29th. This means freezing, tagging, and branching the tree, building the tarballs and exes, etc. But we don't send the announcement or twiddle the python.org home page until the 31st. That way, it's official on the 31st, but everyone who needs it (i.e. Apple) can have it by the 29th. Thoughts? -Barry From tim.one@comcast.net Fri Jul 25 04:25:25 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 23:25:25 -0400 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F13027ABDD8@its-xchg4.massey.ac.nz> Message-ID: [Tim] >> It would be better if Python didn't use locale-dependent >> string<->float conversions internally, but that's just not >> the case (yet). [Tony Meyer] > Is this likely to become the case? (In 2.4, for example?) I think so, and maybe before that. Not in 2.3 final, but maybe in 2.3.1 -- numeric locale problems can be catastrophic to Python programmers, so I'm comfortable arguing the case for calling it a bugfix. Whether it happens depends on who's willing and able to do the work, of course. There's a patch pending on a Python tracker to do it, but that uses a pile of code borrowed from glibc, and that's got problems of its own. From tim.one@comcast.net Fri Jul 25 04:25:26 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 23:25:26 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <20030725031445.GA9648@panix.com> Message-ID: [Barry] >> Please note! I've updated PEP 283 to reflect my hope that we can put >> out 2.3 final next Tuesday the 29th. [Aahz] > This is fine with me, but I'd like the official docs to still state > that the release takes place on 7/31. This will facilitate > coordiantion of the press releases, I think. What's the logic here? Is the general algorithm that if we do a release on date D, the official docs should say it was released on date D+2? Or that the official docs should say that a release occurred on the last day of the month at or following the actual release date? The next Thursday after the actual release? It can't be that you want to see the first prime date at or after the actual release, unless there's been an arithmetic error . From aahz@pythoncraft.com Fri Jul 25 04:26:00 2003 From: aahz@pythoncraft.com (Aahz) Date: Thu, 24 Jul 2003 23:26:00 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <1059103367.12996.33.camel@anthem> References: <1059102065.12996.22.camel@anthem> <1059102593.12996.26.camel@anthem> <20030725031445.GA9648@panix.com> <1059103367.12996.33.camel@anthem> Message-ID: <20030725032600.GA10638@panix.com> On Thu, Jul 24, 2003, Barry Warsaw wrote: > On Thu, 2003-07-24 at 23:14, Aahz wrote: >> >> This is fine with me, but I'd like the official docs to still state that >> the release takes place on 7/31. This will facilitate coordiantion of >> the press releases, I think. > > Here's another option: we do absolutely everything we need to do that > involves SF on the 29th. This means freezing, tagging, and branching > the tree, building the tarballs and exes, etc. > > But we don't send the announcement or twiddle the python.org home page > until the 31st. That way, it's official on the 31st, but everyone who > needs it (i.e. Apple) can have it by the 29th. > > Thoughts? Works for me! (And was one variation I was too terse to list myself.) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From tim.one@comcast.net Fri Jul 25 04:27:00 2003 From: tim.one@comcast.net (Tim Peters) Date: Thu, 24 Jul 2003 23:27:00 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <1059103367.12996.33.camel@anthem> Message-ID: [Barry] > Here's another option: we do absolutely everything we need to do that > involves SF on the 29th. This means freezing, tagging, and branching > the tree, building the tarballs and exes, etc. > > But we don't send the announcement or twiddle the python.org home page > until the 31st. Why would we possibly want to do that? From aahz@pythoncraft.com Fri Jul 25 04:31:54 2003 From: aahz@pythoncraft.com (Aahz) Date: Thu, 24 Jul 2003 23:31:54 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: References: <20030725031445.GA9648@panix.com> Message-ID: <20030725033154.GB10638@panix.com> On Thu, Jul 24, 2003, Tim Peters wrote: > [Aahz] >> [Barry] >>> >>> Please note! I've updated PEP 283 to reflect my hope that we can put >>> out 2.3 final next Tuesday the 29th. >> >> This is fine with me, but I'd like the official docs to still state >> that the release takes place on 7/31. This will facilitate >> coordiantion of the press releases, I think. > > What's the logic here? Is the general algorithm that if we do a > release on date D, the official docs should say it was released > on date D+2? Or that the official docs should say that a release > occurred on the last day of the month at or following the actual > release date? The next Thursday after the actual release? It can't > be that you want to see the first prime date at or after the actual > release, unless there's been an arithmetic error . No, it's that there are press releases that are dependent on this release, particularly the one involving Apple. I think that hard-coding the press releases *now* offers advantages for coordinating the actual release process, so that we don't need to worry about updating them. What happens if the actual release slips just one day? In the past, our pattern has been that the press release follows the product release, but that's not happening this time. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From barry@python.org Fri Jul 25 04:35:48 2003 From: barry@python.org (Barry Warsaw) Date: 24 Jul 2003 23:35:48 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <20030725033154.GB10638@panix.com> References: <20030725031445.GA9648@panix.com> <20030725033154.GB10638@panix.com> Message-ID: <1059104148.12996.43.camel@anthem> On Thu, 2003-07-24 at 23:31, Aahz wrote: > No, it's that there are press releases that are dependent on this > release, particularly the one involving Apple. I think that hard-coding > the press releases *now* offers advantages for coordinating the actual > release process, so that we don't need to worry about updating them. > What happens if the actual release slips just one day? > > In the past, our pattern has been that the press release follows the > product release, but that's not happening this time. OTOH, I'm going to let our press release partners know that 29-Jul-2003 is the release date -- if no one objects before I wake up in the morning. I think the press releases can be updated here easily. -Barry From kbk@shore.net Fri Jul 25 04:51:14 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Thu, 24 Jul 2003 23:51:14 -0400 Subject: [Python-Dev] Vacation and possibly a new bug In-Reply-To: <2B29460B-BCCC-11D7-AF09-000A95A06FC6@shangri-la.dropbear.id.au> (Stuart Bishop's message of "Wed, 23 Jul 2003 15:11:51 +1000") References: <2B29460B-BCCC-11D7-AF09-000A95A06FC6@shangri-la.dropbear.id.au> Message-ID: Stuart Bishop writes: > On Wednesday, July 23, 2003, at 08:42 AM, Neal Norwitz wrote: > >> >> The patch below fixes test_time on RedHat 6.2/Alpha. Since I don't >> understand the code, I haven't the slighest clue if the patch is >> correct or not. But I do know what (365 * 24 * 3600) is. :-) >> I don't know what ((365 * 24 + 6) * 3600) is supposed to represent. >> 1 year + 6 hours in seconds. What's that? >> >> I've copied Stuart Bishop on this message as I believe he wrote >> all this code. The patches in http://python.org/sf/762934 haven't >> made the tests pass. > > I'm following this thread (from an out of sync timezone). [...] > bcannon's tzset_AEST.diff patch can be improved (it doesn't check if the > system believes the whole year is entirely in DST). It also needs to > do the following: > > time_t midyear = xmas - (365 * 24 * 3600 / 2); > > if (strcmp(localtime(&midyear)->tm_zone, "AEST")) > exit(1); > > I'll make a patch when anon-cvs gets back up, unless someone beats > me to it. Further testing on RH Linux 6.2 and a revised patch: [kbk@float ~/PYSRC]$ ./python Python 2.3c2 (#15, Jul 24 2003, 11:17:16) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> from os import environ >>> victoria = 'AEST-10AEDT-11,M10.5.0,M3.5.0' >>> environ['TZ'] = victoria >>> time.tzset() >>> time.tzname ('AEST', 'AEST') >>> =========================================================== Hm!! Try a couple of things to try to see what's going on: =========================================================== >>> victoria2 = 'AEST-10AEDT-11' >>> environ['TZ'] = victoria2 >>> time.tzset() >>> time.tzname ('AEST', 'AEDT') >>> >>> # try reversing the changeover ... >>> victoria3 = 'AEST-10AEDT-11,M3.5.0,M10.5.0' >>> environ['TZ'] = victoria3 >>> time.tzset() >>> time.tzname ('AEST', 'AEDT') =================================== ok, debug inittimezone: =================================== Breakpoint 1, inittimezone (m=0x4014053c) at /home/kbk/PYTHON/python/dist/src/Modules/timemodule.c:608 608 t = (time((time_t *)0) / YEAR) * YEAR; (gdb) n 609 p = localtime(&t); (gdb) p asctime(localtime(&t)) $14 = 0x4013be00 "Wed Jan 1 16:00:00 2003\n" (gdb) p localtime(&t)->tm_zone $19 = 0x8162b78 "AEST" [std time on Jan 1!! ...back up a day or so....] (gdb) p t = t - 84000 $20 = 1041316800 (gdb) p localtime(&t)->tm_zone $21 = 0x8162b90 "AEDT" (gdb) p asctime(localtime(&t)) $22 = 0x4013be00 "Tue Dec 31 17:40:00 2002\n" (gdb) ============================================================= so Linux6.2 thinks AEDT switches to AEST in Jan, and six months forward is still AEST. xmas2002 is AEDT so config test passes but timemodule uses Jan 1 and flubs when setting tzname. Need to do the config test later than xmas. ============================================================== ****** Apply Patch SF 762934 configure.in.patch.kbk ******* ============================================= autoreconf && ./configure && make clean && make OPT=-g ============================================== extract from configure log: .... checking for broken nice()... yes checking for working tzset()... no checking for tv_nsec in struct stat... no checking whether mvwdelch is an expression... yes .... ============================================= [kbk@float ~/PYSRC]$ ./python Python 2.3c2 (#18, Jul 24 2003, 22:40:09) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from test import test_time >>> test_time.test_main() test_asctime (test.test_time.TimeTestCase) ... ok test_clock (test.test_time.TimeTestCase) ... ok test_conversions (test.test_time.TimeTestCase) ... ok test_data_attributes (test.test_time.TimeTestCase) ... ok test_sleep (test.test_time.TimeTestCase) ... ok test_strftime (test.test_time.TimeTestCase) ... ok test_strptime (test.test_time.TimeTestCase) ... ok test_tzset (test.test_time.TimeTestCase) ... ok ---------------------------------------------------------------------- Ran 8 tests in 2.523s OK >>> ================================================ make test: ================================================ .... .... test_zlib 227 tests OK. 28 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_largefile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. [kbk@float ~/PYSRC]$ -- KBK From T.A.Meyer@massey.ac.nz Fri Jul 25 05:13:59 2003 From: T.A.Meyer@massey.ac.nz (Meyer, Tony) Date: Fri, 25 Jul 2003 16:13:59 +1200 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) Message-ID: <1ED4ECF91CDED24C8D012BCF2B034F130290AA0C@its-xchg4.massey.ac.nz> > While on our machines, we can reproduce the locale being=20 > switched at MAPILogon time, my instrumented version also=20 > shows that for some people at least, Outlook itself will also=20 > change it back some time before delivering UI events to us. I think my .py files now have more print statements than they do other code, and I still can't figure what causes the change (apart from when we start the plugin and the logonex call). If I open Outlook (starts in Outlook Today), wait for it to do a send & receive (with nothing received) and then close it, the locale is changed somewhere apart from these two known places, but I can't find the place! It's somewhere between the end of OnStartupComplete() and the start of OnClose(). (Very little gets called, since there isn't any training, or changing of folders, etc). Is it possible that Outlook simply changes the crt locale at some point completely unrelated to spambayes activity? This would explain why I can't narrow down a call that does it. If that's the case, then the only solution is a band-aid one, isn't it - where we fix the locale each time, before we do anything with floats. (And avoid floats by using float(1)/10 and so forth). > Today I hope to produce a less-instrumented version with the=20 > fix I intend leaving in, and asking the OP to re-test. FWIW, here's what I get: """ ################################################## addin import IS a hijacker!!! The crt locale is German_Germany.1252 The locale was repaired addin onconnection is not a hijacker. Known hijacker mapi logon did hijack The crt locale is German_Germany.1252 The locale was repaired Loaded bayes database from 'C:\Documents and Settings\tameyer.MASSEY\Application Data\SpamBayes\default_bayes_database.db' Loaded message database from 'C:\Documents and Settings\tameyer.MASSEY\Application Data\SpamBayes\default_message_database.db' Bayes database initialized with 1754 spam and 269 good messages SpamBayes Outlook Addin (beta), version 0.4 (July 2003) starting (with engine SpamBayes Beta2, version 0.2 (July 2003)) on Windows 5.1.2600 (Service Pack 1) using Python 2.3c1 (#44, Jul 21 2003, 09:21:38) [MSC v.1200 32 bit (Intel)] SpamBayes: Watching for new messages in folder Inbox SpamBayes: Watching for new messages in folder Spam Processing 0 missed spam in folder 'Inbox' took 71.0777ms """ =3DTony Meyer From tim.one@comcast.net Fri Jul 25 05:57:21 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 25 Jul 2003 00:57:21 -0400 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: <1ED4ECF91CDED24C8D012BCF2B034F130290AA0C@its-xchg4.massey.ac.nz> Message-ID: [Tony Meyer] > ... > Is it possible that Outlook simply changes the crt locale at some > point completely unrelated to spambayes activity? Oh yes! Outlook is usually running 16 (or more) threads, and one of the joys of locale is that it's global (shared) state. Any thread can change it at any time, and the change is seen by all threads. > This would explain why I can't narrow down a call that does it. If > that's the case, then the only solution is a band-aid one, isn't it - > where we fix the locale each time, before we do anything with floats. It really doesn't matter when we *use* floats. What matters is the locale setting at the time Python's (un)marshal code calls C's atof() when it's building code objects from a .pyc file. Building a code object is a once-per-life-of-the-program-run thing, and happens at import time. Once the code object is constructed, the locale setting becomes irrelevant. Really understanding this requires learning more about Python internals than anyone (other than a Python implementer) should ever need to know. Here's a clue: >>> def f(): ... return 1.23 + 4.56 ... >>> f.func_code.co_consts (None, 1.23, 4.5599999999999996) >>> A code object's co_consts attribute is a tuple of all objects that correspond to literals in the source code (the None there is from the implicit "return None" at the end of every function). Part of what unmarshal does is to convert a string of bytes in the .pyc file into a code object's co_consts tuple. That's an immutable thing (like all tuples are), and holds actual Python float (and string, etc) objects. Once those are created, changes to locale can't hurt them -- it's already a done deal. > (And avoid floats by using float(1)/10 and so forth). That rule is really painful to live with. Unfortunately, AFAIK, some thread in Outlook *could* change locale while the thread loading a Python .pyc file is in the middle of doing its stuff. Heh. We could start our modules with something like if 1.23 != float(123)/100: do sick magic to force a reload of the module Mark should love that one . From martin@v.loewis.de Fri Jul 25 06:25:48 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 25 Jul 2003 07:25:48 +0200 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: <020901c35236$e5576f10$f502a8c0@eden> References: <020901c35236$e5576f10$f502a8c0@eden> Message-ID: "Mark Hammond" writes: > The "best" solution to this probably involves removing Python being > dependent on the locale - there is even an existing patch for that. While the feature is desirable, I don't like the patch it all. It copies the relevant code of Gnome glib, and I a) doubt it works on all systems we care about, and b) is too much code for us to maintain, and c) introduces yet another license (although the true authors of that code would be willing to relicense it) It would be better if system functions could be found for a locale-agnostic atof/strtod on all systems. For example, glibc has a strtod_l function, which expects a locale_t in addition to the char*. It would be good if something similar was discovered for VC. Using undocumented or straight Win32 API functions would be fine. Unfortunately, the "true" source of atof (i.e. from conv.obj) is not shipped with MSVC :-( Regards, Martin From drifty@alum.berkeley.edu Fri Jul 25 08:00:18 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Fri, 25 Jul 2003 00:00:18 -0700 Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827 In-Reply-To: <003f01c35254$2260b700$b5b9958d@oemcomputer> References: <003f01c35254$2260b700$b5b9958d@oemcomputer> Message-ID: <3F20D582.9020102@ocf.berkeley.edu> Raymond Hettinger wrote: >>+ - Removed caching of TimeRE (and thus LocaleTime) in _strptime.py to >>+ fix a locale related bug in the test suite. Although another patch >>+ was needed to actually fix the problem, the cache code was not >>+ restored. > > > FWIW, I would feel safer if the cache code were restored. > That code has been around for while and the one defect > is known. In contrast, the "ripping it out" touched a lot > of code and has not been thoroughly reviewed. > One argument for not putting it back: I realized that it is not totally thread-safe because of the laziness of the figuring out the locale info (although switching the locale while running threads you are asking for trouble). While there is no specific thread-safety claims, I would rather work the code to make it thread-safe before re-introducing caching. But if people feel otherwise it is easy to put back in. I am abstaining from making any form of a vote on this since to not have a warped bias towards one side. -Brett From tim.one@comcast.net Fri Jul 25 08:13:46 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 25 Jul 2003 03:13:46 -0400 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: Message-ID: [martin@v.loewis.de] > While the feature is desirable, I don't like the patch it all. It > copies the relevant code of Gnome glib, and I > a) doubt it works on all systems we care about, and > b) is too much code for us to maintain, and > c) introduces yet another license (although the true authors > of that code would be willing to relicense it) OTOH, even assuming "C" locale, Python's float<->string story varies across platforms anyway, due to different C libraries treating things like infinities, NaNs, signed zeroes, and the number of digits displayed in an exponent differently. This also has bad consequences, although one-platform programmers usually don't notice them (Windows programmers do more than most, because MS's C library can't read back the strings it produces for NaNs and infinities -- which Python also produces and can't read back in then). So it's not that the patch is too much code to maintain, it's not enough code to do the whole job <0.9 wink>. > It would be better if system functions could be found for a > locale-agnostic atof/strtod on all systems. For example, glibc > has a strtod_l function, which expects a locale_t in addition > to the char*. Well, a growing pile of funky platform #ifdefs isn't all that attractive either. > It would be good if something similar was discovered for VC. Using > undocumented or straight Win32 API functions would be fine. Only half joking, I expect that anything using the native Win32 API would end up being as big as the glib patch. > Unfortunately, the "true" source of atof (i.e. from conv.obj) is not > shipped with MSVC :-( Would that help us if we could get it? I'm not sure how. I expect the true source is assembler, for easy exploitation of helpful Pentium FPU gimmicks you can't get at reliably from C code. Standard-quality float<->string routines require simulating (by hook or by crook) more precision than the float type has, and access to the Pentium's extended-precision float type can replace pages of convoluted C with a few machine instructions. From python@rcn.com Fri Jul 25 13:11:06 2003 From: python@rcn.com (Raymond Hettinger) Date: Fri, 25 Jul 2003 08:11:06 -0400 Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827 References: <003f01c35254$2260b700$b5b9958d@oemcomputer> <3F20D582.9020102@ocf.berkeley.edu> Message-ID: <003701c352a7$b4db68c0$125ffea9@oemcomputer> > >>+ - Removed caching of TimeRE (and thus LocaleTime) in _strptime.py to > >>+ fix a locale related bug in the test suite. Although another patch > >>+ was needed to actually fix the problem, the cache code was not > >>+ restored. > > > > > > FWIW, I would feel safer if the cache code were restored. > > That code has been around for while and the one defect > > is known. In contrast, the "ripping it out" touched a lot > > of code and has not been thoroughly reviewed. > > > > One argument for not putting it back: I realized that it is not totally > thread-safe because of the laziness of the figuring out the locale info > (although switching the locale while running threads you are asking for > trouble). While there is no specific thread-safety claims, I would > rather work the code to make it thread-safe before re-introducing caching. Besides being too late now, thread safety is another good reason to keep it out. Raymond ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# ################################################################# From jason@tishler.net Fri Jul 25 14:58:51 2003 From: jason@tishler.net (Jason Tishler) Date: Fri, 25 Jul 2003 09:58:51 -0400 Subject: [Python-Dev] Re: RELEASED Python 2.3c2 In-Reply-To: <1059102065.12996.22.camel@anthem> References: <1059102065.12996.22.camel@anthem> Message-ID: <20030725135851.GB1764@tishler.net> On Thu, Jul 24, 2003 at 11:01:05PM -0400, Barry Warsaw wrote: > We highly encourage everyone to rigorously test this release > candidate. Looks good under Cygwin. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From barry@python.org Fri Jul 25 14:58:41 2003 From: barry@python.org (Barry Warsaw) Date: 25 Jul 2003 09:58:41 -0400 Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Misc NEWS,1.826,1.827 In-Reply-To: <3F20D582.9020102@ocf.berkeley.edu> References: <003f01c35254$2260b700$b5b9958d@oemcomputer> <3F20D582.9020102@ocf.berkeley.edu> Message-ID: <1059141520.6783.5.camel@yyz> On Fri, 2003-07-25 at 03:00, Brett C. wrote: > One argument for not putting it back: I realized that it is not totally > thread-safe because of the laziness of the figuring out the locale info > (although switching the locale while running threads you are asking for > trouble). While there is no specific thread-safety claims, I would > rather work the code to make it thread-safe before re-introducing caching. > > But if people feel otherwise it is easy to put back in. I am abstaining > from making any form of a vote on this since to not have a warped bias > towards one side. At this point, the code's probably better off left out than left in. We don't have time for another release candidate, and if Brett's against putting it in, we need to defer to that. -Barry From Scott.Daniels@Acm.Org Fri Jul 25 14:17:50 2003 From: Scott.Daniels@Acm.Org (Scott David Daniels) Date: Fri, 25 Jul 2003 06:17:50 -0700 Subject: [Python-Dev] Re: [spambayes-dev] RE: RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: References: <1ED4ECF91CDED24C8D012BCF2B034F130290AA0C@its-xchg4.massey.ac.nz> Message-ID: I've been seeing a lot of "we'll have to use float(123)/100" messages floating around, and I'd like to point out there is an atof-able form for floating point numbers: 256.7654e-7 = 2567654e-11 def safestr(floatstr): """Return a locale-safe version of C-locale-generated floatstr""" try: decpos = floatstr.index('.') except ValueError: return floatstr try: exppos = floatstr.lower().index('e') except ValueError: ebias = 0 exppos = len(sv) else: ebias = int(floatstr[exppos+1:]) return '%s%se%s' % (floatstr[:decpos], floatstr[decpos+1:exppos], ebias + 1 - exppos + decpos) floating-point-need-not-use-fractional-mantissas-ly yours, -Scott David Daniels From skip@pobox.com Fri Jul 25 16:18:35 2003 From: skip@pobox.com (Skip Montanaro) Date: Fri, 25 Jul 2003 10:18:35 -0500 Subject: [Python-Dev] Re: [spambayes-dev] RE: RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: References: <1ED4ECF91CDED24C8D012BCF2B034F130290AA0C@its-xchg4.massey.ac.nz> Message-ID: <16161.19019.786563.72782@montanaro.dyndns.org> Scott> I've been seeing a lot of "we'll have to use float(123)/100" Scott> messages floating around, and I'd like to point out there is an Scott> atof-able form for floating point numbers: Scott> 256.7654e-7 = 2567654e-11 This isn't a general solution because when that floating point number is marshalled for storage in the .pyc file it will be normalized and contain a decimal point: >>> f = 2567654e-11 >>> f 2.567654e-05 >>> import marshal >>> marshal.dumps(f) 'f\x0c2.567654e-05' Skip From tim.one@comcast.net Fri Jul 25 16:37:50 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 25 Jul 2003 11:37:50 -0400 Subject: [Python-Dev] Re: [spambayes-dev] RE: RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: Message-ID: [Scott David Daniels] > I've been seeing a lot of "we'll have to use float(123)/100" > messages floating around, and I'd like to point out there is an > atof-able form for floating point numbers: > 256.7654e-7 = 2567654e-11 Skip is right that this won't help. At compile time, Python doesn't stuff pieces of the source code into a .pyc file, it builds the float objects and marshals them. Here's temp.py: def example(): return 1e-1 Then: >>> import temp >>> file('temp.pyc', 'rb').read() ';\xf2\r\n\xf1L!?c\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00 @\x00\x00\x00s\r\x00\x00\x00d\x00\x00\x84\x00\x00Z\x00\x00d\x01 \x00S(\x02\x00\x00\x00c\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00 \x00\x00C\x00\x00\x00s\x08\x00\x00\x00d\x01\x00Sd\x00\x00S(\x02 \x00\x00\x00Nf\x130.10000000000000001(\x00\x00\x00\x00(\x00\x00 \x00\x00(\x00\x00\x00\x00(\x00\x00\x00\x00s\x07\x00\x00\x00temp.py s\x07\x00\x00\x00example\x01\x00\x00\x00s\x02\x00\x00\x00\x00 \x01N(\x01\x00\x00\x00s\x07\x00\x00\x00example(\x01\x00\x00\x00 s\x07\x00\x00\x00example(\x00\x00\x00\x00(\x00\x00\x00\x00 s\x07\x00\x00\x00temp.pys\x01\x00\x00\x00?\x01\x00\x00\x00s\x00 \x00\x00\x00' >>> The substring f\x130.10000000000000001 is the marshal typecode for a float, a byte saying the float string is in the next 0x13 = 19 bytes, and then the 19-byte string "0.10000000000000001". The source code's exponential notation didn't survive in the .pyc file. From Scott.Daniels@Acm.Org Fri Jul 25 16:55:33 2003 From: Scott.Daniels@Acm.Org (Scott David Daniels) Date: Fri, 25 Jul 2003 08:55:33 -0700 Subject: [Python-Dev] Re: [spambayes-dev] RE: RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: References: Message-ID: <3F2152F5.1090305@Acm.Org> Tim Peters wrote: >[Scott David Daniels] > > >>I've been seeing a lot of "we'll have to use float(123)/100" >>messages floating around, and I'd like to point out there is an >>atof-able form for floating point numbers: >> 256.7654e-7 = 2567654e-11 >> >> > >Skip is right that this won't help. At compile time, Python doesn't stuff >pieces of the source code into a .pyc file, it builds the float objects and >marshals them. Here's temp.py: > >def example(): > return 1e-1 > >Then: > > > >>>>import temp >>>>file('temp.pyc', 'rb').read() >>>> >>>> >';\xf2\r\n\xf1L!?c\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00 >@\x00\x00\x00s\r\x00\x00\x00d\x00\x00\x84\x00\x00Z\x00\x00d\x01 >\x00S(\x02\x00\x00\x00c\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00 >\x00\x00C\x00\x00\x00s\x08\x00\x00\x00d\x01\x00Sd\x00\x00S(\x02 >\x00\x00\x00Nf\x130.10000000000000001(\x00\x00\x00\x00(\x00\x00 >\x00\x00(\x00\x00\x00\x00(\x00\x00\x00\x00s\x07\x00\x00\x00temp.py >s\x07\x00\x00\x00example\x01\x00\x00\x00s\x02\x00\x00\x00\x00 >\x01N(\x01\x00\x00\x00s\x07\x00\x00\x00example(\x01\x00\x00\x00 >s\x07\x00\x00\x00example(\x00\x00\x00\x00(\x00\x00\x00\x00 >s\x07\x00\x00\x00temp.pys\x01\x00\x00\x00?\x01\x00\x00\x00s\x00 >\x00\x00\x00' > > > >The substring > > f\x130.10000000000000001 > >is the marshal typecode for a float, a byte saying the float string is in >the next 0x13 = 19 bytes, and then the 19-byte string "0.10000000000000001". >The source code's exponential notation didn't survive in the .pyc file. > > > The idea is to change the unmarshal code to transform the 19-byte string to the 24-byte string '010000000000000001e-17' before calling atof. I suppose the marshal code could be converted to generate it, but I was suggesting a way of reading the current format by fiddling bytes before calling atof. -Scott David Daniels From tim.one@comcast.net Fri Jul 25 17:19:07 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 25 Jul 2003 12:19:07 -0400 Subject: [Python-Dev] Re: [spambayes-dev] RE: RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: <3F2152F5.1090305@Acm.Org> Message-ID: [Scott David Daniels] > ... > The idea is to change the unmarshal code to transform the 19-byte > string to the 24-byte string '010000000000000001e-17' before calling > atof. I suppose the marshal code could be converted to generate it, > but I was suggesting a way of reading the current format by fiddling > bytes before calling atof. The unmarshaling code is part of the Python core, and written in C. So we can't change that without releasing a new Python, and requiring that people use that new version. The float(1)/10 "idea" was in the context of workarounds that can avoid the problems today, using the Pythons people already have. The other half of this problem hasn't been mentioned yet because it hasn't come up yet in the spambayes context: if locale happens to get changed while Python is *compiling* a module, the marshaling code can end up writing out a float string with (e.g.) a comma instead of a period. IOW, there isn't a quick hack that's going to solve all the potential problems here (and they're not limited to marshal, either). From janssen@parc.com Fri Jul 25 23:20:07 2003 From: janssen@parc.com (Bill Janssen) Date: Fri, 25 Jul 2003 15:20:07 PDT Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: Your message of "Thu, 24 Jul 2003 20:09:53 PDT." <1059102593.12996.26.camel@anthem> Message-ID: <03Jul25.152012pdt."58611"@synergy1.parc.xerox.com> I get one test failure on Mac OS 10.2.6: test test_pwd failed -- Traceback (most recent call last): File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) KeyError: 'getpwuid(): uid not found' The passwd entry on which it fails looks perfectly normal, AFAICS. We've got about 3500 entries in our passwd file, if that's of interest. Bill From martin@v.loewis.de Fri Jul 25 23:21:16 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 26 Jul 2003 00:21:16 +0200 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: References: Message-ID: "Tim Peters" writes: > > Unfortunately, the "true" source of atof (i.e. from conv.obj) is not > > shipped with MSVC :-( > > Would that help us if we could get it? I'm not sure how. I would hope that some inner routine that does the actual construction of the double is locale-independent, and takes certain details as separate arguments. Then, this routine could be used, passing the "C" specific parameters instead of those of the current locale. Regards, Martin From tjreedy@udel.edu Sat Jul 26 02:34:24 2003 From: tjreedy@udel.edu (Terry Reedy) Date: Fri, 25 Jul 2003 21:34:24 -0400 Subject: [Python-Dev] Re: RE: [Spambayes] Question (or possibly a bug report) References: <1ED4ECF91CDED24C8D012BCF2B034F13027ABDD8@its-xchg4.massey.ac.nz> Message-ID: "Tim Peters" wrote in message news:LNBBLJKPBEHFEDALKOLCGEOJEPAB.tim.one@comcast.net... > [Tim] > >> It would be better if Python didn't use locale-dependent > >> string<->float conversions internally, but that's just not > >> the case (yet). > > [Tony Meyer] > > Is this likely to become the case? (In 2.4, for example?) > > I think so, and maybe before that. Not in 2.3 final, but maybe in 2.3.1 -- > numeric locale problems can be catastrophic to Python programmers, so I'm > comfortable arguing the case for calling it a bugfix. Lib Manual 3.19 says clearly that the marshal format for a specific release is system independent and tranportable. It includes floats as one of the types so supported. If, as I have gathered from this thread, the format for floats is actually, under certain circumstances, whimsy-dependent, I think a warning should be added to the doc until the bug is fixed. Terry J. Reedy From tim.one@comcast.net Sat Jul 26 03:20:21 2003 From: tim.one@comcast.net (Tim Peters) Date: Fri, 25 Jul 2003 22:20:21 -0400 Subject: [Python-Dev] Re: RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: Message-ID: [Terry Reedy] > Lib Manual 3.19 says clearly that the marshal format for a specific > release is system independent and tranportable. It includes floats as > one of the types so supported. If, as I have gathered from this > thread, the format for floats is actually, under certain > circumstances, whimsy-dependent, I think a warning should be added to > the doc until the bug is fixed. The warning is there, but it's in the locale module docs (see the "For extension writers and programs that embed Python" section). It's a documented requirement that LC_NUMERIC be "C" when using Python, and violating that is akin to dividing by 0 in C: nothing is defined if you break the rules. The .pyc problem is only one of the things that can go wrong, and is getting all the attention here just because it *is* going wrong in the spambayes Outlook addin. Note that you can't fall into this trap running a pure Python program. It requires that you also run some non-Python code in the same process that mucks with C runtime state in a forbidden-by-Python way. Python can't *stop* non-Python C code from screwing up the locale, it can only document (and does document) that Python may not work as intended if that occurs. Since Python is functioning as designed and documented in such cases, it's hard to sell this as "a bug" in a convincing way. As Python spreads into more embedded contexts, though, the consequences of this design decision (really more of a no-brainer that looks like "a decision" in hindsight: C's horrid locale gimmicks didn't exist when these parts of Python were first written!) justify arguing for a friendlier (to embedding) design. From aleaxit@yahoo.com Sat Jul 26 11:54:15 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Sat, 26 Jul 2003 12:54:15 +0200 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box Message-ID: <200307261254.15092.aleaxit@yahoo.com> A guy on the Italian Python mailing list has just installed 2.3rc2 on top of his existing 2.2 and IDLE doesn't start. Specifically when he gives an explicit command at the DOS Box prompt of: python.exe "C:\Programmi\Python23\Lib\idlelib\idle.pyw" he sees from Task Manager that 2 python.exe instances start, one disappears after a few seconds, and on the DOS Box appear the messages: Python subprocess socket error: Connection refused, retrying.... Python subprocess socket error: Connection refused, retrying.... Python subprocess socket error: Connection refused, retrying.... Connection to Idle failed, exiting. *HOWEVER* IDLE runs fine IF he starts it while connected to the internet! This clearly points to a configuration/installation problem with his Win2000 SP3 box and I'm working with him to pin that down -- see if his sockets work at all when he's not on the net, etc, etc. Nevertheless I'm worried by this problem: no doubt it's something he needs to fix by correcting his Win2000 installation and configuration, *BUT*, just as doubtlessly a huge number of Windows machines out there must suffer from similar misconfiguration issues. If on all of those misbegotten boxes IDLE 1.0 silently refuses to start with no clarification nor error-message at all to the user as to WHY (typical newbies won't THINK of running idle.pyw at the prompt, they'll keep banging on icons and getting silent failure as a result), I predict a flood of help request to the main and help lists, AND many potential new users simply giving up on Python without even such help requests -- that would be pretty sad. I can't reproduce the problem myself -- I've tried deliberately breaking my Win/98 configuration but local sockets keep getting opened happily, and I have no Win/2000 box to try things on. Should I nevertheless try bug-reporting or even hacking a patch that puts out some kind of visible error message to the user if socket connection fails, even though I can't try it out myself? Does anybody agree with me that this doubtlessly trivial issue has the potential to do Python substantial damage, making it critical enough to address between 2.3rc2 and 2.3 final...? Alex From zooko@zooko.com Sat Jul 26 16:08:46 2003 From: zooko@zooko.com (Zooko) Date: 26 Jul 2003 11:08:46 -0400 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: Message from Detlef Lannert of "Wed, 23 Jul 2003 16:34:50 +0200." <20030723163450.E22274@lannert.rz.uni-duesseldorf.de> References: <20030722204201.11589.74038.Mailman@mail.python.org> <20030723163450.E22274@lannert.rz.uni-duesseldorf.de> Message-ID: Detlef Lannert wrote: > > This is maybe not the same problem that Zooko had, but bsddb doesn't > build on my Linux 2.4.10 (SuSE 7.3) box either where Sleepycat > db-4.1.25 was installed from the sources. It puts db.h under > /usr/local/include per default where Python's setup.py doesn't find it. This *was* the same problem that I had. http://sourceforge.net/tracker/index.php?func=detail&aid=775850&group_id=5470&atid=105470 The solution ("workaround"?) is to install bsddb in `/usr/local/BerkeleyDB.4.1'. Regards, Zooko From tim.one@comcast.net Sat Jul 26 16:56:47 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 26 Jul 2003 11:56:47 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <200307261254.15092.aleaxit@yahoo.com> Message-ID: Noting that someone on the Tutor list running a "personal firewall" kind of program was disturbed because it reported that 2.3c1 IDLE was trying to access the Internet at startup. They were concerned about why IDLE would be reporting *anything* about them to another machine. I confess I had the same question when I first tried the new IDLE on Win98SE, and ZoneAlarm raised an eyebrow. Of course I looked at the source and saw then it was only talking to localhost, but for some reason it didn't occur to me that anyone else might wonder about this too. It's obvious that gazillions of Windows users will wonder about it. If anyone has an idea about where to put a reassuring explanation that a panicky Windows user is likely to read, don't be shy. From skip@pobox.com Sat Jul 26 17:01:24 2003 From: skip@pobox.com (Skip Montanaro) Date: Sat, 26 Jul 2003 11:01:24 -0500 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: References: <20030722204201.11589.74038.Mailman@mail.python.org> <20030723163450.E22274@lannert.rz.uni-duesseldorf.de> Message-ID: <16162.42452.940978.48426@montanaro.dyndns.org> Detlef> This is maybe not the same problem that Zooko had, but bsddb Detlef> doesn't build on my Linux 2.4.10 (SuSE 7.3) box either where Detlef> Sleepycat db-4.1.25 was installed from the sources. It puts Detlef> db.h under /usr/local/include per default where Python's Detlef> setup.py doesn't find it. zooko> This *was* the same problem that I had. zooko> The solution ("workaround"?) is to install bsddb in zooko> `/usr/local/BerkeleyDB.4.1'. I've been resistant to adding /usr/include and /usr/lib to the search path in setup.py because some platforms still ship with Berkeley DB 1.85 in those directories. If you can supply a patch to setup.py which will only allow db3 or 4 to be used to link the bsddb module, I will see about adding /usr/include and /usr/lib to the bsddb module search path for 2.3.1. Anything you come up with should also allow the bsddb185 module to build with db2, 3 or 4, but require a simple tweak to setup.py (perhaps a variable setting change at the top of the file) to build it with db1.85. Skip From aahz@pythoncraft.com Sat Jul 26 17:04:48 2003 From: aahz@pythoncraft.com (Aahz) Date: Sat, 26 Jul 2003 12:04:48 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: References: <200307261254.15092.aleaxit@yahoo.com> Message-ID: <20030726160447.GA16886@panix.com> On Sat, Jul 26, 2003, Tim Peters wrote: > > Noting that someone on the Tutor list running a "personal firewall" kind of > program was disturbed because it reported that 2.3c1 IDLE was trying to > access the Internet at startup. They were concerned about why IDLE would be > reporting *anything* about them to another machine. > > I confess I had the same question when I first tried the new IDLE on > Win98SE, and ZoneAlarm raised an eyebrow. Of course I looked at the source > and saw then it was only talking to localhost, but for some reason it didn't > occur to me that anyone else might wonder about this too. > > It's obvious that gazillions of Windows users will wonder about it. If > anyone has an idea about where to put a reassuring explanation that a > panicky Windows user is likely to read, don't be shy. This is more code change than I'd like this late, but perhaps we should pop up a dialog the first time IDLE starts that stores a key in the registry when the user clicks OK. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From aleaxit@yahoo.com Sat Jul 26 17:05:20 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Sat, 26 Jul 2003 18:05:20 +0200 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: References: Message-ID: <200307261805.20985.aleaxit@yahoo.com> On Saturday 26 July 2003 05:56 pm, Tim Peters wrote: > Noting that someone on the Tutor list running a "personal firewall" kind of > program was disturbed because it reported that 2.3c1 IDLE was trying to > access the Internet at startup. They were concerned about why IDLE would > be reporting *anything* about them to another machine. > > I confess I had the same question when I first tried the new IDLE on > Win98SE, and ZoneAlarm raised an eyebrow. Of course I looked at the source > and saw then it was only talking to localhost, but for some reason it > didn't occur to me that anyone else might wonder about this too. > > It's obvious that gazillions of Windows users will wonder about it. If > anyone has an idea about where to put a reassuring explanation that a > panicky Windows user is likely to read, don't be shy. Just brainstorming...: in the Windows installer (if a suitable place can be found); in the README most definitely (SOME users, albeit a minority, will have a look at the README -- far fewer than will think to look at the IDLE sources or be able to make sense of them); in the "what's new" doc; in the IDLE docs; ... (not intended to be mutually exclusive). More ideas, anybody? Alex From kbk@shore.net Sat Jul 26 17:22:07 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 12:22:07 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <200307261254.15092.aleaxit@yahoo.com> (Alex Martelli's message of "Sat, 26 Jul 2003 12:54:15 +0200") References: <200307261254.15092.aleaxit@yahoo.com> Message-ID: Alex Martelli writes: > A guy on the Italian Python mailing list has just installed 2.3rc2 > on top of his existing 2.2 and IDLE doesn't start. Specifically > when he gives an explicit command at the DOS Box prompt of: > > python.exe "C:\Programmi\Python23\Lib\idlelib\idle.pyw" > > he sees from Task Manager that 2 python.exe instances start, one > disappears after a few seconds, and on the DOS Box appear the > messages: > > Python subprocess socket error: Connection refused, retrying.... > > Python subprocess socket error: Connection refused, retrying.... > > Python subprocess socket error: Connection refused, retrying.... > > Connection to Idle failed, exiting. If he got this far, the GUI process was able to set up a listening socket on 127.0.0.1 / 8833 but the subprocess was not able to make a connection to it. I have seen this problem in the past when a crashed IDLE GUI process was left listening on 8833. Please have him check the task manager, there should be only two pythonw.exe running in W2K. Sorting the task manager on the first column helps to see this. > *HOWEVER* IDLE runs fine IF he starts it while connected to > the internet! This clearly points to a configuration/installation > problem with his Win2000 SP3 box Please define "connected to the internet". Does it mean plug in the RJ-45? What exactly does he do to "disconnect"? Are reboots involved? (He should upgrade his box, there is a critical buffer overflow hole in Direct X announced a couple of days ago. It would also be interesting to see if SP4 etc. fixes the problem.) > and I'm working with him to pin that down -- see if his sockets work > at all when he's not on the net, etc, etc. Nevertheless I'm worried > by this problem: no doubt it's something he needs to fix by > correcting his Win2000 installation and configuration, *BUT*, just > as doubtlessly a huge number of Windows machines out there must > suffer from similar misconfiguration issues. If on all of those > misbegotten boxes IDLE 1.0 silently refuses to start with no > clarification nor error-message at all to the user as to WHY > (typical newbies won't THINK of running idle.pyw at the prompt, > they'll keep banging on icons and getting silent failure as a > result), Well, this is the key point. Things can and no doubt will go wrong, many of them beyond the control of IDLE or Python. It's desirable to let the user know what's going on if possible and not leave him "banging the icons" :-) > I predict a flood of help request to the main and help lists, AND > many potential new users simply giving up on Python without even > such help requests -- that would be pretty sad. > > I can't reproduce the problem myself -- I've tried deliberately > breaking my Win/98 configuration but local sockets keep getting > opened happily, and I have no Win/2000 box to try things on. I can't see it on W2K / SP4 or XP Pro 2002 / SP1 but I need to know what "disconnect from the internet" means. > Should I nevertheless try bug-reporting or even hacking a patch that > puts out some kind of visible error message to the user if socket > connection fails, even though I can't try it out myself? Does > anybody agree with me that this doubtlessly trivial issue has the > potential to do Python substantial damage, making it critical enough > to address between 2.3rc2 and 2.3 final...? This would involve having the subprocess open a Tk window with the error message. I'll take a look at it. However, I'm going to be away for a couple of days starting this afternoon. -- KBK From kbk@shore.net Sat Jul 26 17:32:47 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 12:32:47 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <20030726160447.GA16886@panix.com> (Aahz's message of "Sat, 26 Jul 2003 12:04:48 -0400") References: <200307261254.15092.aleaxit@yahoo.com> <20030726160447.GA16886@panix.com> Message-ID: Aahz writes: > This is more code change than I'd like this late, but perhaps we > should pop up a dialog the first time IDLE starts that stores a key > in the registry when the user clicks OK. This doesn't help users on other platforms who may have similar concerns. Perhaps a pop up and then store a marker in .idlerc/config-main.cfg to show it's no longer the first start? -- KBK From anna@aleax.it Sat Jul 26 17:38:27 2003 From: anna@aleax.it (Anna Ravenscroft) Date: Sat, 26 Jul 2003 18:38:27 +0200 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <200307261805.20985.aleaxit@yahoo.com> References: <200307261805.20985.aleaxit@yahoo.com> Message-ID: <200307261838.27595.anna@aleax.it> On Saturday 26 July 2003 06:05 pm, Alex Martelli wrote: > On Saturday 26 July 2003 05:56 pm, Tim Peters wrote: > > Noting that someone on the Tutor list running a "personal firewall" kind > > of program was disturbed because it reported that 2.3c1 IDLE was trying > > to access the Internet at startup. They were concerned about why IDLE > > would be reporting *anything* about them to another machine. > > > > I confess I had the same question when I first tried the new IDLE on > > Win98SE, and ZoneAlarm raised an eyebrow. Of course I looked at the > > source and saw then it was only talking to localhost, but for some reason > > it didn't occur to me that anyone else might wonder about this too. > > > > It's obvious that gazillions of Windows users will wonder about it. If > > anyone has an idea about where to put a reassuring explanation that a > > panicky Windows user is likely to read, don't be shy. > > Just brainstorming...: in the Windows installer (if a suitable place can be > found); in the README most definitely (SOME users, albeit a minority, > will have a look at the README -- far fewer than will think to look at > the IDLE sources or be able to make sense of them); in the "what's > new" doc; in the IDLE docs; ... (not intended to be mutually exclusive). > > More ideas, anybody? > > > Alex Alex just explained to me what this situation is about and I'm very concerned. As a sometime Windows user, I installed Python on my computer at work as well as on my Linux box at home. If, in starting IDLE, I had seen a message like ya'll are talking about, I'd have assumed that Python/IDLE had decided to follow the example of some of our closed source villains and was attempting to send some kind of personal information about my system to someone somewhere. This would have stopped me in my tracks, especially since I was running it at work. I think this needs to be dealt with as a very serious issue - the use of sockets for coprocesses in the new IDLE desperately needs to be explained clearly for the uninitiated, and a notice on the FRONT PAGE of python.org should be prominently displayed, imho, with a link to the fuller NEWBIE-friendly explanation. I *also* agree with Aahz's idea of a reassuringly-worded pop-up that handles the problem quietly. Please - don't blow this off - there are a lot of (justifiably or not) paranoid people out there who may be tentatively exploring programming via Python and this kind of thing could really scare them off. There are also a lot ot potential pythonistas who *dont'* understand sockets but still want to learn Python. (For example, I saw a number of pythonistas at the tutorial on sockets and other networking issues at OSCON, so I know that not all pythonistas understand sockets.) If we simply ignore this issue - we're likely to lose people over it. And I would find that a sad thing. cordially, Anna Ravenscroft From aahz@pythoncraft.com Sat Jul 26 17:38:51 2003 From: aahz@pythoncraft.com (Aahz) Date: Sat, 26 Jul 2003 12:38:51 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: References: <200307261254.15092.aleaxit@yahoo.com> <20030726160447.GA16886@panix.com> Message-ID: <20030726163851.GA29436@panix.com> On Sat, Jul 26, 2003, Kurt B. Kaiser wrote: > Aahz writes: >> >> This is more code change than I'd like this late, but perhaps we >> should pop up a dialog the first time IDLE starts that stores a key >> in the registry when the user clicks OK. > > This doesn't help users on other platforms who may have similar > concerns. Perhaps a pop up and then store a marker in > .idlerc/config-main.cfg to show it's no longer the first start? That'd work, provided .idlerc/ is stored in a user's directory. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From kbk@shore.net Sat Jul 26 17:43:03 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 12:43:03 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <200307261805.20985.aleaxit@yahoo.com> (Alex Martelli's message of "Sat, 26 Jul 2003 18:05:20 +0200") References: <200307261805.20985.aleaxit@yahoo.com> Message-ID: Alex Martelli writes: > Just brainstorming...: in the Windows installer (if a suitable place > can be found); in the README most definitely (SOME users, albeit a > minority, will have a look at the README -- far fewer than will > think to look at the IDLE sources or be able to make sense of them); > in the "what's new" doc; in the IDLE docs; ... (not intended to be > mutually exclusive). > > More ideas, anybody? I'll send in a patch to .../idlelib/README.txt to add a comment about this. The README is accessible from the About IDLE dialog available on the Help menu so there's a /slight/ chance it might be read :-) The popup on first use is probably necessary if you really want (to attempt :) to get the user's attention. -- KBK From aahz@pythoncraft.com Sat Jul 26 17:45:47 2003 From: aahz@pythoncraft.com (Aahz) Date: Sat, 26 Jul 2003 12:45:47 -0400 Subject: [Python-Dev] 2.3.1 Message-ID: <20030726164547.GA987@panix.com> Given that the IDLE bug doesn't affect Apple (they don't ship Python with Tkinter), I suggest that we not run around like chickens to fix the IDLE bug, but plan on a 2.3.1 release by end of August. What I'd recommend doing for now is putting a big note on the 2.3 download page (not on the front page as Anna suggests). This would also give us time to deal with some other nagging issues for the 2.3 release while committing to a relatively short window for getting them out. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From aleaxit@yahoo.com Sat Jul 26 17:49:57 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Sat, 26 Jul 2003 18:49:57 +0200 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: References: <200307261254.15092.aleaxit@yahoo.com> Message-ID: <200307261849.58008.aleaxit@yahoo.com> On Saturday 26 July 2003 18:22, Kurt B. Kaiser wrote: ... > > Python subprocess socket error: Connection refused, retrying.... > > > > Python subprocess socket error: Connection refused, retrying.... > > > > Python subprocess socket error: Connection refused, retrying.... > > > > Connection to Idle failed, exiting. > > If he got this far, the GUI process was able to set up a listening > socket on 127.0.0.1 / 8833 but the subprocess was not able to make a > connection to it. I have seen this problem in the past when a crashed > IDLE GUI process was left listening on 8833. Please have him check > the task manager, there should be only two pythonw.exe running in W2K. > Sorting the task manager on the first column helps to see this. Sorry, I was translating only a part of the very copious information I exchanged (in Italian) with that user. He IS quite aware that a pythonw.exe process may often be left hanging for one reason or another and on all attempts has been careful to terminate all python.exe and pythonw.exe processes. > > *HOWEVER* IDLE runs fine IF he starts it while connected to > > the internet! This clearly points to a configuration/installation > > problem with his Win2000 SP3 box > > Please define "connected to the internet". Does it mean plug in > the RJ-45? What exactly does he do to "disconnect"? Are reboots > involved? Nope. It's a Windows functionality that in the Italian versions of Windows is called "Connessione Remota" (and I don't have a US version of Windows at hand to check how it's called there): connects your machine to the net via your modem and your ISP, by dialing out and handshaking appropriately (normally with PPP, I believe) etc. The icon/Start menu entry to activate this is labeled something like "Connect to the Internet" (or the Italian translation thereof), so it seems quite reasonable for Windows users to call it similarly. > (He should upgrade his box, there is a critical buffer overflow hole > in Direct X announced a couple of days ago. It would also be > interesting to see if SP4 etc. fixes the problem.) OK, I'll let him know. My hypothesis is that any good reinstall & config of his box will fix HIS problem (he needs a loopback interface adapter, if I recall WIndows terms correctly) but that's not the gist of the problem. How many thousands of Windows users will have machines that only support sockets when "connected to the internet" (dialed out), or personal firewalls that don't know that localhost is safe to connect to (as Tim Peters reported), etc? Helping that Italian user fix his own problem won't help those thousands... > > (typical newbies won't THINK of running idle.pyw at the prompt, > > they'll keep banging on icons and getting silent failure as a > > result), > > Well, this is the key point. Things can and no doubt will go wrong, > many of them beyond the control of IDLE or Python. It's desirable to > let the user know what's going on if possible and not leave him > "banging the icons" :-) Right. In other words you seem to second Aahz's suggestion of some dialog the first time IDLE is started -- I've seen Anna second (third?) it too, and I'll fourth it -- yes, adding code so late is quite unpleasant, but if we don't this is going to be a black eye for the reputation of Python 2.3 among the unwashed masses, IMHO. > > opened happily, and I have no Win/2000 box to try things on. > > I can't see it on W2K / SP4 or XP Pro 2002 / SP1 but I need to > know what "disconnect from the internet" means. I'm pretty sure it means "hang up the remote-connection to the ISP" and that it will give no problem on a well-configured machine. > This would involve having the subprocess open a Tk window with > the error message. I'll take a look at it. However, I'm going > to be away for a couple of days starting this afternoon. At least an error message that's user readable would be better than nothing, though it won't help with the personal firewall side of things. Alex From kbk@shore.net Sat Jul 26 17:57:13 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 12:57:13 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <20030726163851.GA29436@panix.com> (Aahz's message of "Sat, 26 Jul 2003 12:38:51 -0400") References: <200307261254.15092.aleaxit@yahoo.com> <20030726160447.GA16886@panix.com> <20030726163851.GA29436@panix.com> Message-ID: Aahz writes: > That'd work, provided .idlerc/ is stored in a user's directory. On XP it's in \Documents and Settings\\.idlerc\ On W2K and W98 it gets stored in c:\ but those boxes tend to be single user machines anyhow. Centrally administrated boxes have probably been moved to XP by now. I haven't investigated what needs to be done to get .idlerc into the user's Documents and Settings on W2K as yet. -- KBK From aleax@aleax.it Sat Jul 26 18:01:54 2003 From: aleax@aleax.it (Alex Martelli) Date: Sat, 26 Jul 2003 19:01:54 +0200 Subject: [Python-Dev] 2.3.1 In-Reply-To: <20030726164547.GA987@panix.com> References: <20030726164547.GA987@panix.com> Message-ID: <200307261901.54070.aleax@aleax.it> On Saturday 26 July 2003 18:45, Aahz wrote: > Given that the IDLE bug doesn't affect Apple (they don't ship Python > with Tkinter), I suggest that we not run around like chickens to fix the > IDLE bug, but plan on a 2.3.1 release by end of August. > > What I'd recommend doing for now is putting a big note on the 2.3 > download page (not on the front page as Anna suggests). Maybe a reasonable compromise -- download page, "what's new", and assorted README files. Updating those won't break anything. after all. Still, passing errors off silently when they've not been explicitly silenced IS a bug, as well as a violation of the Python Zen -- and that seems to be what IDLE is currently doing. Documenting the bug is better than nothing, but putting out a 2.3 release with such a known bug "because that bug won't affect Apple" (with its whopping, what, 5% of the market vs Microsoft's 90%+...?) still leaves me a bit perplexed. Decision up to the release managers, of course, but as for me personally I'd like 2.3 to have a bit more than just these updates to python.org & informal docfiles to make the user aware that [a] socket bugs may be impeding his use of IDLE AND [b] IDLE is NOT trying to send information out surreptitiously. Not fixing bugs (that might be too hard to do right now for 2.3 and missing 2.3's deadline is just not an option) but making sure "cards are on the table"... > This would also give us time to deal with some other nagging issues for > the 2.3 release while committing to a relatively short window for > getting them out. Yes, this does sound good to me. A short-term 2.3.1 to fix this and other nags does sound good; I'd just like to see a little bit more about it in 2.3 proper. Alex From aahz@pythoncraft.com Sat Jul 26 18:13:07 2003 From: aahz@pythoncraft.com (Aahz) Date: Sat, 26 Jul 2003 13:13:07 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: <200307261901.54070.aleax@aleax.it> References: <20030726164547.GA987@panix.com> <200307261901.54070.aleax@aleax.it> Message-ID: <20030726171307.GA7751@panix.com> On Sat, Jul 26, 2003, Alex Martelli wrote: > On Saturday 26 July 2003 18:45, Aahz wrote: >> >> Given that the IDLE bug doesn't affect Apple (they don't ship Python >> with Tkinter), I suggest that we not run around like chickens to fix the >> IDLE bug, but plan on a 2.3.1 release by end of August. >> >> What I'd recommend doing for now is putting a big note on the 2.3 >> download page (not on the front page as Anna suggests). > > Maybe a reasonable compromise -- download page, "what's new", > and assorted README files. Updating those won't break anything. > after all. Fine by me. > Still, passing errors off silently when they've not been explicitly > silenced IS a bug, as well as a violation of the Python Zen -- and > that seems to be what IDLE is currently doing. Documenting the bug > is better than nothing, but putting out a 2.3 release with such a > known bug "because that bug won't affect Apple" (with its whopping, > what, 5% of the market vs Microsoft's 90%+...?) still leaves me a bit > perplexed. Decision up to the release managers, of course, but as for > me personally I'd like 2.3 to have a bit more than just these updates > to python.org & informal docfiles to make the user aware that [a] > socket bugs may be impeding his use of IDLE AND [b] IDLE is NOT trying > to send information out surreptitiously. Not fixing bugs (that might > be too hard to do right now for 2.3 and missing 2.3's deadline is just > not an option) but making sure "cards are on the table"... My point is that by putting a note on the download page, it's likely that few people will upgrade until 2.3.1 comes out, particularly if they know they only need to wait a month. It's doubtful that any embedded systems other than Apple will use 2.3. Alex, you've got commit privs and you're a decent writer ;-), so why don't you go ahead and make the changes to the README and What's New files (other than IDLE's README, which Kurt will handle). If Barry doesn't like the changes, he can revert them. Barry or I will handle the download page. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From kbk@shore.net Sat Jul 26 18:15:42 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 13:15:42 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <200307261849.58008.aleaxit@yahoo.com> (Alex Martelli's message of "Sat, 26 Jul 2003 18:49:57 +0200") References: <200307261254.15092.aleaxit@yahoo.com> <200307261849.58008.aleaxit@yahoo.com> Message-ID: Alex Martelli writes: >> This would involve having the subprocess open a Tk window with >> the error message. I'll take a look at it. However, I'm going >> to be away for a couple of days starting this afternoon. > > At least an error message that's user readable would be better > than nothing, though it won't help with the personal firewall side > of things. Two separate issues: 1. Failure of IDLE to initialize its subprocess doesn't result in a message visible to the user. 2. Unnecessary user aggravation (I'm paranoid, too) caused by personal firewall software complaining about use of the loopback interface. The use of sockets and the loopback interface was chosen as an IPC method that is supported by Windows as well as Unix based platforms. In the absence of personal firewall software no warnings are seen by the user. -- KBK From gh@ghaering.de Sat Jul 26 18:19:16 2003 From: gh@ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=) Date: Sat, 26 Jul 2003 19:19:16 +0200 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <200307261838.27595.anna@aleax.it> References: <200307261805.20985.aleaxit@yahoo.com> <200307261838.27595.anna@aleax.it> Message-ID: <3F22B814.1070000@ghaering.de> Anna Ravenscroft wrote: > [IDLE uses connections to localhost for interprocess communication; > this triggers "security alerts" in some so-called "Personal Firewalls"] http://www.fefe.de/pffaq/ explains this topic exhaustively. I'll refrain from further comments about this "problem" for now, as I might regret them afterwards. -- Gerhard From drifty@alum.berkeley.edu Sat Jul 26 19:01:39 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Sat, 26 Jul 2003 11:01:39 -0700 Subject: [Python-Dev] 2.3.1 In-Reply-To: <20030726164547.GA987@panix.com> References: <20030726164547.GA987@panix.com> Message-ID: <3F22C203.10203@ocf.berkeley.edu> Aahz wrote: > Given that the IDLE bug doesn't affect Apple (they don't ship Python > with Tkinter), I suggest that we not run around like chickens to fix the > IDLE bug, but plan on a 2.3.1 release by end of August. > Perhaps, but they are including X11 in Panther and so more people will probably be willing to download Tk that has been pre-compiled for OS X and use it if they don't explicitly exclude IDLE from their distro of Python. Jack, do have any info or a comment on this? -Brett From skip@pobox.com Sat Jul 26 19:03:37 2003 From: skip@pobox.com (Skip Montanaro) Date: Sat, 26 Jul 2003 13:03:37 -0500 Subject: [Python-Dev] 2.3.1 In-Reply-To: <200307261901.54070.aleax@aleax.it> References: <20030726164547.GA987@panix.com> <200307261901.54070.aleax@aleax.it> Message-ID: <16162.49785.800687.878189@montanaro.dyndns.org> Alex> .... Documenting the bug is better than nothing, but putting out a Alex> 2.3 release with such a known bug "because that bug won't affect Alex> Apple" (with its whopping, what, 5% of the market vs Microsoft's Alex> 90%+...?) still leaves me a bit perplexed.... Let's see, the following two aphorisms come to mind: * It's better than a poke in the eye with a sharp stick. * Half a loaf is better than none. The point is, Apple has a release window closing (Panther, 10.3) in a few days and if we hit that release then Python 2.3 will be part of the mix. While it might be only 5% of the desktop market, it's still a big plug for Python and recognition of all the work Jack Jansen, Just van Rossum and others have put into the MacPython stuff. I see nothing wrong with letting this IDLE problem slip through to the 2.3 release with notes in the relevant readme-type documentation. It's simply been discovered too late to fix in this release given that we are at 2.3c2. Skip From kbk@shore.net Sat Jul 26 19:25:48 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 14:25:48 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: <16162.49785.800687.878189@montanaro.dyndns.org> (Skip Montanaro's message of "Sat, 26 Jul 2003 13:03:37 -0500") References: <20030726164547.GA987@panix.com> <200307261901.54070.aleax@aleax.it> <16162.49785.800687.878189@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > I see nothing wrong with letting this IDLE problem slip through to the 2.3 > release with notes in the relevant readme-type documentation. It's simply > been discovered too late to fix in this release given that we are at 2.3c2. In the interest of at least partially resolving these issues for 2.3 without major code changes: [KBK] > Two separate issues: > > 1. Failure of IDLE to initialize its subprocess doesn't result in a > message visible to the user. A message can be displayed to the user if we configure the Windows installer to bind the IDLE icon to python.exe instead of pythonw.exe. That way a DOS box will open behind IDLE and any messages will be visible there. This is a small patch. [KBK] > 2. Unnecessary user aggravation (I'm paranoid, too) caused by > personal firewall software complaining about use of the > loopback interface. A very restricted change to the code would be add the following to the banner printed at the top of the shell when it starts (the socket connection isn't made until the shell window opens): *************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. *************************************************************** This involves an addition to PyShell.py:PyShell.begin(), line 873. In addition, the .../idlelib/README.txt would be updated with the same message w/o the asterisks. These are not the final solutions. A pop-up for #1, everytime, and a pop-up for #2 on first use would be introduced into 2.3.1. The above banner could be retained even after the popup is implemented, though I'm -1 on that. Comments? -- KBK From aleax@aleax.it Sat Jul 26 19:40:35 2003 From: aleax@aleax.it (Alex Martelli) Date: Sat, 26 Jul 2003 20:40:35 +0200 Subject: [Python-Dev] 2.3.1 In-Reply-To: References: <20030726164547.GA987@panix.com> <16162.49785.800687.878189@montanaro.dyndns.org> Message-ID: <200307262040.35424.aleax@aleax.it> On Saturday 26 July 2003 20:25, Kurt B. Kaiser wrote: ... > Skip Montanaro writes: > > I see nothing wrong with letting this IDLE problem slip through to the > > 2.3 release with notes in the relevant readme-type documentation. It's > > simply been discovered too late to fix in this release given that we > > are at 2.3c2. "release candidates" are supposed to help us find critical bugs AND FIX THEM before final release. I opine these bugs that we've found ARE critical enough, to enough Python would-be-users on the numerically dominating platform (WIndows), that we should do some minimal effort to fix or at least clearly indicate them (given that one is a missing diagnosis of a user-machine configuration bug, and the other a perfectly acceptable behavior that some buggy but popular pieces of software misdiagnose as IDLE trying to connect to the internet...) in places where users will SEE the indication (download page is good but not quite sufficent IMHO). > In the interest of at least partially resolving these issues for 2.3 > without major code changes: Yes, that sounds like what we should be aiming at. > > Two separate issues: > > > > 1. Failure of IDLE to initialize its subprocess doesn't result in a > > message visible to the user. > > A message can be displayed to the user if we configure the Windows > installer to bind the IDLE icon to python.exe instead of pythonw.exe. > That way a DOS box will open behind IDLE and any messages will be > visible there. This is a small patch. Yes, but the DOS box will be open for EVERY use of IDLE on Windows including ones without errors -- and it will close when IDLE terminates, so the messages will disappear. It seems to me the "fix" for this should be to use messageboxes rather than print or the like (surely can't be that much bigger a fix for a program already using Tkinter?). > > 2. Unnecessary user aggravation (I'm paranoid, too) caused by > > personal firewall software complaining about use of the > > loopback interface. > > A very restricted change to the code would be add the following > to the banner printed at the top of the shell when it starts (the > socket connection isn't made until the shell window opens): > > *************************************************************** > Personal firewall software may warn about the connection IDLE > makes to its subprocess using this computer's internal loopback > interface. This connection is not visible on any external > interface and no data is sent to or received from the Internet. > *************************************************************** > > This involves an addition to PyShell.py:PyShell.begin(), line 873. Yes, this sounds like a real improvement to me. Ideally it should be Windows-only (no reason to display this to users on e.g Linux, where I don't believe there is any such problem). > In addition, the .../idlelib/README.txt would be updated with the > same message w/o the asterisks. > > These are not the final solutions. A pop-up for #1, everytime, and a > pop-up for #2 on first use would be introduced into 2.3.1. The above > banner could be retained even after the popup is implemented, though > I'm -1 on that. Agree with you -- a first-time-only popup sounds better (but it had better wait until 2.3.1 as it's substantially more code). > Comments? Can you submit the patches? Alex From pf_moore@yahoo.co.uk Sat Jul 26 22:53:43 2003 From: pf_moore@yahoo.co.uk (Paul Moore) Date: Sat, 26 Jul 2003 22:53:43 +0100 Subject: [Python-Dev] Re: 2.3.1 References: <20030726164547.GA987@panix.com> <16162.49785.800687.878189@montanaro.dyndns.org> <200307262040.35424.aleax@aleax.it> Message-ID: Alex Martelli writes: > "release candidates" are supposed to help us find critical bugs AND > FIX THEM before final release. I opine these bugs that we've found > ARE critical enough, to enough Python would-be-users on the > numerically dominating platform (WIndows), that we should do some > minimal effort to fix or at least clearly indicate them (given that > one is a missing diagnosis of a user-machine configuration bug, and > the other a perfectly acceptable behavior that some buggy but > popular pieces of software misdiagnose as IDLE trying to connect to > the internet...) in places where users will SEE the indication > (download page is good but not quite sufficent IMHO). Um. While I understand the issue involved, I find it hard to be quite as convinced as this, that the issue is a bug. First of all, I would say that on a correctly functioning machine, applications should be able to listen on, and send to, unprivileged (> 1024) ports on the local machine (127.0.0.1). In that case, I don't see a bug in Python, or in IDLE. There may be "bugs" in certain systems, whereby such ports are not available, but that isn't Python's fault. In thinking about this, however, there *is* one major point which I think needs to be considered. As I understand the issue, IDLE runs as 2 processes which talk via a socket. I assume that it is not possible for this socket to be used by anything *other* than IDLE - in particular, random hackers can't use the open socket as a means of exploit? Such a security hole would, indeed, be a major bug which needs to be addressed. Assuming no such security hole, what remains is an education issue. This is exacerbated by the tendency of some "personal firewall" products to ask the user for his/her opinion on all sorts of otherwise innocent network traffic - often the user has no way of giving an informed opinion, and the question does nothing but foster paranoia. Sure, the fact that people might ask "why is Python talking to the internet?" is worrying. But surely the correct answer is to say firmly, but in the politest possible way, "it's not - whatever gave you the impression that it is, is mistaken". Explanatory dialogs might help for some people, but you risk hitting the other problem, of annoying people who *do* understand what's going on by looking patronising. Paul. -- This signature intentionally left blank From martin@v.loewis.de Sat Jul 26 22:57:30 2003 From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 26 Jul 2003 23:57:30 +0200 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: <16162.42452.940978.48426@montanaro.dyndns.org> References: <20030722204201.11589.74038.Mailman@mail.python.org> <20030723163450.E22274@lannert.rz.uni-duesseldorf.de> <16162.42452.940978.48426@montanaro.dyndns.org> Message-ID: <3F22F94A.7030401@v.loewis.de> Skip Montanaro wrote: > Detlef> This is maybe not the same problem that Zooko had, but bsddb > Detlef> doesn't build on my Linux 2.4.10 (SuSE 7.3) box either where > Detlef> Sleepycat db-4.1.25 was installed from the sources. It puts > Detlef> db.h under /usr/local/include per default where Python's > Detlef> setup.py doesn't find it. > > zooko> This *was* the same problem that I had. > > zooko> The solution ("workaround"?) is to install bsddb in > zooko> `/usr/local/BerkeleyDB.4.1'. > > I've been resistant to adding /usr/include and /usr/lib to the search path > in setup.py because some platforms still ship with Berkeley DB 1.85 in those > directories. I have a number of observations and corrections to make: 1. The default installation of Sleepycat Berkeley DB does *not* install the files to /usr/local, but to /usr/local/BerkeleyDB.x.y. You have to request /usr/local explicitly, and you should not do so, unless you know what you are doing. 2. If Sleepycat is in /usr/local, Zooko's problem was *not* that setup.py would not find it there. Instead, the problem was that ld-linux.so.1 would not look for shared libraries in /usr/local. 3. Zooko's problem also was *not* related to /usr Regards, Martin From martin@v.loewis.de Sat Jul 26 23:05:45 2003 From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 27 Jul 2003 00:05:45 +0200 Subject: [Python-Dev] 2.3.1 In-Reply-To: <200307262040.35424.aleax@aleax.it> References: <20030726164547.GA987@panix.com> <16162.49785.800687.878189@montanaro.dyndns.org> <200307262040.35424.aleax@aleax.it> Message-ID: <3F22FB39.4030502@v.loewis.de> Alex Martelli wrote: > "release candidates" are supposed to help us find critical bugs AND FIX THEM > before final release. I opine these bugs that we've found ARE critical > enough I completely disagree. This code has been in IDLE for quite some time. If it was a serious problem, it would have been reported before. Regards, Martin From aleax@aleax.it Sat Jul 26 23:16:05 2003 From: aleax@aleax.it (Alex Martelli) Date: Sun, 27 Jul 2003 00:16:05 +0200 Subject: [Python-Dev] 2.3.1 In-Reply-To: <3F22FB39.4030502@v.loewis.de> References: <20030726164547.GA987@panix.com> <200307262040.35424.aleax@aleax.it> <3F22FB39.4030502@v.loewis.de> Message-ID: <200307270016.05042.aleax@aleax.it> On Sunday 27 July 2003 00:05, Martin v. Löwis wrote: > Alex Martelli wrote: > > "release candidates" are supposed to help us find critical bugs AND FIX > > THEM before final release. I opine these bugs that we've found ARE > > critical enough > > I completely disagree. This code has been in IDLE for quite some time. > If it was a serious problem, it would have been reported before. It's been in *idlefork* -- not in the mainstream, an official Python release. The kind of people for whom these problems are very serious -- newbies, attracting whom is crucial to Python's future -- just aren't likely to download and try arbitrary SF projects nor any release that's not "final"; the people who DO download and try SF projects and alpha/beta/rc releases -- and submit bug reports for things they dislike -- are clearly more likely to have well configured machines, avoid using "personal firewalls" that as Gerhard reminded us are in fact of dubious utility though popular, or even (as Tim Peters reports he did) investigate the sources enough to satisfy themselves that the firewall's report is bogus and not submit that as an idlefork bug. Alex From martin@v.loewis.de Sat Jul 26 23:31:33 2003 From: martin@v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 27 Jul 2003 00:31:33 +0200 Subject: [Python-Dev] 2.3.1 In-Reply-To: <200307270016.05042.aleax@aleax.it> References: <20030726164547.GA987@panix.com> <200307262040.35424.aleax@aleax.it> <3F22FB39.4030502@v.loewis.de> <200307270016.05042.aleax@aleax.it> Message-ID: <3F230145.1090207@v.loewis.de> Alex Martelli wrote: > It's been in *idlefork* -- not in the mainstream, an official Python > release. It's been in 2.3b2. The release candidate is to discover critical bugs that have been introduced *in that candidate*, not to discover bugs that had been there before. Beta releases are there to find bugs that had been introduced during the development cycle. > The kind of people for whom these problems are very > serious -- newbies, attracting whom is crucial to Python's future -- > just aren't likely to download and try arbitrary SF projects nor any > release that's not "final"; These are the people for whom that problem is serious. However, if the problem was really common, it would have been detected during the beta. So while the problem might be serious if it happens, I still don't think it happens often. It's not that all, or even most, Win98 installations are affected. So far, the actual conditions under which it occurs haven't even been identified, let alone the problem being understood. So I suggest to release IDLE as-is, investigating more time into understanding both the cause of the problem and the impact in real life. Regards, Martin From skip@pobox.com Sat Jul 26 23:36:01 2003 From: skip@pobox.com (Skip Montanaro) Date: Sat, 26 Jul 2003 17:36:01 -0500 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: <3F22F94A.7030401@v.loewis.de> References: <20030722204201.11589.74038.Mailman@mail.python.org> <20030723163450.E22274@lannert.rz.uni-duesseldorf.de> <16162.42452.940978.48426@montanaro.dyndns.org> <3F22F94A.7030401@v.loewis.de> Message-ID: <16163.593.704035.46802@montanaro.dyndns.org> Martin> 3. Zooko's problem also was *not* related to /usr Not in my quoting or yours, but I thought there was some mention of /usr/lib/db4.so in that thread or on the bug tracker. In any case, we have been asked in the past to add /usr/lib and /usr/include to the search directories. Skip From tim.one@comcast.net Sun Jul 27 00:00:30 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 26 Jul 2003 19:00:30 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: Message-ID: [Kurt B. Kaiser] > [KBK] >> Two separate issues: > >> 1. Failure of IDLE to initialize its subprocess doesn't result in a >> message visible to the user. > > A message can be displayed to the user if we configure the Windows > installer to bind the IDLE icon to python.exe instead of pythonw.exe. > That way a DOS box will open behind IDLE and any messages will be > visible there. This is a small patch. Sorry, that one isn't a possibility. After 3 years and 50 comments and at least a dozen attempts by Tk wizards to fix it, I finally gave up on this bug report, and closed it as hopeless: Programs using Tkinter sometimes can't shut down (Windows) http://www.python.org/sf/216289 The only known workaround is never opening Tcl/Tk clients with python.exe. From tim.one@comcast.net Sun Jul 27 00:27:53 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 26 Jul 2003 19:27:53 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <200307261805.20985.aleaxit@yahoo.com> Message-ID: [Alex Martelli] > Just brainstorming...: in the Windows installer (if a suitable place > can be found); If someone can suggest newbie-comprehensible text, I think that's a good idea. It's easy enough to add a new dialog to the installer, and I'd insert this as the first dialog presented. People who have installed Python before would notice it then, since it would be both the first thing they see, and brand new. From tim.one@comcast.net Sun Jul 27 00:45:27 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 26 Jul 2003 19:45:27 -0400 Subject: [Python-Dev] Re: 2.3.1 In-Reply-To: Message-ID: [Paul Moore] > Um. While I understand the issue involved, I find it hard to be quite > as convinced as this, that the issue is a bug. User perceptions aren't technical issues, so whether it's "a bug" doesn't really matter -- Python wants to be friendly to newbies, and even in areas their OS is hostile. > First of all, I would say that on a correctly functioning machine, > applications should be able to listen on, and send to, unprivileged > (> 1024) ports on the local machine (127.0.0.1). > > In that case, I don't see a bug in Python, or in IDLE. There may be > "bugs" in certain systems, whereby such ports are not available, but > that isn't Python's fault. Python has a long tradition of accepting the blame for system bugs it can reasonably hide. > In thinking about this, however, there *is* one major point which I > think needs to be considered. As I understand the issue, IDLE runs as > 2 processes which talk via a socket. I assume that it is not possible > for this socket to be used by anything *other* than IDLE - in > particular, random hackers can't use the open socket as a means of > exploit? Such a security hole would, indeed, be a major bug which > needs to be addressed. I don't know the answer, and agree it should be taken seriously. For example, a port that accepts arbitrary Python code and executes it is as dangerous as anything I can imagine. But I haven't studied the new IDLE code, and don't know what the risks are. > Assuming no such security hole, what remains is an education issue. > This is exacerbated by the tendency of some "personal firewall" > products to ask the user for his/her opinion on all sorts of otherwise > innocent network traffic - often the user has no way of giving an > informed opinion, and the question does nothing but foster paranoia. That's the life goal of "security geeks" . > Sure, the fact that people might ask "why is Python talking to the > internet?" is worrying. But surely the correct answer is to say > firmly, but in the politest possible way, "it's not - whatever gave > you the impression that it is, is mistaken". > > Explanatory dialogs might help for some people, but you risk hitting > the other problem, of annoying people who *do* understand what's going > on by looking patronising. I didn't understand why IDLE was "accessing the Internet" the first time I tried it, and I'll immodestly claim that I'm more computer-savvy than a solid 13.7% of Python's Windows users . I expect a one-time warning would only irritate those who love to be irritated, and there's no pleasing the unpleasable. From tim.one@comcast.net Sun Jul 27 00:54:44 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 26 Jul 2003 19:54:44 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: Message-ID: [Kurt B. Kaiser] > ... > A very restricted change to the code would be add the following > to the banner printed at the top of the shell when it starts (the > socket connection isn't made until the shell window opens): > > *************************************************************** > Personal firewall software may warn about the connection IDLE > makes to its subprocess using this computer's internal loopback > interface. This connection is not visible on any external > interface and no data is sent to or received from the Internet. > *************************************************************** > > This involves an addition to PyShell.py:PyShell.begin(), line 873. > > In addition, the .../idlelib/README.txt would be updated with the > same message w/o the asterisks. I think that's a great idea, and is all we really need for 2.3 final. Barry is the release manager now, so the final call is his, but I'm +1 on it. > These are not the final solutions. A pop-up for #1, everytime, and a > pop-up for #2 on first use would be introduced into 2.3.1. The above > banner could be retained even after the popup is implemented, though > I'm -1 on that. Final solutions can be argued over after the final release. On a box with multiple profiles, is the proposed "first use" pop-up relative to the first time IDLE is run, or to the first time a specific user runs IDLE? I don't even want to know the answer now (no time for this now), just trying to suggest there may be issues with clever approaches. Dirt-dumb is all we can consider for 2.3 final. From tim.one@comcast.net Sun Jul 27 01:01:37 2003 From: tim.one@comcast.net (Tim Peters) Date: Sat, 26 Jul 2003 20:01:37 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: <3F22FB39.4030502@v.loewis.de> Message-ID: [Martin v. Löwis] > I completely disagree. This code has been in IDLE for quite some time. > If it was a serious problem, it would have been reported before. Well, variations of it have been reported to Alex, and to me (via the Tutor list), and I experienced my own Windows Moment with it. I failed to act on the warnings I got, but reflection on the Tutor list strongly suggests it's going to be a major problem on Windows. Newbies don't generally download pre-release software (except by mistake), so I take the Tutor list report from someone who did very seriously indeed. Kurt's suggestion to add a message at the top of the IDLE shell window seems adequate and very low risk. From kbk@shore.net Sun Jul 27 02:20:41 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 21:20:41 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: ("Tim Peters"'s message of "Sat, 26 Jul 2003 19:27:53 -0400") References: Message-ID: "Tim Peters" writes: > If someone can suggest newbie-comprehensible text, I think that's a good > idea. It's easy enough to add a new dialog to the installer, and I'd insert > this as the first dialog presented. People who have installed Python before > would notice it then, since it would be both the first thing they see, and > brand new. Maybe use the text from the shell banner in Patch 778286. -- KBK From kbk@shore.net Sun Jul 27 02:28:09 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 21:28:09 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: ("Tim Peters"'s message of "Sat, 26 Jul 2003 19:54:44 -0400") References: Message-ID: "Tim Peters" writes: > [Kurt B. Kaiser] >> ... >> A very restricted change to the code would be add the following >> to the banner printed at the top of the shell when it starts (the >> socket connection isn't made until the shell window opens): >> >> *************************************************************** >> Personal firewall software may warn about the connection IDLE >> makes to its subprocess using this computer's internal loopback >> interface. This connection is not visible on any external >> interface and no data is sent to or received from the Internet. >> *************************************************************** >> >> This involves an addition to PyShell.py:PyShell.begin(), line 873. >> >> In addition, the .../idlelib/README.txt would be updated with the >> same message w/o the asterisks. > > I think that's a great idea, and is all we really need for 2.3 final. Barry > is the release manager now, so the final call is his, but I'm +1 on it. Submitted as Patch 778286, assigned to Barry. -- KBK From aahz@pythoncraft.com Sun Jul 27 02:32:06 2003 From: aahz@pythoncraft.com (Aahz) Date: Sat, 26 Jul 2003 21:32:06 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: References: Message-ID: <20030727013206.GA3944@panix.com> On Sat, Jul 26, 2003, Kurt B. Kaiser wrote: > "Tim Peters" writes: >> [Kurt B. Kaiser] >>> ... >>> A very restricted change to the code would be add the following >>> to the banner printed at the top of the shell when it starts (the >>> socket connection isn't made until the shell window opens): >>> >>> *************************************************************** >>> Personal firewall software may warn about the connection IDLE >>> makes to its subprocess using this computer's internal loopback >>> interface. This connection is not visible on any external >>> interface and no data is sent to or received from the Internet. >>> *************************************************************** >>> >>> This involves an addition to PyShell.py:PyShell.begin(), line 873. >>> >>> In addition, the .../idlelib/README.txt would be updated with the >>> same message w/o the asterisks. >> >> I think that's a great idea, and is all we really need for 2.3 final. Barry >> is the release manager now, so the final call is his, but I'm +1 on it. > > Submitted as Patch 778286, assigned to Barry. Go ahead and commit it; Barry's probably going to approve it, and it's one less thing for him to do. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From kbk@shore.net Sun Jul 27 02:52:17 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 21:52:17 -0400 Subject: [Python-Dev] Re: 2.3.1 In-Reply-To: ("Tim Peters"'s message of "Sat, 26 Jul 2003 19:45:27 -0400") References: Message-ID: "Tim Peters" writes: >> In thinking about this, however, there *is* one major point which I >> think needs to be considered. As I understand the issue, IDLE runs as >> 2 processes which talk via a socket. I assume that it is not possible >> for this socket to be used by anything *other* than IDLE - in >> particular, random hackers can't use the open socket as a means of >> exploit? Such a security hole would, indeed, be a major bug which >> needs to be addressed. > > I don't know the answer, and agree it should be taken seriously. For > example, a port that accepts arbitrary Python code and executes it is as > dangerous as anything I can imagine. But I haven't studied the new IDLE > code, and don't know what the risks are. An open execution server on an external interface is exploitable at the privilege level of the user which initiated it. At GvR request, the connection was reversed so that the execution server connects to the user's GUI process. If the local cracker manages to intercept the loopback interface (no external packets) he can then access IDLE's stdout and stderr streams in the user GUI. Once the subprocess makes a connection to the user process, no further connections are accepted. In practice this happens within a second of when the user process spawns the subprocess. This seems to have limited exploitablility. If further security is desired, a random number could be passed to the subprocess for authentication upon connection. Comments appreciated! -- KBK From kbk@shore.net Sun Jul 27 03:41:11 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 26 Jul 2003 22:41:11 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: <20030727013206.GA3944@panix.com> (Aahz's message of "Sat, 26 Jul 2003 21:32:06 -0400") References: <20030727013206.GA3944@panix.com> Message-ID: Aahz writes: > Go ahead and commit it; Barry's probably going to approve it, and > it's one less thing for him to do. Without objection, I'll apply this in half an hour, subject to Barry's backout. -- KBK From kbk@shore.net Sun Jul 27 05:20:03 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sun, 27 Jul 2003 00:20:03 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: ("Tim Peters"'s message of "Sat, 26 Jul 2003 19:00:30 -0400") References: Message-ID: "Tim Peters" writes: > Sorry, that one isn't a possibility. After 3 years and 50 comments and at > least a dozen attempts by Tk wizards to fix it, I finally gave up on this > bug report, and closed it as hopeless: > > Programs using Tkinter sometimes can't shut down (Windows) > http://www.python.org/sf/216289 > > The only known workaround is never opening Tcl/Tk clients with python.exe. OK, I've submitted patch 778323, copied below, which opens a Tk message box. This is a relatively low risk patch: 1. One line added to PyShell to set a timeout on the socket.accept(). In the case Alex raises, it's likely the user process will block waiting for the subprocess to connect, leaving a stuck process for the user to clean up. The timeout fixes that. 2. One line added to run.py which calls the Tk error message method. This line and the method only execute when a socket error is raised and the situation is already pretty bleak. Tested on XP and RH6.2. The text printed to sys.__stderr__ would get removed at 2.3.1. -- KBK Index: PyShell.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/PyShell.py,v retrieving revision 1.81 diff -c -p -r1.81 PyShell.py *** PyShell.py 27 Jul 2003 03:24:18 -0000 1.81 --- PyShell.py 27 Jul 2003 03:41:14 -0000 *************** class ModifiedInterpreter(InteractiveInt *** 349,354 **** --- 349,356 ---- sys.exit() self.spawn_subprocess() # Accept the connection from the Python execution server + ## XXX 26Jul03 KBK Should raise a Tk exception message on timeout + self.rpcclt.listening_sock.settimeout(20) self.rpcclt.accept() self.rpcclt.register("stdin", self.tkconsole) self.rpcclt.register("stdout", self.tkconsole.stdout) Index: run.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/run.py,v retrieving revision 1.25 diff -c -p -r1.25 run.py *** run.py 22 Jun 2003 07:52:56 -0000 1.25 --- run.py 27 Jul 2003 03:41:30 -0000 *************** def manage_socket(address): *** 103,112 **** --- 103,122 ---- + err[1] + ", retrying...." else: print>>sys.__stderr__, "\nConnection to Idle failed, exiting." + show_socket_error(err) global exit_now exit_now = True return server.handle_request() # A single request only + + def show_socket_error(err): + import Tkinter + import tkMessageBox + root = Tkinter.Tk() + root.withdraw() + msg = "Can't Connect to IDLE User Process: %s" + tkMessageBox.showerror("IDLE Subprocess Error", msg % err[1], parent=root) + root.destroy() def print_exception(): flush_stdout() Index: NEWS.txt =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/NEWS.txt,v retrieving revision 1.23 diff -c -p -r1.23 NEWS.txt *** NEWS.txt 27 Jul 2003 03:24:18 -0000 1.23 --- NEWS.txt 27 Jul 2003 04:02:46 -0000 *************** What's New in IDLE 1.0? *** 3,8 **** --- 3,11 ---- *Release date: 29-Jul-2003* + - Added a Tk error dialog to inform the user if the subprocess can't connect + to the user GUI process. Added a timeout to the latter's listening socket. + - Added a banner to the shell discussimg warnings possibly raised by personal firewall software. Added same comment to README.txt. From tim.one@comcast.net Sun Jul 27 06:06:03 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 27 Jul 2003 01:06:03 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: Message-ID: [Tim] >> If someone can suggest newbie-comprehensible text, I think that's a >> good idea. It's easy enough to add a new dialog to the installer, >> and I'd insert this as the first dialog presented. People who have >> installed Python before would notice it then, since it would be both >> the first thing they see, and brand new. [Kurt B. Kaiser] > Maybe use the text from the shell banner in Patch 778286. I will if it gets pursued, but I don't like the installer idea anymore, because you plan to do plenty already to warn IDLE users about these issues. From tim.one@comcast.net Sun Jul 27 06:17:51 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 27 Jul 2003 01:17:51 -0400 Subject: [Python-Dev] Re: 2.3.1 In-Reply-To: Message-ID: [Kurt B. Kaiser] > An open execution server on an external interface is exploitable at > the privilege level of the user which initiated it. Noting that Win9X systems offer no protection in this sense, then (there aren't any privilege levels -- anyone can do anything). > At GvR request, the connection was reversed so that the execution > server connects to the user's GUI process. > > If the local cracker manages to intercept the loopback interface > (no external packets) he can then access IDLE's stdout and stderr > streams in the user GUI. > > Once the subprocess makes a connection to the user process, no further > connections are accepted. In practice this happens within a second of > when the user process spawns the subprocess. I'm not sure I understand this claim. I just brought up IDLE. Now in a separate DOS box: >>> addr = 'localhost', 8833 >>> import time >>> time.sleep(5) # more than 1 second >>> import socket >>> s = socket.socket() >>> s.connect(addr) >>> Was that connection expected? > This seems to have limited exploitablility. If further security is > desired, a random number could be passed to the subprocess for > authentication upon connection. I suppose a randomized port number could be used too. I'm not worried -- but I tend not to worry much about such things. if-i-did-i-wouldn't-be-running-windows-ly y'rs - tim From ncoghlan@email.com Sun Jul 27 07:11:04 2003 From: ncoghlan@email.com (Nick Coghlan) Date: Sun, 27 Jul 2003 16:11:04 +1000 Subject: [Python-Dev] 2.3.1 In-Reply-To: References: Message-ID: <3F236CF8.7080101@iinet.net.au> Tim Peters wrote: > [Kurt B. Kaiser] > >>... >>A very restricted change to the code would be add the following >>to the banner printed at the top of the shell when it starts (the >>socket connection isn't made until the shell window opens): >> >>*************************************************************** >>Personal firewall software may warn about the connection IDLE >>makes to its subprocess using this computer's internal loopback >>interface. This connection is not visible on any external >>interface and no data is sent to or received from the Internet. >>*************************************************************** >> >>This involves an addition to PyShell.py:PyShell.begin(), line 873. >> >>In addition, the .../idlelib/README.txt would be updated with the >>same message w/o the asterisks. > > > I think that's a great idea, and is all we really need for 2.3 final. Barry > is the release manager now, so the final call is his, but I'm +1 on it. After seeing this thread, I experimented with 2.3c2 IDLE on my machine (Windows XP, with the free ZoneAlarm installed). The ZoneAlarm warning comes up *before* the Python Shell window opens - the shell Window doesn't open until after I click 'Yes'. If I click "No", the shell window never appears at all. So Kurt's suggestion may not help, if the firewall intercepts the outgoing connection _before_ the above message is made visible to the user. (I suspect Zone Alarm halts the entire process responsible for initiating the connection request) Details on the ZoneAlarm warning: The Destination IP is given as "127.0.0.1: Port 8833" and the connecting application is listed as "pythonw.exe". (I imagine the port number will vary for different configurations and so forth - at the moment its consistent for me, but that is no doubt due to the particular applications I currently happen to have running). The IP address and application name may be useful in the warnings for non-technical users (after all, they clicked on an "IDLE" icon - they may not have any idea what "pythonw" is) Unsurprisingly, Zone Alarm's Alert Advisor says nothing about what the program is, or why it is trying to access the network. I've submitted some feedback to them, suggesting it might be useful to point out in Alert Advisor that '127.0.0.1' means the connection is being made directly back to the current computer. This doesn't help anyone using a different firewall application, though (and it is questionable whether or not Zonelabs will do anything about it, anyway - it must be an issue they have come across before). Regards, Nick. -- Nick Coghlan | Brisbane, Australia ICQ#: 68854767 | ncoghlan@email.com Mobile: 0409 573 268 | http://www.talkinboutstuff.net "Let go your prejudices, lest they limit your thoughts and actions." From anna@aleax.it Sun Jul 27 08:41:41 2003 From: anna@aleax.it (Anna Ravenscroft) Date: Sun, 27 Jul 2003 09:41:41 +0200 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: References: Message-ID: <200307270941.41019.anna@aleax.it> On Sunday 27 July 2003 07:06 am, Tim Peters wrote: > [Tim] > > >> If someone can suggest newbie-comprehensible text, I think that's a > >> good idea. It's easy enough to add a new dialog to the installer, > >> and I'd insert this as the first dialog presented. People who have > >> installed Python before would notice it then, since it would be both > >> the first thing they see, and brand new. > > [Kurt B. Kaiser] > > > Maybe use the text from the shell banner in Patch 778286. + (Personal firewall software may warn about the connection IDLE makes to its + subprocess using this computer's internal loopback interface. This connection + is not visible on any external interface and no data is sent to or received + from the Internet.) I like this - it's clear and concise. And newbie-friendly enough, imho. > I will if it gets pursued, but I don't like the installer idea anymore, > because you plan to do plenty already to warn IDLE users about these > issues. So, excuse my caffeine-deficient brain: when is this message going to appear? On installation, or on first run of IDLE, or both? I hope it will appear on first run of IDLE, or both. I'm remembering my first installation of Python - I had no idea yet what IDLE was. I was starting from the point of "let's install it and play with it" and then started working my way through the tutorial... If a message came up in installation, I might look at it uncomprehendingly and continue on and then wonder what was going on when IDLE starts - and try to find that message again. If there's a place to look it up outside of IDLE's help (someone suggested the download page, others suggested the README), or better yet, a pop-up when IDLE first starts, before the firewall complains, I'd have felt much more comfortable. I think that eventually some code fix will be necessary to handle the firewall issues. But, the notice is certainly a great first step (and I think, sufficient for even us newbies). Just my $.03 worth, Anna Ravenscroft From martin@v.loewis.de Sun Jul 27 08:45:30 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 27 Jul 2003 09:45:30 +0200 Subject: [Python-Dev] bsddb3 test hang In-Reply-To: <16163.593.704035.46802@montanaro.dyndns.org> References: <20030722204201.11589.74038.Mailman@mail.python.org> <20030723163450.E22274@lannert.rz.uni-duesseldorf.de> <16162.42452.940978.48426@montanaro.dyndns.org> <3F22F94A.7030401@v.loewis.de> <16163.593.704035.46802@montanaro.dyndns.org> Message-ID: Skip Montanaro writes: > Not in my quoting or yours, but I thought there was some mention of > /usr/lib/db4.so in that thread or on the bug tracker. In any case, we have > been asked in the past to add /usr/lib and /usr/include to the search > directories. And indeed, we have satisfied this request for Python 2.3. Regards, Martin From kbk@shore.net Sun Jul 27 12:34:07 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sun, 27 Jul 2003 07:34:07 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: ("Tim Peters"'s message of "Sun, 27 Jul 2003 01:06:03 -0400") References: Message-ID: "Tim Peters" writes: > I will if it gets pursued, but I don't like the installer idea > anymore, because you plan to do plenty already to warn IDLE users > about these issues. Nick Coghlan points out that if Zone Alarm intercepts the connection the shell will not start. In that case the banner will not be displayed because the current implementation establishes the connection before opening the shell window. A way around this is to start with the -n switch, but that's not a practical solution, especially for Windows. It should be possible to pop up the notification dialog before that point in the code is reached, but that's left for 2.3.1. So a comment in the installer may be helpful. -- KBK From kbk@shore.net Sun Jul 27 12:37:19 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sun, 27 Jul 2003 07:37:19 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: (kbk@shore.net's message of "Sun, 27 Jul 2003 00:20:03 -0400") References: Message-ID: kbk@shore.net (Kurt B. Kaiser) writes: > OK, I've submitted patch 778323, copied below, which opens a Tk message box. I'll be off the net until Tuesday night. -- KBK From skip@mojam.com Sun Jul 27 13:00:22 2003 From: skip@mojam.com (Skip Montanaro) Date: Sun, 27 Jul 2003 07:00:22 -0500 Subject: [Python-Dev] Weekly Python Bug/Patch Summary Message-ID: <200307271200.h6RC0MG29407@manatee.mojam.com> Bug/Patch Summary ----------------- 402 open / 3917 total bugs (+26) 169 open / 2295 total patches (+4) New Bugs -------- Failures in test_macostools for --enable-unicode=ucs4 (2003-06-30) http://python.org/sf/763708 popen does not like filenames with spaces (2003-07-20) http://python.org/sf/774546 Non-ASCII characters bugs (2003-07-20) http://python.org/sf/774680 slow socket binding & netinfo lookups (2003-07-20) http://python.org/sf/774751 SSL bug in socketmodule.c using threads (2003-07-20) http://python.org/sf/774798 No syntax hilite on new file until saved as *.py (2003-07-21) http://python.org/sf/775012 2 problems with IDLE (2003-07-21) http://python.org/sf/775061 button methods tkButtonDown, etc don't work (2003-07-21) http://python.org/sf/775309 plistlib error handling (2003-07-21) http://python.org/sf/775321 OSX 'freeze' bug (2003-07-21) http://python.org/sf/775340 IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work (2003-07-21) http://python.org/sf/775353 bsddb3 hash craps out with threads (2003-07-21) http://python.org/sf/775414 Tooltip-window doesn't vanish if... (2003-07-22) http://python.org/sf/775535 idle.py doesn't accept ( in some cases (2003-07-22) http://python.org/sf/775541 Tk.quit leads to crash in python.exe (2003-07-22) http://python.org/sf/775544 change 0,1 to False,True in dict.has_key doc (2003-07-22) http://python.org/sf/775836 PythonLauncher has empty popup for interpreters (2003-07-22) http://python.org/sf/775878 fix test_grp failing on RedHat 6.2 (2003-07-22) http://python.org/sf/775964 Solaris error doing a print (2003-07-22) http://python.org/sf/775985 MacOS9: test_uu fails (2003-07-23) http://python.org/sf/776202 MacOS9: test_urllib fails (2003-07-23) http://python.org/sf/776203 MacOS9: test_strptime fails (2003-07-23) http://python.org/sf/776205 MacOS9: test_posixpath fails (2003-07-23) http://python.org/sf/776207 MacOS9: test_csv fails (2003-07-23) http://python.org/sf/776209 Regular expression failure of the sre engine (2003-07-23) http://python.org/sf/776311 Carbon.Snd module SPB constructor shadowed (2003-07-23) http://python.org/sf/776533 urllib: open_https generates wrong Authorize header (2003-07-23) http://python.org/sf/776542 PIL binary package missing jpeg support (pimp) (2003-07-23) http://python.org/sf/776600 readline should be in PackageManager database (2003-07-23) http://python.org/sf/776602 asyncore is broken for windows if connection is refused (2003-07-25) http://python.org/sf/777588 socketmodule.c connection handling incorect on windows (2003-07-25) http://python.org/sf/777597 Uninitialized variable used in Tools/faqwiz/faqwiz.py (2003-07-25) http://python.org/sf/777659 HIDDEN in Tkconstants.py (2003-07-25) http://python.org/sf/777664 CGIHTTPServer and urls (2003-07-25) http://python.org/sf/777848 test_ioctl fails (2003-07-25) http://python.org/sf/777867 minidom.py -- TypeError: object doesn't support slice assig (2003-07-25) http://python.org/sf/777884 Shared Python Library installed without link (2003-07-26) http://python.org/sf/778119 IDLE hangs when selecting "Edit with IDLE" from explorer (2003-07-27) http://python.org/sf/778400 New Patches ----------- making Python LC_NUMERIC agnostic (2003-07-20) http://python.org/sf/774665 fix problem in about dialog (2003-07-21) http://python.org/sf/775057 Cygwin test_netrc open mode patch (2003-07-22) http://python.org/sf/775777 new function 'islastline' in fileinput (2003-07-23) http://python.org/sf/776100 add SIGRTMIN, SIGRTMAX to signalmodule.c (2003-07-23) http://python.org/sf/776725 expose lowlevel setlocale (2003-07-24) http://python.org/sf/776854 Tk Dialog Upon Subprocess Socket Error (2003-07-26) http://python.org/sf/778323 Closed Bugs ----------- Circular reference in Index for frame (2002-05-10) http://python.org/sf/554750 zipimport doesn't support prepended junk (2003-01-16) http://python.org/sf/669036 ioctl only accepts 1024 byte arguments (2003-06-29) http://python.org/sf/762855 pythonw crashes under one windows platform (easy-everything) (2003-07-01) http://python.org/sf/764049 PackMan reissues error messages (2003-07-02) http://python.org/sf/764615 PackMan: per-user source install of Numeric (2003-07-03) http://python.org/sf/765601 Binary installer says it will take 0 bytes of diskspace (2003-07-03) http://python.org/sf/765608 Packman crashes with garbage database (2003-07-03) http://python.org/sf/765621 Distutils broken on Os X (2003-07-09) http://python.org/sf/768306 nconsistant results for os.listdir,os.path.isdir on W2k (2003-07-17) http://python.org/sf/773286 2.3b2 pimp.py calls non-existent routine (2003-07-17) http://python.org/sf/773450 XP manifest files should be installed (2003-07-19) http://python.org/sf/774188 2.3c1 readme unparseable sentence (2003-07-20) http://python.org/sf/774480 UnicodeError (2003-07-20) http://python.org/sf/774536 Closed Patches -------------- fix memory leaks in posixmodule on Windows (2003-06-08) http://python.org/sf/751114 update old urls (2003-07-17) http://python.org/sf/773007 pimp.py incorrect dict test (2003-07-17) http://python.org/sf/773448 From aahz@pythoncraft.com Sun Jul 27 14:07:43 2003 From: aahz@pythoncraft.com (Aahz) Date: Sun, 27 Jul 2003 09:07:43 -0400 Subject: [Python-Dev] Draft: 2.3 download page Message-ID: <20030727130743.GA14543@panix.com> Here's a quick draft of the text for the 2.3 download page. Could someone please provide a list of the bugs we want to show up in the Known bugs section?

WARNING:

Consider waiting for Python 2.3 if you use IDLE or if you care about absolute stability. See "Known bugs" below for more info. Known bugs First of all, Python 2.3 is overall more stable than Python 2.2.3. There have been many bug fixes, and Python's extensive and growing suite of unit tests ensures that bugs rarely recur. However, bugs can and do show up in new code that has not yet been exercised in the Real World. Python 2.3's final release was in a schedule crunch because of a commitment to a release date for Apple Computer and OS X 10.3 (Panther), and several minor but critical bugs made it into the release. These bugs are minor because (except for IDLE) they are far from core Python code; they are critical because you will have problems if you run into them. We plan to release Python 2.3.1 within a month. We recommend downloading and using Python 2.3, but waiting for 2.3.1 if you're new to Python and plan to use IDLE or if you're using Python in a mission-critical application. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From skip@pobox.com Sun Jul 27 14:42:46 2003 From: skip@pobox.com (Skip Montanaro) Date: Sun, 27 Jul 2003 08:42:46 -0500 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <20030727130743.GA14543@panix.com> References: <20030727130743.GA14543@panix.com> Message-ID: <16163.54998.64120.609757@montanaro.dyndns.org> aahz> Here's a quick draft of the text for the 2.3 download page... aahz>

aahz> WARNING: aahz>

aahz> Consider waiting for Python 2.3 if you use IDLE or if you care about 2.3.1? ---------------^^^ aahz> absolute stability. See "Known bugs" below for more info. Skip From aahz@pythoncraft.com Sun Jul 27 14:48:03 2003 From: aahz@pythoncraft.com (Aahz) Date: Sun, 27 Jul 2003 09:48:03 -0400 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <16163.54998.64120.609757@montanaro.dyndns.org> References: <20030727130743.GA14543@panix.com> <16163.54998.64120.609757@montanaro.dyndns.org> Message-ID: <20030727134802.GA21484@panix.com> On Sun, Jul 27, 2003, Skip Montanaro wrote: > > aahz> Here's a quick draft of the text for the 2.3 download page... > > aahz>

> aahz> WARNING: > aahz>

> aahz> Consider waiting for Python 2.3 if you use IDLE or if you care about > 2.3.1? ---------------^^^ > aahz> absolute stability. See "Known bugs" below for more info. Whoops! That's what I get for writing first thing in the morning. Thanks. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From barry@python.org Sun Jul 27 16:35:10 2003 From: barry@python.org (Barry Warsaw) Date: 27 Jul 2003 11:35:10 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <3F22B814.1070000@ghaering.de> References: <200307261805.20985.aleaxit@yahoo.com> <200307261838.27595.anna@aleax.it> <3F22B814.1070000@ghaering.de> Message-ID: <1059320109.26800.0.camel@anthem> On Sat, 2003-07-26 at 13:19, Gerhard H=E4ring wrote: > Anna Ravenscroft wrote: > > [IDLE uses connections to localhost for interprocess communication; > > this triggers "security alerts" in some so-called "Personal Firewalls= "]=20 >=20 > http://www.fefe.de/pffaq/ explains this topic exhaustively. >=20 > I'll refrain from further comments about this "problem" for now, as I=20 > might regret them afterwards. I wouldn't want to link Python to something that calls the user an idiot in its second answer. -Barry From barry@python.org Sun Jul 27 16:39:27 2003 From: barry@python.org (Barry Warsaw) Date: 27 Jul 2003 11:39:27 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: References: <200307261805.20985.aleaxit@yahoo.com> Message-ID: <1059320366.26800.4.camel@anthem> On Sat, 2003-07-26 at 12:43, Kurt B. Kaiser wrote: > I'll send in a patch to .../idlelib/README.txt to add a comment about > this. The README is accessible from the About IDLE dialog available > on the Help menu so there's a /slight/ chance it might be read :-) As a point of order, Kurt, you have blanket authority to commit any changes to documentation related to this idle issue, at least up until code freeze sometime near 7pm EDT on Tuesday. If you think you need to make more extensive changes to idle before then, please let me and Tim know (at the least). It would suck to have idle broken in 2.3 final, but I don't think we can hold up the release for this. -Barry From barry@python.org Sun Jul 27 16:46:44 2003 From: barry@python.org (Barry Warsaw) Date: 27 Jul 2003 11:46:44 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: References: Message-ID: <1059320804.26800.7.camel@anthem> On Sat, 2003-07-26 at 19:54, Tim Peters wrote: > [Kurt B. Kaiser] > > ... > > A very restricted change to the code would be add the following > > to the banner printed at the top of the shell when it starts (the > > socket connection isn't made until the shell window opens): > > > > *************************************************************** > > Personal firewall software may warn about the connection IDLE > > makes to its subprocess using this computer's internal loopback > > interface. This connection is not visible on any external > > interface and no data is sent to or received from the Internet. > > *************************************************************** > > > > This involves an addition to PyShell.py:PyShell.begin(), line 873. > > > > In addition, the .../idlelib/README.txt would be updated with the > > same message w/o the asterisks. > > I think that's a great idea, and is all we really need for 2.3 final. Barry > is the release manager now, so the final call is his, but I'm +1 on it. Tim again proves his superior channeling skills. +1 and please go ahead and check this in. -Barry From barry@python.org Sun Jul 27 16:52:05 2003 From: barry@python.org (Barry Warsaw) Date: 27 Jul 2003 11:52:05 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: <20030726164547.GA987@panix.com> References: <20030726164547.GA987@panix.com> Message-ID: <1059321125.26800.12.camel@anthem> On Sat, 2003-07-26 at 12:45, Aahz wrote: > Given that the IDLE bug doesn't affect Apple (they don't ship Python > with Tkinter), I suggest that we not run around like chickens to fix the > IDLE bug, but plan on a 2.3.1 release by end of August. > > What I'd recommend doing for now is putting a big note on the 2.3 > download page (not on the front page as Anna suggests). > > This would also give us time to deal with some other nagging issues for > the 2.3 release while committing to a relatively short window for > getting them out. Aahz: please put something appropriate in pydotorg's 2.3/bugs.ht file. Kurt (or someone else), please add an entry in the Misc/NEWS file. I won't have much net access today until later tonight. This and Kurt's changes to idle should just about cover what we can do for 2.3 final. If we need a near-term 2.3.1 to slap the finishing touches on idle, so be it, but at least then we'll have breathing room to come up with the best (least worst) solution. -Barry From aleax@aleax.it Sun Jul 27 16:57:34 2003 From: aleax@aleax.it (Alex Martelli) Date: Sun, 27 Jul 2003 17:57:34 +0200 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <20030727130743.GA14543@panix.com> References: <20030727130743.GA14543@panix.com> Message-ID: <200307271757.34469.aleax@aleax.it> On Sunday 27 July 2003 15:07, Aahz wrote: ... > problems if you run into them. We plan to release Python 2.3.1 within a > month. We recommend downloading and using Python 2.3, but waiting for > 2.3.1 if you're new to Python and plan to use IDLE or if you're using > Python in a mission-critical application. I think this is too strongly worded, and will keep people away from 2.3 who would be quite happy with it. I would rephrase the last sentence as: """ We recommend downloading and using Python 2.3, but you may want to wait for 2.3.1 if you're new to Python and plan to use IDLE on Windows machines with easily mis-triggered "personal firewalls", or if you're using Python in a mission-critical application. """ BTW, the original problem with that Italian user also turned out to be a "personal firewall" bug. He had programmed his PFW to *not give warnings* (about attempted connections) when his remote connection to the net was off; the PFW erroneously *made all attempted connections fail* in this case (rather than letting ones to 127.0.0.1 succeed). When the remote connection was on, the PFW was using a different set of rules (which correctly included giving no warnings, and silently succeeding, for attempted connections to 127.0.0.1). He has now worked around his PFW's bug as well as let its producers know about it. But basically, to this point, it does seem that problems only occur for people using IDLE 1.0 on Windows machines *with easily mis-triggered personal firewalls*, so I see no need to issue a much broader, threatening-sounding warning that might turn off people who'd be quite happy using 2.3 as it stands. Alex From barry@python.org Sun Jul 27 17:00:21 2003 From: barry@python.org (Barry Warsaw) Date: 27 Jul 2003 12:00:21 -0400 Subject: [Python-Dev] Re: 2.3.1 In-Reply-To: References: <20030726164547.GA987@panix.com> <16162.49785.800687.878189@montanaro.dyndns.org> <200307262040.35424.aleax@aleax.it> Message-ID: <1059321621.26800.14.camel@anthem> On Sat, 2003-07-26 at 17:53, Paul Moore wrote: > Sure, the fact that people might ask "why is Python talking to the > internet?" is worrying. But surely the correct answer is to say > firmly, but in the politest possible way, "it's not - whatever gave > you the impression that it is, is mistaken". Adding text to bugs.html will at least give all the help@python.org volunteers something to quickly point to that will explain away all the FUD. :) -Barry From barry@python.org Sun Jul 27 17:09:37 2003 From: barry@python.org (Barry Warsaw) Date: 27 Jul 2003 12:09:37 -0400 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <20030727130743.GA14543@panix.com> References: <20030727130743.GA14543@panix.com> Message-ID: <1059322176.26800.20.camel@anthem> On Sun, 2003-07-27 at 09:07, Aahz wrote: > Here's a quick draft of the text for the 2.3 download page. Could > someone please provide a list of the bugs we want to show up in the > Known bugs section? > >

> WARNING: >

> Consider waiting for Python 2.3 if you use IDLE or if you care about > absolute stability. See "Known bugs" below for more info. > > Known bugs > > First of all, Python 2.3 is overall more stable than Python 2.2.3. > There have been many bug fixes, and Python's extensive and growing suite > of unit tests ensures that bugs rarely recur. However, bugs can and do > show up in new code that has not yet been exercised in the Real World. > Python 2.3's final release was in a schedule crunch because of a > commitment to a release date for Apple Computer and OS X 10.3 (Panther), > and several minor but critical bugs made it into the release. > > These bugs are minor because (except for IDLE) they are far from core > Python code; they are critical because you will have > problems if you run into them. We plan to release Python 2.3.1 within a > month. We recommend downloading and using Python 2.3, but waiting for > 2.3.1 if you're new to Python and plan to use IDLE or if you're using > Python in a mission-critical application. If I read this, I probably wouldn't touch Python 2.3 final with a 10 foot rigid boa. Why is it not sufficient to say, on index.html: Please note: running the new IDLE in Python 2.3 may produce spurious warnings from personal firewall software on some Windows machines. Please see the known bugs list for more information. Then on bugs.html, we provide more information, such as describing exactly what idle is doing without any fear mongering. Include a promise that we'll fix this for Python 2.3.1. People can then make up their own minds on whether they care enough, but at least we've informed them as best as possible before the fact. It doesn't sound to me like there are any problems preventing people from enjoying Python and idle on Windows right now, just that they'll get some confusing unexpected warnings. -Barry From tim.one@comcast.net Sun Jul 27 17:13:19 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 27 Jul 2003 12:13:19 -0400 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <20030727130743.GA14543@panix.com> Message-ID: [Aahz] > Here's a quick draft of the text for the 2.3 download page. Could > someone please provide a list of the bugs we want to show up in the > Known bugs section? > >

> WARNING: >

> Consider waiting for Python 2.3^H^H^H 2.3.1 if you use IDLE Why? Kurt may add more ways to spell warnings, but there's no reason to avoid 2.3's IDLE. Explain whatever issues remain instead. They're technically minor. They're just potentially surprising the first time you see one (if you see one at all). > or if you care about absolute stability. See "Known bugs" below for > more info. > > Known bugs > > First of all, Python 2.3 is overall more stable than Python 2.2.3. We don't know that, and it's almost certainly not true for people using new-in-2.3 code. > There have been many bug fixes, and Python's extensive and growing > suite of unit tests ensures that bugs rarely recur. However, bugs > can and do show up in new code that has not yet been exercised in the > Real World. Python 2.3's final release was in a schedule crunch > because of a commitment to a release date for Apple Computer and OS X > 10.3 (Panther), There wasn't a schedule crunch: 2.3 has been in the works since 22-Dec-2001 (the day after 2.2 final was released). That's 19 months of development, and the first 2.3 alpha was released 7 months ago. Saying there *was* a schedule crunch implies we're making excuses for pushing out a shoddy release, but there's nothing shoddy about it. If it appears to be suffering compared to previous PLabs releases, it's because Guido and Jeremy are missing, and the rest of PLabs has to carve all our efforts out of "spare time". This has acted to *drag out* the release process, though, not to rush it. There's certainly more of a harried tone in our email about release issues this time, but that's only because we can't afford the time to type about them <0.7 wink>. > and several minor but critical bugs made it into the release. They'll be backported to 2.2.4 too, if anyone cares to make the effort. > These bugs are minor because (except for IDLE) they are far from core > Python code; they are critical because you will have > problems if you run into them. We plan to release Python 2.3.1 > within a month. I'm sorry to say I can't commit to that. PythonLabs no longer exists, and future releases will have to be on a more relaxed schedule to the extent that the 5 former-PLabs geeks remain on release critical paths. > We recommend downloading and using Python 2.3, Yes. > but waiting for 2.3.1 if you're new to Python and plan to use IDLE I don't recommend that. > or if you're using Python in a mission-critical application. This is inconsistent with the earlier claim that "Python 2.3 is overall more stable than Python 2.2.3". That claim implies 2.3 is the most stable version in existence. Why would we recommend to avoid the most stable version for a mission-critical app? 2.3 final is in at least as good a shape as any major Python final release has ever been (which is saying a lot), and certainly in better shape than 2.2 final was in. In all, I'd like to see a lot less dubious negative editorializing in the release blurb. It's a major release long in the making, and it is (thanks to the efforts of everyone on Python-Dev, and to Guido's reluctance to add new features to the core language this time) probably the best major release Python has ever had. Even if it doesn't compile on a Cray SV1 running UNICOS . From tim.one@comcast.net Sun Jul 27 17:40:35 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 27 Jul 2003 12:40:35 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: <1059320109.26800.0.camel@anthem> Message-ID: [Gerhard Häring] >> http://www.fefe.de/pffaq/ explains this topic exhaustively. >> >> I'll refrain from further comments about this "problem" for now, as I >> might regret them afterwards. [Barry] > I wouldn't want to link Python to something that calls the user an > idiot in its second answer. Well, I certainly would, I only object because the referenced page isn't helpful . for-best-security-flip-the-off-switch-and-unplug-it-ly y'rs - tim From aleaxit@yahoo.com Sun Jul 27 18:12:28 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Sun, 27 Jul 2003 19:12:28 +0200 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: References: Message-ID: <200307271912.28661.aleaxit@yahoo.com> On Sunday 27 July 2003 06:13 pm, Tim Peters wrote: ... > > and several minor but critical bugs made it into the release. > > They'll be backported to 2.2.4 too, if anyone cares to make the effort. Backporting bugs is a novel concept (no time to type the appropriate wink fraction?-). > In all, I'd like to see a lot less dubious negative editorializing in the > release blurb. It's a major release long in the making, and it is (thanks > to the efforts of everyone on Python-Dev, and to Guido's reluctance to add > new features to the core language this time) probably the best major > release Python has ever had. Even if it doesn't compile on a Cray SV1 > running UNICOS . I entirely concur. Admittedly using only "major" platforms -- Linux on Intel-like CPU's, Windows -- I've been positively *amazed* at how solid and reliable 2.3 has felt for the last 6 months or so, and I've been unashamedly recommending it to everybody and their cousin. Alex From aleaxit@yahoo.com Sun Jul 27 18:16:31 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Sun, 27 Jul 2003 19:16:31 +0200 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <1059322176.26800.20.camel@anthem> References: <20030727130743.GA14543@panix.com> <1059322176.26800.20.camel@anthem> Message-ID: <200307271916.31864.aleaxit@yahoo.com> On Sunday 27 July 2003 06:09 pm, Barry Warsaw wrote: ... > > problems if you run into them. We plan to release Python 2.3.1 within a > > month. We recommend downloading and using Python 2.3, but waiting for > > 2.3.1 if you're new to Python and plan to use IDLE or if you're using > > Python in a mission-critical application. > > If I read this, I probably wouldn't touch Python 2.3 final with a 10 > foot rigid boa. Why is it not sufficient to say, on index.html: > > Please note: running the new IDLE in Python 2.3 may produce spurious > warnings from personal firewall software on some Windows machines. > Please see the known bugs list for more > information. +1 > Then on bugs.html, we provide more information, such as describing > exactly what idle is doing without any fear mongering. Include a > promise that we'll fix this for Python 2.3.1. People can then make up > their own minds on whether they care enough, but at least we've informed > them as best as possible before the fact. It doesn't sound to me like > there are any problems preventing people from enjoying Python and idle > on Windows right now, just that they'll get some confusing unexpected > warnings. Depends on their PFW if any -- how programmable it is, how programmed, how buggy. I do remember we advised people to turn anti-virus software entirely before running Python's installer on Windows (do we still do so? I don't recall, probably yes); the IDLE-vs-PFW clash is lesser (no need to turn the PFW off entirely, just make sure it does let connections to 127.0.0.1 work, one way or another) even though it will recur every time IDLE is started (and if we didn't document it clearly it might LOOK to the average uninitiated paranoid like we're trying to pull a fast one). Alex From whisper@oz.net Sun Jul 27 19:30:02 2003 From: whisper@oz.net (David LeBlanc) Date: Sun, 27 Jul 2003 11:30:02 -0700 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <200307271916.31864.aleaxit@yahoo.com> Message-ID: > Depends on their PFW if any -- how programmable it is, how programmed, > how buggy. I do remember we advised people to turn anti-virus software > entirely before running Python's installer on Windows (do we > still do so? I > don't recall, probably yes); the IDLE-vs-PFW clash is lesser (no > need to turn > the PFW off entirely, just make sure it does let connections to 127.0.0.1 > work, one way or another) even though it will recur every time IDLE is > started (and if we didn't document it clearly it might LOOK to > the average > uninitiated paranoid like we're trying to pull a fast one). > > > Alex > The PFW's I'm familiar with, Zone Alarm (ZA) and Tiny Personal Firewall (TPF), both pop up dialogs when unknown outbound connections are attempted. IIRC, both will allow clicking a button to add a rule allowing the connection (and, at least with TPF, making the rule a one time only or permanent rule). TPF also detects the replacement of an .exe file and asks whether it should be permitted or not (it has done this for Python x.x -> Python x.y updates the first time any TCP/IP use is attempted). Perhaps it need only be as simple as "If your PFW complains about your use of Idle, please allow it to create a rule permitting those connections to permit Idle to work correctly: no information will be sent outside of your computer". Dave LeBlanc Seattle, WA USA From Tino.Lange@isg.de Sun Jul 27 20:42:10 2003 From: Tino.Lange@isg.de (Tino Lange) Date: Sun, 27 Jul 2003 21:42:10 +0200 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <1059322176.26800.20.camel@anthem> References: <20030727130743.GA14543@panix.com> <1059322176.26800.20.camel@anthem> Message-ID: <3F242B12.3070101@isg.de> Aahz wrote: >>First of all, Python 2.3 is overall [...] mission-critical application. Barry Warsaw wrote: > If I read this, I probably wouldn't touch Python 2.3 final with a 10 > foot rigid boa. Why is it not sufficient to say, on index.html: > > [...] Then on bugs.html, [...] Hi! I agree with Barry - the text is "too hard" - and too honest. If I read this I'm sure I would at least think twice if I really should download & install 2.3 - or stay with my 2.1.3 for some more time. The actual Python 2.3 wouldn't deserve that :-) The "bug" only affects those people that a) have strange configured PFW on Windows b) use IDLE ... many Windows user will use PythonWin as default editor since they install the MH-Extensions on top. The installer will make PythonWin the default. Even if they use IDLE - in most cases they will see some kind of Firewall Information and/or question LOTS of programs do some socket stuff on startup. This is not unusual. Just a short "firewall compatibility note" should be enough. Cheers, Tino From tim.one@comcast.net Sun Jul 27 21:30:29 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 27 Jul 2003 16:30:29 -0400 Subject: [Python-Dev] 2.3.1 In-Reply-To: <3F236CF8.7080101@iinet.net.au> Message-ID: [ncoghlan@email.com] > After seeing this thread, I experimented with 2.3c2 IDLE on my > machine (Windows XP, with the free ZoneAlarm installed). The > ZoneAlarm warning comes up *before* the Python Shell window opens - > the shell Window doesn't open until after I click 'Yes'. If I click > "No", the shell window never appears at all. All true. I've added an IDLE section to the main NEWS file, and populated it with this blurb: """ - IDLE displays a new message upon startup: some "personal firewall" kinds of programs (for example, ZoneAlarm) open a dialog of their own when any program opens a socket. IDLE does use sockets, talking on the computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. So, if you get such a dialog when opening IDLE, asking whether to let pythonw.exe talk to address 127.0.0.1, say yes, and rest assured no communication external to your machine is taking place. If you don't allow it, IDLE won't be able to start. """ Note that similar dialogs have always popped up for users with this kind of software who tried the "Module Docs" menu shortcut (on Windows) to launch pydoc's Tk interface. It occurs to me now that that's why I didn't think much of it when IDLE started provoking the same behavior. From tim.one@comcast.net Sun Jul 27 21:37:58 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 27 Jul 2003 16:37:58 -0400 Subject: [Python-Dev] 2.3rc2 IDLE problems on a Win2000sp3 box In-Reply-To: Message-ID: [Kurt B. Kaiser] > Nick Coghlan points out that if Zone Alarm intercepts the connection > the shell will not start. In that case the banner will not be > displayed because the current implementation establishes the > connection before opening the shell window. Right. > ... > > It should be possible to pop up the notification dialog before that > point in the code is reached, but that's left for 2.3.1. > > So a comment in the installer may be helpful. I'm going to skip that. Installer changes have a way of breaking unexpectedly on Finnish Windows XP service pack 2 <0.6 wink>, and adding a new dialog requires tedious non-local changes (e.g., the current first dialog has to grow a new "back" button then) -- in all, it's more code fiddling than I had hoped. Also, as Anna pointed out, true newbies would have no idea what the installer blurb is talking about. I added a melding of your and Nick's text to NEWS.txt instead. That should be enough (IMO). From tim.one@comcast.net Sun Jul 27 21:54:42 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 27 Jul 2003 16:54:42 -0400 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: <020901c35236$e5576f10$f502a8c0@eden> Message-ID: [Mark Hammond] > This seems to be coming to a conclusion. Not a completely > satisfactory one, but one nonetheless. > > Short story for the python-dev crew: > > * Some Windows programs are known to run with the CRT locale set to > other than "C" - specifically, set to the locale of the user. > * If this happens, the marshal module will load floating point > literals incorrectly. Well, it depends on the locale, and on the fp literals in question, but it's often the case that damage occurs. > * Thus, once this happens, if a .pyc file is imported, the floating > point literals in that .pyc are wrong. Confusion reigns. Yup -- and it's an excellent to-the-point summary! > The "best" solution to this probably involves removing Python being > dependent on the locale - there is even an existing patch for that. Kinda. > To the SpamBayes specifics: > ... > I have a version working for the original bug reporter. While on our > machines, we can reproduce the locale being switched at MAPILogon > time, my instrumented version also shows that for some people at > least, Outlook itself will also change it back some time before > delivering UI events to us. There's potentially another dark side to this story: if MS code is going out of its way to switch locale, it's presumably because some of MS's code wants to change the behavior of CRT routines to work "as expected" for the current user. So if we switch LC_NUMERIC back to "C", we *may* be creating problems for Outlook. I'll never stumble into this, since "C" locale and my normal locale are so similar (and have identical behavior in the LC_NUMERIC category). At least Win32's *native* notions of locale are settable on a per-thread basis; C's notion is a global hammer; it's unclear to me why MS's code is even touching C's notion. > ... > We *do* still have the "social" problem of what locale conventions to > use for Config files, but that has nothing to do with our tools... To the extent that Config files use Python syntax, they're least surprising if they stick to Python syntax. The locale pit is deep. For example, Finnish uses a non-breaking space to separate thousands "although fullstop may be used in monetary context". We'll end up with more code to cater to gratuitous locale differences than to identify spam <0.7 wink>. From tim.one@comcast.net Sun Jul 27 22:11:19 2003 From: tim.one@comcast.net (Tim Peters) Date: Sun, 27 Jul 2003 17:11:19 -0400 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: Message-ID: [martin@v.loewis.de] >>> Unfortunately, the "true" source of atof (i.e. from conv.obj) is not >>> shipped with MSVC :-( [Tim] >> Would that help us if we could get it? I'm not sure how. [Martin] > I would hope that some inner routine that does the actual construction > of the double is locale-independent, and takes certain details as > separate arguments. Then, this routine could be used, passing the "C" > specific parameters instead of those of the current locale. OK. I looked and couldn't find anything useful. The Win32 GetNumberFormat() call can be used to format numbers for locale-aware display, but I didn't find anything in the other direction. The info at http://www.microsoft.com/globaldev/getwr/steps/wrg_nmbr.mspx seems to imply Win32 apps have to roll their own numeric parsing, building on the raw info returned by GetLocaleInfo(). From martin@v.loewis.de Sun Jul 27 22:42:40 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 27 Jul 2003 23:42:40 +0200 Subject: [spambayes-dev] RE: [Python-Dev] RE: [Spambayes] Question (orpossibly a bug report) In-Reply-To: References: Message-ID: "Tim Peters" writes: > At least Win32's *native* notions of locale are settable on a > per-thread basis; C's notion is a global hammer; it's unclear to me why MS's > code is even touching C's notion. Because they want a locale-aware atof(), and there is no equivalent API function that uses the thread locale? Regards, Martin From aahz@pythoncraft.com Mon Jul 28 00:50:09 2003 From: aahz@pythoncraft.com (Aahz) Date: Sun, 27 Jul 2003 19:50:09 -0400 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <1059322176.26800.20.camel@anthem> References: <20030727130743.GA14543@panix.com> <1059322176.26800.20.camel@anthem> Message-ID: <20030727235009.GA26636@panix.com> On Sun, Jul 27, 2003, Barry Warsaw wrote: > > If I read this, I probably wouldn't touch Python 2.3 final with a 10 > foot rigid boa. Why is it not sufficient to say, on index.html: > > Please note: running the new IDLE in Python 2.3 may produce spurious > warnings from personal firewall software on some Windows machines. > Please see the known bugs list for more > information. Now that Alex has provided additional info, that's fine with me. Before, it looked like there might be a problem with IDLE on a standard setup. I'm busy this evening, but I should have /2.3/bugs.html updated tomorrow. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz From barry@python.org Mon Jul 28 03:42:15 2003 From: barry@python.org (Barry Warsaw) Date: 27 Jul 2003 22:42:15 -0400 Subject: [Python-Dev] Draft: 2.3 download page In-Reply-To: <20030727235009.GA26636@panix.com> References: <20030727130743.GA14543@panix.com> <1059322176.26800.20.camel@anthem> <20030727235009.GA26636@panix.com> Message-ID: <1059360135.26800.48.camel@anthem> On Sun, 2003-07-27 at 19:50, Aahz wrote: > Now that Alex has provided additional info, that's fine with me. > Before, it looked like there might be a problem with IDLE on a standard > setup. I'm busy this evening, but I should have /2.3/bugs.html updated > tomorrow. Great, thanks! -Barry From walter@livinglogic.de Mon Jul 28 11:55:25 2003 From: walter@livinglogic.de (=?ISO-8859-15?Q?Walter_D=F6rwald?=) Date: Mon, 28 Jul 2003 12:55:25 +0200 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <03Jul25.152012pdt."58611"@synergy1.parc.xerox.com> References: <03Jul25.152012pdt."58611"@synergy1.parc.xerox.com> Message-ID: <3F25011D.5060208@livinglogic.de> Bill Janssen wrote: > I get one test failure on Mac OS 10.2.6: > > test test_pwd failed -- Traceback (most recent call last): > File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values > self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) > KeyError: 'getpwuid(): uid not found' > > The passwd entry on which it fails looks perfectly normal, AFAICS. > We've got about 3500 entries in our passwd file, if that's of interest. Could you make a bug report on Sourceforge and assign it to me? Bye, Walter Dörwald From kiko@async.com.br Mon Jul 28 21:51:20 2003 From: kiko@async.com.br (Christian Reis) Date: Mon, 28 Jul 2003 17:51:20 -0300 Subject: [Python-Dev] RE: [Spambayes] Question (or possibly a bug report) In-Reply-To: References: <1ED4ECF91CDED24C8D012BCF2B034F13027ABDD8@its-xchg4.massey.ac.nz> Message-ID: <20030728205120.GC4236@async.com.br> On Thu, Jul 24, 2003 at 11:25:25PM -0400, Tim Peters wrote: > [Tony Meyer] > > Is this likely to become the case? (In 2.4, for example?) > > I think so, and maybe before that. Not in 2.3 final, but maybe in 2.3.1 -- > numeric locale problems can be catastrophic to Python programmers, so I'm > comfortable arguing the case for calling it a bugfix. Whether it happens > depends on who's willing and able to do the work, of course. There's a > patch pending on a Python tracker to do it, but that uses a pile of code > borrowed from glibc, and that's got problems of its own. FWIW, it's actually borrowed from glib (GTK+'s abstraction library), and we've got tacit permission to include it (and as soon as Alex Larsson is back from vacation, he'll most likely sign the contributor agreement). For details, see my PEP submission at http://www.async.com.br/~kiko/pep-numeric.txt Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL From janssen@parc.com Tue Jul 29 00:18:48 2003 From: janssen@parc.com (Bill Janssen) Date: Mon, 28 Jul 2003 16:18:48 PDT Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: Your message of "Mon, 28 Jul 2003 03:55:25 PDT." <3F25011D.5060208@livinglogic.de> Message-ID: <03Jul28.161853pdt."58611"@synergy1.parc.xerox.com> OK, done. It's 779218. Bill > I get one test failure on Mac OS 10.2.6: > > > > test test_pwd failed -- Traceback (most recent call last): > > File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values > > self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) > > KeyError: 'getpwuid(): uid not found' > > > > The passwd entry on which it fails looks perfectly normal, AFAICS. > > We've got about 3500 entries in our passwd file, if that's of interest. From barry@python.org Tue Jul 29 04:05:24 2003 From: barry@python.org (Barry Warsaw) Date: 28 Jul 2003 23:05:24 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <03Jul28.161853pdt."58611"@synergy1.parc.xerox.com> References: <03Jul28.161853pdt."58611"@synergy1.parc.xerox.com> Message-ID: <1059447923.28413.5.camel@anthem> On Mon, 2003-07-28 at 19:18, Bill Janssen wrote: > OK, done. It's 779218. > > Bill Thanks Bill. Is there a `+' in your /etc/passwd file? See 775964 -Barry From barry@python.org Tue Jul 29 05:04:45 2003 From: barry@python.org (Barry Warsaw) Date: 29 Jul 2003 00:04:45 -0400 Subject: [Python-Dev] Last priority >= 7 bug for Python 2.3 Message-ID: <1059451484.28413.24.camel@anthem> I've lowered the priority on a bunch of priority 7 bugs for Python 2.3, mostly because I think there's nothing we can do before the final release, and they don't seem to be show stoppers. The last one is 775985 but I'm nervous about this one. I haven't been able to reproduce this on Linux, and it seems a fairly obscure bug (reportedly $LANG envar has to be empty). I'm strongly inclined to lower it to priority 6 and leave it for a later patch release. Comments? -Barry From martin@v.loewis.de Tue Jul 29 05:42:36 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 29 Jul 2003 06:42:36 +0200 Subject: [Python-Dev] Last priority >= 7 bug for Python 2.3 In-Reply-To: <1059451484.28413.24.camel@anthem> References: <1059451484.28413.24.camel@anthem> Message-ID: Barry Warsaw writes: > The last one is 775985 but I'm nervous > about this one. I haven't been able to reproduce this on Linux, and it > seems a fairly obscure bug (reportedly $LANG envar has to be empty). > I'm strongly inclined to lower it to priority 6 and leave it for a later > patch release. > > Comments? It's a Solaris bug, and my patch is a work-around. It only matters for printing Unicode objects on the terminal, so feel free to defer this past 2.3. Regards, Martin From barry@python.org Tue Jul 29 13:15:00 2003 From: barry@python.org (Barry Warsaw) Date: 29 Jul 2003 08:15:00 -0400 Subject: [Python-Dev] Last priority >= 7 bug for Python 2.3 In-Reply-To: References: <1059451484.28413.24.camel@anthem> Message-ID: <1059480899.28413.37.camel@anthem> On Tue, 2003-07-29 at 00:42, Martin v. L=F6wis wrote: > Barry Warsaw writes: >=20 > > The last one is 775985 but I'm nervous > > about this one. I haven't been able to reproduce this on Linux, and = it > > seems a fairly obscure bug (reportedly $LANG envar has to be empty).=20 > > I'm strongly inclined to lower it to priority 6 and leave it for a la= ter > > patch release. > >=20 > > Comments? >=20 > It's a Solaris bug, and my patch is a work-around. It only matters for > printing Unicode objects on the terminal, so feel free to defer this > past 2.3. Thanks Martin. -Barry From manfred.stienstra@dwerg.net Tue Jul 29 18:08:04 2003 From: manfred.stienstra@dwerg.net (Manfred Stienstra) Date: 29 Jul 2003 19:08:04 +0200 Subject: [Python-Dev] Httplib Message-ID: <1059498484.7905.1.camel@tail.dwerg.net> Hi, I was wondering if gzip/compress support is planned for httplib? Manfred From barry@python.org Tue Jul 29 18:49:19 2003 From: barry@python.org (Barry Warsaw) Date: 29 Jul 2003 13:49:19 -0400 Subject: [Python-Dev] CVS Freeze Message-ID: <1059500959.5748.36.camel@yyz> I'm freezing the trunk of the CVS tree for the Python 2.3 release now, even though we won't cut the release for several more hours. Fred's already frozen the docs, and I really don't expect any new check-ins now anyway. -Barry From drifty@alum.berkeley.edu Tue Jul 29 18:54:33 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 29 Jul 2003 10:54:33 -0700 Subject: [Python-Dev] Httplib In-Reply-To: <1059498484.7905.1.camel@tail.dwerg.net> References: <1059498484.7905.1.camel@tail.dwerg.net> Message-ID: <3F26B4D9.3020704@ocf.berkeley.edu> Manfred Stienstra wrote: > Hi, > > I was wondering if gzip/compress support is planned for httplib? > Not that I am aware of. The best way to see if anyone has done the work is to check for a patch on SourceForge that already implements it. If not then chances are there are no specific plans for it (at least known publicly on python-dev). -Brett C. From janssen@parc.com Tue Jul 29 21:37:57 2003 From: janssen@parc.com (Bill Janssen) Date: Tue, 29 Jul 2003 13:37:57 PDT Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: Your message of "Mon, 28 Jul 2003 20:05:24 PDT." <1059447923.28413.5.camel@anthem> Message-ID: <03Jul29.133802pdt."58611"@synergy1.parc.xerox.com> Not in the sense that you mean, I think. There is one entry in it which contains a '+' among other text in the name of the entry. Bill > On Mon, 2003-07-28 at 19:18, Bill Janssen wrote: > > OK, done. It's 779218. > > > > Bill > > Thanks Bill. Is there a `+' in your /etc/passwd file? > > See 775964 > > -Barry > > From barry@python.org Tue Jul 29 21:49:26 2003 From: barry@python.org (Barry Warsaw) Date: 29 Jul 2003 16:49:26 -0400 Subject: [Python-Dev] RELEASED Python 2.3c2 In-Reply-To: <03Jul29.133802pdt."58611"@synergy1.parc.xerox.com> References: <03Jul29.133802pdt."58611"@synergy1.parc.xerox.com> Message-ID: <1059511766.5748.67.camel@yyz> On Tue, 2003-07-29 at 16:37, Bill Janssen wrote: > Not in the sense that you mean, I think. There is one entry in it > which contains a '+' among other text in the name of the entry. That probably doesn't matter. I think it's a plus (or a minus?) as the first character on the line. But we'll look into this more after 2.3 final goes out. Thanks, -Barry From barry@python.org Wed Jul 30 01:02:26 2003 From: barry@python.org (Barry A. Warsaw) Date: Tue, 29 Jul 2003 20:02:26 -0400 Subject: [Python-Dev] RELEASED Python 2.3 (final) Message-ID: <16167.2834.754645.707376@gargle.gargle.HOWL> On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.3 (final). Nineteen months in the making, Python 2.3 represents a commitment to stability and improved performance, with a minimum of new language features. Countless bugs and memory leaks have been fixed, many new and updated modules have been added, and the new type/class system introduced in Python 2.2 has been significantly improved. Python 2.3 can be up to 30% faster than Python 2.2. For more information on Python 2.3, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.3 Highlights of this new release include: - A brand new version of IDLE, the Python IDE, from the IDLEfork project at SourceForge. - Many new and improved library modules including: sets, heapq, datetime, textwrap, optparse, logging, bsddb, bz2, tarfile, ossaudiodev, itertools, platform, csv, timeit, shelve, DocXMLRPCServer, imaplib, imp, trace, and a new random number generator based on the highly acclaimed Mersenne Twister algorithm (with a period of 2**19937-1). Some obsolete modules have been deprecated. - New and improved built-ins including: o enumerate(): an iterator yielding (index, item) pairs o sum(): a new function to sum a sequence of numbers o basestring: an abstract base string type for str and unicode o bool: a proper type with instances True and False o compile(), eval(), exec: fully support Unicode, and allow input not ending in a newline o range(): support for long arguments (magnitude > sys.maxint) o dict(): new constructor signatures o filter(): returns Unicode when the input is Unicode o int() can now return long o isinstance(), super(): Now support instances whose type() is not equal to their __class__. super() no longer ignores data descriptors, except for __class__. o raw_input(): can now return Unicode objects o slice(), buffer(): are now types rather than functions - Many new doctest extensions, allowing them to be run by unittest. - Extended slices, e.g. "hello"[::-1] returns "olleh". - Universal newlines mode for reading files (converts \r, \n and \r\n all into \n). - Source code encoding declarations. (PEP 263) - Import from zip files. (PEP 273 and PEP 302) - FutureWarning issued for "unsigned" operations on ints. (PEP 237) - Faster list.sort() is now stable. - Unicode filenames on Windows. (PEP 227) - Karatsuba long multiplication (running time O(N**1.58) instead of O(N**2)). - pickle, cPickle, and copy support a new pickling protocol for more efficient pickling of (especially) new-style class instances. - The socket module now supports optional timeouts on all operations. - ssl support has been incorporated into the Windows installer. - Many improvements to Tkinter. Python 2.3 contains many other improvements, including the adoption of many Python Enhancement Proposals (PEPs). For details see: http://www.python.org/2.3/highlights.html Enjoy. happy-50th-birthday-geddy-ly y'rs, -Barry Barry Warsaw barry@python.org Python 2.3 Release Manager (and the PythonLabs team: Tim, Fred, Jeremy, and Guido) From hfastjava@yahoo.com Wed Jul 30 03:12:08 2003 From: hfastjava@yahoo.com (Hunter Peress) Date: Tue, 29 Jul 2003 19:12:08 -0700 (PDT) Subject: [Python-Dev] RE:Httplib [solution for gzip http lib] Message-ID: <20030730021208.71505.qmail@web41311.mail.yahoo.com> the bittorrent folks hacked together one. probably not complete. but its a start. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bittorrent/BitTorrent/BitTorrent/ see zurlib.py __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From python@rcn.com Wed Jul 30 03:18:54 2003 From: python@rcn.com (Raymond Hettinger) Date: Tue, 29 Jul 2003 22:18:54 -0400 Subject: [Python-Dev] RE:Httplib [solution for gzip http lib] References: <20030730021208.71505.qmail@web41311.mail.yahoo.com> Message-ID: <006d01c35640$ed3b7ba0$b7b7958d@oemcomputer> From: "Hunter Peress" > the bittorrent folks hacked together one. probably not complete. but its a start. > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bittorrent/BitTorrent/BitTorrent/ Please add that link to a feature request on SourceForge so it won't get lost for Py2.4 Raymond Hettinger ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# ################################################################# From drifty@alum.berkeley.edu Wed Jul 30 03:52:24 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Tue, 29 Jul 2003 19:52:24 -0700 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <16167.2834.754645.707376@gargle.gargle.HOWL> References: <16167.2834.754645.707376@gargle.gargle.HOWL> Message-ID: <3F2732E8.70205@ocf.berkeley.edu> Barry A. Warsaw wrote: > On behalf of the Python development team and the Python community, I'm > happy to announce the release of Python 2.3 (final). > Woohoo! I know I would like to thank Barry, Tim, and Jeremy for all playing some part of release manager for this. Now, it's time for Brett's Newbie Questions! When can we start doing 2.4 work on HEAD? I assume 2.3 will end up a maintenance branch that patches are to be back-ported to. If that is true, what is the tag name (I assume release23-maint)? What happens to 2.2 work? Since 2.3 will now be the last stable release should we even worry about backporting to 2.2? I know it has been said that 2.2 would be a very stable version that would be around for a while, but I think Martin said that once 2.3 was out we would not really worry about 2.2 . Are there any preset goals of 2.4? The only one I know of off the top of my head is to prevent Guido from getting a pie to the face at OSCON 2004. =) That is all I can think of off the top of my head. -Brett From fdrake@acm.org Wed Jul 30 04:02:32 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 29 Jul 2003 23:02:32 -0400 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <3F2732E8.70205@ocf.berkeley.edu> References: <16167.2834.754645.707376@gargle.gargle.HOWL> <3F2732E8.70205@ocf.berkeley.edu> Message-ID: <16167.13640.547146.10919@grendel.zope.com> Brett C. writes: > Woohoo! I know I would like to thank Barry, Tim, and Jeremy for all > playing some part of release manager for this. Yes, indeed! > When can we start doing 2.4 work on HEAD? I assume 2.3 will end up a > maintenance branch that patches are to be back-ported to. If that is > true, what is the tag name (I assume release23-maint)? 2.4 work can go on the head now as far as *I'm* concerned. 2.3 exists on a branch (release23-branch). > What happens to 2.2 work? Since 2.3 will now be the last stable release > should we even worry about backporting to 2.2? I know it has been said > that 2.2 would be a very stable version that would be around for a > while, but I think Martin said that once 2.3 was out we would not really > worry about 2.2 . I'm inclined to be a little more conservative than that. I'd be glad to see a 2.2.4 release toward the end of the year to fix up any minor niggles, but we should be really careful about it. I know I have one memory leak patch I need to backport to the release22-maint branch. > Are there any preset goals of 2.4? The only one I know of off the top > of my head is to prevent Guido from getting a pie to the face at OSCON > 2004. =) Actually, that might be something to see. ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake@acm.org Wed Jul 30 04:05:34 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 29 Jul 2003 23:05:34 -0400 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <16167.13640.547146.10919@grendel.zope.com> References: <16167.2834.754645.707376@gargle.gargle.HOWL> <3F2732E8.70205@ocf.berkeley.edu> <16167.13640.547146.10919@grendel.zope.com> Message-ID: <16167.13822.82876.622001@grendel.zope.com> I wrote: > I'm inclined to be a little more conservative than that. I'd be glad > to see a 2.2.4 release toward the end of the year to fix up any minor > niggles, but we should be really careful about it. I know I have one > memory leak patch I need to backport to the release22-maint branch. And I'll put my time where my mailer is: I'll volunteer to be the release manager. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From tim_one@email.msn.com Wed Jul 30 05:34:58 2003 From: tim_one@email.msn.com (Tim Peters) Date: Wed, 30 Jul 2003 00:34:58 -0400 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <3F2732E8.70205@ocf.berkeley.edu> Message-ID: [Brett] > ... > When can we start doing 2.4 work on HEAD? Wait for Barry to Pronounce on that; there may be some last-second release branch checkins that need to be merged back into the HEAD. > I assume 2.3 will end up a maintenance branch that patches are to be > back-ported to. Right. > If that is true, what is the tag name (I assume release23-maint)? If it's not release23-maint already, Barry will fix that . > What happens to 2.2 work? Since 2.3 will now be the last stable > release should we even worry about backporting to 2.2? I know it has > been said that 2.2 would be a very stable version that would be > around for a while, but I think Martin said that once 2.3 was out we > would not really worry about 2.2 . > > Are there any preset goals of 2.4? The only one I know of off the top > of my head is to prevent Guido from getting a pie to the face at OSCON > 2004. =) "Scratch your own itch." If you think 2.2.4 is a good idea, do some backporting for it; if Martin doesn't, that's cool too. I'm going to ignore the 2.2 line in my spare time (it doesn't scratch any itch I have). I don't know of concrete plans for 2.4 beyond finishing int/long unification; I expect Guido is going to need time to plot a new course given his new position and the dissolution of his group (although the observant have noticed that what PLabs does here has been dropping steadily since last year, we've been doing a pretty good job of maintaining an illusion of Pythonic vigor ). From martin@v.loewis.de Wed Jul 30 05:53:54 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 30 Jul 2003 06:53:54 +0200 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <3F2732E8.70205@ocf.berkeley.edu> References: <16167.2834.754645.707376@gargle.gargle.HOWL> <3F2732E8.70205@ocf.berkeley.edu> Message-ID: "Brett C." writes: > What happens to 2.2 work? Since 2.3 will now be the last stable > release should we even worry about backporting to 2.2? I know it has > been said that 2.2 would be a very stable version that would be around > for a while, but I think Martin said that once 2.3 was out we would > not really worry about 2.2 . Did I really say that? I would not mind making a 2.1.4 release, even. However, I don't think patches need to be backported to both 2.2 and 2.3 on a regular basis. Instead, if a patch seems "important enough" to whoever commits it, that person should back-port it right away, so that the release process for 2.2.4 does not involve a huge amount of backporting. If the PBF wants to have 2.2 more active than that, they would need to nominate a maintainer for it, IMO. Regards, Martin From barry@python.org Wed Jul 30 06:42:12 2003 From: barry@python.org (Barry Warsaw) Date: 30 Jul 2003 01:42:12 -0400 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <3F2732E8.70205@ocf.berkeley.edu> References: <16167.2834.754645.707376@gargle.gargle.HOWL> <3F2732E8.70205@ocf.berkeley.edu> Message-ID: <1059543732.11624.46.camel@anthem> On Tue, 2003-07-29 at 22:52, Brett C. wrote: > Woohoo! I know I would like to thank Barry, Tim, and Jeremy for all > playing some part of release manager for this. I'm just playing Monkey Release Boy here, but I think everyone will agree that Python 2.3 is a great release that would have been impossible without everyone on python-dev, pydotorg, etc. helping out. I'm so tired my XEmacs window is laughing at me, so forgive the rambling. :) But it is cool to see that Python is not only a model programming language, but a model open source community too. Thanks everyone! (man, software releases should have liner notes :) > Now, it's time for Brett's Newbie Questions! > > When can we start doing 2.4 work on HEAD? I assume 2.3 will end up a > maintenance branch that patches are to be back-ported to. If that is > true, what is the tag name (I assume release23-maint)? Now, and yes. The HEAD is currently open for Python 2.4 work and I just fiddled the version numbers. The maintenance branch is closed until Jack is finished with the MacOS9 release. He'll announce that and then he or I will fiddle those version numbers. The 2.3 maintenance branch is called "release23-branch". > What happens to 2.2 work? Since 2.3 will now be the last stable release > should we even worry about backporting to 2.2? I know it has been said > that 2.2 would be a very stable version that would be around for a > while, but I think Martin said that once 2.3 was out we would not really > worry about 2.2 . Good questions. I think the answers are going to be evident from the time and effort that people put into backporting. Isn't the PBF's mission (or part of it) to make sure that there's a very stable long lived Python 2.2 branch (Py-in-a-tie)? If so, how can they help with Python 2.2 maintenance going forward? > Are there any preset goals of 2.4? The only one I know of off the top > of my head is to prevent Guido from getting a pie to the face at OSCON > 2004. =) Yes, that should be our #1 priority! As soon as Guido gets his California legs, I'm sure he'll start posting about his overall plans for Python 2.4. Until then, get those PEPs rolling! As for how the process is going to be different now, your guess is as good as mine. As usual we'll make it up as we go along . key-of-e-ly y'rs, -Barry From barry@python.org Wed Jul 30 06:44:25 2003 From: barry@python.org (Barry Warsaw) Date: 30 Jul 2003 01:44:25 -0400 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <16167.13640.547146.10919@grendel.zope.com> References: <16167.2834.754645.707376@gargle.gargle.HOWL> <3F2732E8.70205@ocf.berkeley.edu> <16167.13640.547146.10919@grendel.zope.com> Message-ID: <1059543864.11624.49.camel@anthem> On Tue, 2003-07-29 at 23:02, Fred L. Drake, Jr. wrote: > Brett C. writes: > > Woohoo! I know I would like to thank Barry, Tim, and Jeremy for all > > playing some part of release manager for this. > > Yes, indeed! You too Fred! The documentation wouldn't be nearly as useful, pretty, or standards compliant without you! xhtml-ish-ly y'rs, -Barry From barry@python.org Wed Jul 30 06:46:44 2003 From: barry@python.org (Barry Warsaw) Date: 30 Jul 2003 01:46:44 -0400 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <16167.13822.82876.622001@grendel.zope.com> References: <16167.2834.754645.707376@gargle.gargle.HOWL> <3F2732E8.70205@ocf.berkeley.edu> <16167.13640.547146.10919@grendel.zope.com> <16167.13822.82876.622001@grendel.zope.com> Message-ID: <1059544004.11624.52.camel@anthem> On Tue, 2003-07-29 at 23:05, Fred L. Drake, Jr. wrote: > I wrote: > > I'm inclined to be a little more conservative than that. I'd be glad > > to see a 2.2.4 release toward the end of the year to fix up any minor > > niggles, but we should be really careful about it. I know I have one > > memory leak patch I need to backport to the release22-maint branch. > > And I'll put my time where my mailer is: I'll volunteer to be the > release manager. Yay! It's fun. Peter Gabriel once said that everyone should shave their head once in their life. If that's a little too drastic or scary, being a Python RM is the next best thing! shock-the-monkey-ly y'rs, -Barry From barry@python.org Wed Jul 30 06:53:16 2003 From: barry@python.org (Barry Warsaw) Date: 30 Jul 2003 01:53:16 -0400 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: References: Message-ID: <1059544395.11624.58.camel@anthem> On Wed, 2003-07-30 at 00:34, Tim Peters wrote: > Wait for Barry to Pronounce on that; there may be some last-second release > branch checkins that need to be merged back into the HEAD. Anything between release23-branch and r23 should be ported into the head, but it's probably best to wait until Jack's done with the Mac release. > > If that is true, what is the tag name (I assume release23-maint)? > > If it's not release23-maint already, Barry will fix that . Dang, I am tired. I mentioned in another message that the branch tag was release23-branch, and indeed that's what I created. I should have created the release23-maint branch, but I don't trust myself to do that tonight. If someone beats me to it tomorrow, that'd be fine. -Barry From apurv_anand@hotmail.com Wed Jul 30 10:55:43 2003 From: apurv_anand@hotmail.com (Apurv Anand) Date: Wed, 30 Jul 2003 15:25:43 +0530 Subject: [Python-Dev] Kindly remove me from the list Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C356AE.D7AC2FF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_000D_01C356AE.D7AC2FF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_000D_01C356AE.D7AC2FF0-- From Raymond Hettinger" Currently, zip() with no arguments raises an exception. Does anyone have objections to my having it return an empty list instead? A poster on comp.lang.python raised some valid objections to the current behavior and I see no use case for wanting to have an exception instead of a useful return value. zip() --> [] would make the zip function more useful and predictable when used with variable length argument lists: def transpose(matrix): return zip(*matrix) On python-dev, when other features have been implemented, there have been discussions about whether zero cases should raise an exception or have a return value that is a more natural extension of the non-zero cases. I believe the resolution was typically to choose the latter (i.e. '' in 'abc'). This allows the patterns to extend more naturally: >>> zip('abc', range(3)) [('a', 0), ('b', 1), ('c', 2)] >>> zip('abc') [('a',), ('b',), ('c',)] >>> zip() [] FWIW, I've tried it out and found that it only touches a couple of lines of C, it breaks no test cases other than the two which serve to verify the current behavior; my existing apps and downloaded python apps all run fine. IOW, while it is a backwards incompatible change, I do not expect to find more than a modicum of existing code relying on an exception from zip() with no arguments. Another nice side benefit is that it simplifies the documentation and makes zip() easier to learn in the first place. Code surrounding a zip(*args) becomes more clear without a surrounding try/except. Avoiding unnecessary exceptions is part of the reason for methods like dict.get(k) which make coding a little more straight-forward. Raymond Hettinger From skip@pobox.com Wed Jul 30 14:08:39 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 30 Jul 2003 08:08:39 -0500 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: References: <3F2732E8.70205@ocf.berkeley.edu> Message-ID: <16167.50007.979138.373546@montanaro.dyndns.org> Tim> "Scratch your own itch." If you think 2.2.4 is a good idea, do Tim> some backporting for it; if Martin doesn't, that's cool too. I'm Tim> going to ignore the 2.2 line in my spare time (it doesn't scratch Tim> any itch I have). I thought 2.2 was supposed to be Py-in-a-tie. I would think 2.2.4 would scratch the Python Business Forum's itch. Is there anybody from that august group listening to python-dev who can speak up about their plans? Skip From aleaxit@yahoo.com Wed Jul 30 14:30:56 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Wed, 30 Jul 2003 15:30:56 +0200 Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <16167.50007.979138.373546@montanaro.dyndns.org> References: <3F2732E8.70205@ocf.berkeley.edu> <16167.50007.979138.373546@montanaro.dyndns.org> Message-ID: <200307301530.56483.aleaxit@yahoo.com> On Wednesday 30 July 2003 03:08 pm, Skip Montanaro wrote: > Tim> "Scratch your own itch." If you think 2.2.4 is a good idea, do > Tim> some backporting for it; if Martin doesn't, that's cool too. I'm > Tim> going to ignore the 2.2 line in my spare time (it doesn't scratch > Tim> any itch I have). > > I thought 2.2 was supposed to be Py-in-a-tie. I would think 2.2.4 would > scratch the Python Business Forum's itch. Is there anybody from that > august group listening to python-dev who can speak up about their plans? The current proposal in the PBF mailing list is to move to 2.3 as "Python in a tie" as soon as 2.3's stability/solidity is widely confirmed. I have heard no voices against that idea so far, and just a few in favour (in July and/or August most European business slows down due to vacations, and most PBF members are in Europe). How that would play (in terms of time and dates) with the timing of a 2.2.4 release, I don't know. Alex From barry@python.org Wed Jul 30 15:20:11 2003 From: barry@python.org (Barry Warsaw) Date: 30 Jul 2003 10:20:11 -0400 Subject: [Python-Dev] zip() in Py2.4 In-Reply-To: <009801c3569b$05b6ede0$b7b7958d@oemcomputer> References: <009801c3569b$05b6ede0$b7b7958d@oemcomputer> Message-ID: <1059574811.30752.5.camel@yyz> On Wed, 2003-07-30 at 09:00, Raymond Hettinger wrote: > Currently, zip() with no arguments raises an exception. > Does anyone have objections to my having it return an > empty list instead? Raymond, I remember that we made an explicit decision for zero arg zip() to raise an exception, but I don't remember what the rationale was. Can you go back into the archives and see if you can find that discussion (I believe zip() predates the peps). -Barry From Paul.Moore@atosorigin.com Wed Jul 30 15:31:15 2003 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Wed, 30 Jul 2003 15:31:15 +0100 Subject: [Python-Dev] zip() in Py2.4 Message-ID: <16E1010E4581B049ABC51D4975CEDB8802C0964B@UKDCX001.uk.int.atosorigin.com> From: Barry Warsaw [mailto:barry@python.org] > Raymond, I remember that we made an explicit decision for zero arg = zip() > to raise an exception, but I don't remember what the rationale was. = Can > you go back into the archives and see if you can find that discussion = (I > believe zip() predates the peps). It's PEP 201, and that contains a statement that Guido pronounced explicitly on 0-arg zip producing an exception. Sadly, there's no rationale given (but Guido doesn't need one :-)) Paul. From barry@python.org Wed Jul 30 15:49:42 2003 From: barry@python.org (Barry Warsaw) Date: 30 Jul 2003 10:49:42 -0400 Subject: [Python-Dev] zip() in Py2.4 In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8802C0964B@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8802C0964B@UKDCX001.uk.int.atosorigin.com> Message-ID: <1059576582.30752.16.camel@yyz> On Wed, 2003-07-30 at 10:31, Moore, Paul wrote: > It's PEP 201 Phhfff. You'da thought I'd have remembered that. ;) -Barry From mnot@mnot.net Wed Jul 30 16:38:13 2003 From: mnot@mnot.net (Mark Nottingham) Date: Wed, 30 Jul 2003 08:38:13 -0700 Subject: [Python-Dev] A syntax for function attributes? Message-ID: PEP 232 lists syntactic support for function attributions to be a possible future direction. I would very much like to use function attributes for associating metadata with functions and methods, but the lack of such syntactic support precludes their use, so I end up (ab)using __doc__. Has there been much further consideration of this issue? I'm not too particular about the chosen syntax, I just need something that doesn't require qualification with the function name (which tends to reduce readability/typeability, in some cases drastically so). I'm happy to write a PEP if that will help, but wanted to get a sense of what people's thinking was. Cheers, [ pls cc: me in responses ] From jacobs@penguin.theopalgroup.com Wed Jul 30 16:43:42 2003 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Wed, 30 Jul 2003 11:43:42 -0400 (EDT) Subject: [Python-Dev] RELEASED Python 2.3 (final) In-Reply-To: <16167.50007.979138.373546@montanaro.dyndns.org> Message-ID: On Wed, 30 Jul 2003, Skip Montanaro wrote: > Tim> "Scratch your own itch." If you think 2.2.4 is a good idea, do > Tim> some backporting for it; if Martin doesn't, that's cool too. I'm > Tim> going to ignore the 2.2 line in my spare time (it doesn't scratch > Tim> any itch I have). > > I thought 2.2 was supposed to be Py-in-a-tie. I would think 2.2.4 would > scratch the Python Business Forum's itch. Is there anybody from that august > group listening to python-dev who can speak up about their plans? This exact question is being discussed on the PBF mailing list. My vote was to go with 2.3 once it has been better battle-tested and major applications are ported to it. -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From barry@python.org Wed Jul 30 17:05:00 2003 From: barry@python.org (Barry Warsaw) Date: 30 Jul 2003 12:05:00 -0400 Subject: [Python-Dev] A syntax for function attributes? In-Reply-To: References: Message-ID: <1059581100.30752.78.camel@yyz> On Wed, 2003-07-30 at 11:38, Mark Nottingham wrote: > PEP 232 lists syntactic support for function attributions to be a > possible future direction. I would very much like to use function > attributes for associating metadata with functions and methods, but the > lack of such syntactic support precludes their use, so I end up > (ab)using __doc__. > > Has there been much further consideration of this issue? I'm not too > particular about the chosen syntax, I just need something that doesn't > require qualification with the function name (which tends to reduce > readability/typeability, in some cases drastically so). > > I'm happy to write a PEP if that will help, but wanted to get a sense > of what people's thinking was. Function attributes of course already exist. They seem like they'd be really cool to use . But I agree. I think we did well not introducing new syntax for Python 2.3 so we owe it to ourselves to break that bad habit. :) I'd also like to see syntactic support for method annotations, hooking into descriptors. I've been using a lot of properties in some recent code and while they are very very cool (and IMO improve Python in some important ways), they are still too tedious to use. I think the method annotation idea would be an elegant addition. -Barry From python@rcn.com Wed Jul 30 17:08:09 2003 From: python@rcn.com (Raymond Hettinger) Date: Wed, 30 Jul 2003 12:08:09 -0400 Subject: [Python-Dev] zip() in Py2.4 References: <16E1010E4581B049ABC51D4975CEDB8802C0964B@UKDCX001.uk.int.atosorigin.com> Message-ID: <00cc01c356b4$c525d9c0$b7b7958d@oemcomputer> [Barry Warsaw] > Raymond, I remember that we made an explicit decision for zero arg zip() > to raise an exception, but I don't remember what the rationale was. Can > you go back into the archives and see if you can find that discussion (I > believe zip() predates the peps). ["Moore, Paul"] It's PEP 201, and that contains a statement that Guido pronounced explicitly on 0-arg zip producing an exception. Sadly, there's no rationale given (but Guido doesn't need one :-)) After Guido gets settled in, I'll see if the California air has changed his thinking. If it hasn't, I'll at least get the rationale documented. Raymond Hettinger From jepler@unpythonic.net Wed Jul 30 17:20:36 2003 From: jepler@unpythonic.net (Jeff Epler) Date: Wed, 30 Jul 2003 11:20:36 -0500 Subject: [Python-Dev] A syntax for function attributes? In-Reply-To: References: Message-ID: <20030730162036.GB5692@unpythonic.net> On Wed, Jul 30, 2003 at 08:38:13AM -0700, Mark Nottingham wrote: > I'm happy to write a PEP if that will help, but wanted to get a sense > of what people's thinking was. Well, if a function-modifier syntax is adopted (most frequently discussed in forms like def f() [modifier, modifier]: pass ) then a function-attribute modifier could sure be written: def attributes(**kw): def _attributes(f): for k, v in kw.iteritems(): setattr(f, k, v) return f return _attributes and used as follows (my example being of the 'type-hint' variety): def sqr(x) [optimize, attributes( return_type = float, argument_type = (float,), pure = True)]: return x*x Of course, you could also do this: mathfunc = attribute(pure=true, return_type=float, argument_type=(float,)) def f(x) [optimze, mathfunc]: return x*x Or the grammar for the modifier-list could be modified to accept 'name = expr' and 'expr', treating the former as creating a function attribute, and the latter as giving a modifier function: def sqr(x) [optimize, return_type = float, argument_type = (float,), pure = True]: return x*x I don't think I'll be a big user of function attributes, as compared to function modifiers *cough*classmethod*cough*, so perhaps I'm wrong to think that the latter should be done as a special case of the former. Certainly the [attributes()] approach will be harder for a parse-only tool to take advantage of, especially in the face of things like 'mathfunc = attribute(...)'. Is this an important feature for function attributes to have? What other reasons are there for a distinct syntax? Jeff From mwh@python.net Wed Jul 30 17:26:44 2003 From: mwh@python.net (Michael Hudson) Date: Wed, 30 Jul 2003 17:26:44 +0100 Subject: [Python-Dev] A syntax for function attributes? In-Reply-To: <1059581100.30752.78.camel@yyz> (Barry Warsaw's message of "30 Jul 2003 12:05:00 -0400") References: <1059581100.30752.78.camel@yyz> Message-ID: <2mfzkoasl7.fsf@starship.python.net> Barry Warsaw writes: > On Wed, 2003-07-30 at 11:38, Mark Nottingham wrote: >> PEP 232 lists syntactic support for function attributions to be a >> possible future direction. I would very much like to use function >> attributes for associating metadata with functions and methods, but the >> lack of such syntactic support precludes their use, so I end up >> (ab)using __doc__. >> >> Has there been much further consideration of this issue? I'm not too >> particular about the chosen syntax, I just need something that doesn't >> require qualification with the function name (which tends to reduce >> readability/typeability, in some cases drastically so). >> >> I'm happy to write a PEP if that will help, but wanted to get a sense >> of what people's thinking was. > > Function attributes of course already exist. They seem like they'd be > really cool to use . Hmm, that's a surprise, coming from you :-) > But I agree. I think we did well not introducing new syntax for Python > 2.3 so we owe it to ourselves to break that bad habit. :) > > I'd also like to see syntactic support for method annotations, hooking > into descriptors. I've been using a lot of properties in some recent > code and while they are very very cool (and IMO improve Python in some > important ways), they are still too tedious to use. I think the method > annotation idea would be an elegant addition. Method annotations can be made to do function attributes: def attrs(**kw): def _(func): for k in kw: setattr(func, k, kw[k]) return func return _ def func() [attrs(a=1, b=42)]: pass but I don't recall how they do properties (and let's not have the "extended function syntax" thread again, please). Cheers, mwh -- Now this is what I don't get. Nobody said absolutely anything bad about anything. Yet it is always possible to just pull random flames out of ones ass. -- http://www.advogato.org/person/vicious/diary.html?start=60 From guido@python.net Wed Jul 30 17:55:13 2003 From: guido@python.net (Guido van Rossum) Date: Wed, 30 Jul 2003 12:55:13 -0400 Subject: [Python-Dev] Re: zip() in Py2.4 Message-ID: <20030730125513.A25538@starship.python.net> [Argh! My followup got swallowed by a disconnect.] The CA air is definitely cool, but I'm not quite settled -- I'm still living in a hotel room with my family, at least until Friday. My rationale for zip() refusing to be called without arguments is that this is more likely a mistake than intentional. Admittedly I hadn't foreseen using zip(*xxx). There are two sides to this. 1) Someone mistakenly types zip(). If they get an empty list, how confused will they be? Will their program finish with bogus output, or will the empty list cause a speedy failure? 2) How realistic is the use case for zip(*[])? --Guido From python@rcn.com Wed Jul 30 18:00:11 2003 From: python@rcn.com (Raymond Hettinger) Date: Wed, 30 Jul 2003 13:00:11 -0400 Subject: [Python-Dev] zip() in Py2.4 References: <16E1010E4581B049ABC51D4975CEDB8802C0964B@UKDCX001.uk.int.atosorigin.com> <00cc01c356b4$c525d9c0$b7b7958d@oemcomputer> <20030730122333.C22700@starship.python.net> Message-ID: <011001c356bc$0a923420$b7b7958d@oemcomputer> > > After Guido gets settled in, I'll see if the California air has > > changed his thinking. If it hasn't, I'll at least get the > > rationale documented. > > I don't know about the CA air (it's nice and col here though) > and I'm not quite settled yet (still living in a hotel room > with my family at least until Friday) but the rationale > is that I expect zip() to be called by mistake more likely > than with an intention. Now, the question is if that mistake > will be hidden by returning [] or not. IOW whether returning > [] causes a broken program to limp along with bogus data, > or whether it will cause a clear-enough error to happen next. > > What are typical use situations for zip(...) these days? The main use is still lockstep iteration in for-loops. If someone mistakenly omits a zip argument here, the mistake will still surface immediately with a [] return value: for timestamp, user, event in zip(): pass # never gets here because the tuple won't unpack Another use is for joining together keys/indices and values and then undoing the join (like a Schwarzian transform): >>> k = ('pear', 'apple', 'banana', 'coconut') >>> i = range(len(k)) >>> temp = zip(k, i) >>> temp [('pear', 0), ('apple', 1), ('banana', 2), ('coconut', 3)] >>> temp.sort() >>> fruits, indices = zip(*temp) >>> fruits ('apple', 'banana', 'coconut', 'pear') >>> indices (1, 2, 3, 0) Another use is a fast row/column switch in rectangular tables organized as lists of tuples. > Can you elaborate the case for zip() without arguments? Yes, it comes up whenever zip() is used with the * operator (as in the last two examples above). When there are variable length argument lists, it is helpful to have a smooth transition to the null case -- for instance a zero matrix used with: def transpose(mat): return zip(*mat) Transposing is a common first step in when reading CSV files so that the tuples (records) of non-homogenenous data can be re-grouped into homogenous data from each column position (field): dates, rainfall, hightemp, lowtemp = zip(*csv.reader(file("weather.csv"))) print 'Monthly total rainfall', sum(rainfall) Subsequent to the time the PEP was decided, I think the trend has been for python to handle null cases the same as regular cases and not raise exceptions. For instance, sum([]) returns 0 instead of demanding at least one addend. The star operator is also used in the unzip operation, described above as zip(*temp) in the Schwarzian transform example. Unzipping a reasonably common way of breaking out data aggregates. IOW, zip(*something) is handy for re-organizing data and the empty dataset should need not special case handling. This is especially true when data is built-up from the null case: mytable = [] gen_report(mytable) # don't have this raise an exception mytable.append(newrecord()) gen_report(mytable) mytable.append(newrecord()) gen_report(mytable) mytable.append(newrecord()) That about covers the subject. Raymond Hettinger From guido@python.net Wed Jul 30 18:26:39 2003 From: guido@python.net (Guido van Rossum) Date: Wed, 30 Jul 2003 13:26:39 -0400 Subject: [Python-Dev] zip() in Py2.4 In-Reply-To: <011001c356bc$0a923420$b7b7958d@oemcomputer>; from python@rcn.com on Wed, Jul 30, 2003 at 01:00:11PM -0400 References: <16E1010E4581B049ABC51D4975CEDB8802C0964B@UKDCX001.uk.int.atosorigin.com> <00cc01c356b4$c525d9c0$b7b7958d@oemcomputer> <20030730122333.C22700@starship.python.net> <011001c356bc$0a923420$b7b7958d@oemcomputer> Message-ID: <20030730132639.A26120@starship.python.net> > > What are typical use situations for zip(...) these days? > > The main use is still lockstep iteration in for-loops. > If someone mistakenly omits a zip argument here, the > mistake will still surface immediately with a [] return value: > > for timestamp, user, event in zip(): > pass # never gets here because the tuple won't unpack Hm... I worry about this case specifically, because it's easily imaginable that the intended list args were empty, and the code behaves the same way in that case. So if the code is written to cope with empty input, only careful testing will reveal the bug. > Another use is for joining together keys/indices and values > and then undoing the join (like a Schwarzian transform): > > >>> k = ('pear', 'apple', 'banana', 'coconut') > >>> i = range(len(k)) > >>> temp = zip(k, i) > >>> temp > [('pear', 0), ('apple', 1), ('banana', 2), ('coconut', 3)] > >>> temp.sort() > >>> fruits, indices = zip(*temp) > >>> fruits > ('apple', 'banana', 'coconut', 'pear') > >>> indices > (1, 2, 3, 0) That looks cute, but sounds inefficient when the list is 1000s of items long -- the zip(*temp) abuses the argument passing machinery. > Another use is a fast row/column switch in > rectangular tables organized as lists of tuples. But somehow that doesn't strike me as a very likely table organization. It can be a list of lists, too, but the transform changes it to a list of tuples. > > Can you elaborate the case for zip() without arguments? > > Yes, it comes up whenever zip() is used with the * operator > (as in the last two examples above). When there are > variable length argument lists, it is helpful to have a smooth > transition to the null case -- for instance a zero matrix used with: > > def transpose(mat): > return zip(*mat) Fair enough. > Transposing is a common first step in when reading CSV files > so that the tuples (records) of non-homogenenous data can be > re-grouped into homogenous data from each column position (field): > > dates, rainfall, hightemp, lowtemp = zip(*csv.reader(file("weather.csv"))) > print 'Monthly total rainfall', sum(rainfall) > > Subsequent to the time the PEP was decided, I think the trend has > been for python to handle null cases the same as regular cases and > not raise exceptions. For instance, sum([]) returns 0 instead of > demanding at least one addend. But max([]) raises an exception, and I think you'll agree that it should. It's not that I started recently paying attention to empty lists (I always treated them as first-class citizens), it's that I wasn't aware of zip(*xxx) as a common use case before. > The star operator is also used in the unzip operation, described > above as zip(*temp) in the Schwarzian transform example. > Unzipping a reasonably common way of breaking out data > aggregates. > > IOW, zip(*something) is handy for re-organizing data and the > empty dataset should need not special case handling. This is > especially true when data is built-up from the null case: > > mytable = [] > gen_report(mytable) # don't have this raise an exception > mytable.append(newrecord()) > gen_report(mytable) > mytable.append(newrecord()) > gen_report(mytable) > mytable.append(newrecord()) > > > That about covers the subject. OK. While I still have some misgivings about the first example, I think I see that zip(*[]) should return []. It's OK for 2.4. --Guido From python@rcn.com Wed Jul 30 18:32:33 2003 From: python@rcn.com (Raymond Hettinger) Date: Wed, 30 Jul 2003 13:32:33 -0400 Subject: [Python-Dev] zip() in Py2.4 References: <16E1010E4581B049ABC51D4975CEDB8802C0964B@UKDCX001.uk.int.atosorigin.com> <00cc01c356b4$c525d9c0$b7b7958d@oemcomputer> <20030730122333.C22700@starship.python.net> <011001c356bc$0a923420$b7b7958d@oemcomputer> <20030730132639.A26120@starship.python.net> Message-ID: <013201c356c0$9028ac00$b7b7958d@oemcomputer> > OK. While I still have some misgivings about the first example, > I think I see that zip(*[]) should return []. It's OK for 2.4. > > --Guido Would you like me to document this discussion in the PEP? Raymond From guido@python.net Wed Jul 30 18:43:45 2003 From: guido@python.net (Guido van Rossum) Date: Wed, 30 Jul 2003 13:43:45 -0400 Subject: [Python-Dev] zip() in Py2.4 In-Reply-To: <013201c356c0$9028ac00$b7b7958d@oemcomputer>; from python@rcn.com on Wed, Jul 30, 2003 at 01:32:33PM -0400 References: <16E1010E4581B049ABC51D4975CEDB8802C0964B@UKDCX001.uk.int.atosorigin.com> <00cc01c356b4$c525d9c0$b7b7958d@oemcomputer> <20030730122333.C22700@starship.python.net> <011001c356bc$0a923420$b7b7958d@oemcomputer> <20030730132639.A26120@starship.python.net> <013201c356c0$9028ac00$b7b7958d@oemcomputer> Message-ID: <20030730134345.B26120@starship.python.net> > Would you like me to document this discussion in the PEP? Please, go ahead. --Guido From patmiller@llnl.gov Wed Jul 30 19:45:16 2003 From: patmiller@llnl.gov (Pat Miller) Date: Wed, 30 Jul 2003 11:45:16 -0700 Subject: [Python-Dev] A syntax for function attributes? References: <1059581100.30752.78.camel@yyz> <2mfzkoasl7.fsf@starship.python.net> Message-ID: <3F28123C.2080807@llnl.gov> I can imagine lots of ways that these attributes can be useful and would like to see this extension in some form. If nothing else, they can be used to help guide optimizations. I can imagine: def sqr [inline=true](x): return x*x or def debug [debug_only=true](*messages): global debugging if debugging: print "DEBUG",' '.join([str(x) for x in messages]) return In the first case, maybe a bytecode inliner could move the code into a caller In the second case, if debugging were turned off, the function call could be made into a NOP. I think it essential to use some dense syntax. It would be messy if it were def sqr(x): return x*x sqr.inline = true Pat -- Patrick Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller Fanaticism consists of redoubling your efforts when you have forgotten your aim. -- George Santayana From Jack.Jansen@cwi.nl Wed Jul 30 22:46:49 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 30 Jul 2003 23:46:49 +0200 Subject: [Python-Dev] Python version number in file names Message-ID: <53071234-C2D7-11D7-8C4A-000A27B19B96@cwi.nl> Something that came up in the 2.3 alfa/beta/release cycle is that there is a buglet in our version numbering scheme. We use "major.minor" as the indicator of binary compatibility, and hence use "lib/python2.3" to put things, distutils uses "2.3" in its build directory and distribution filenames, etc. There are exceptions to this binary compatibility rule, however, and that are the alfa and beta releases: these are explicitly not guaranteed to be compatible. This problem has always existed, but as far as I know it was theoretical until Apple shipped a Python 2.3 beta with their Panther beta. All betas, but still this means that there is now a much bigger chance than their ever was of people trying to use things built for 2.3final with 2.3b2, or people building modules with 2.3b2 for quite some time, which others will then try to install into 2.3final. I think it's a good idea to fix this. I thought I had an algorithm to do this using '.'.join(version.split('.')[:2]) in stead of version[:3], but unfortunately this will make the release candidates also not use "python2.3", and I think for these we definitely want to use the final names. Still, an algorithm shouldn't be rocket science:-) Opinions? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From jafo-python-dev@tummy.com Thu Jul 31 00:23:47 2003 From: jafo-python-dev@tummy.com (Sean Reifschneider) Date: Wed, 30 Jul 2003 17:23:47 -0600 Subject: [Python-Dev] How to get the .spec file version number updated. Message-ID: <20030730232347.GB25476@tummy.com> What has to be done to make sure that the version number in the .spec file gets updated along with other files before pushing a release out? Is there a script I need to patch (or write) for this, or does the PEP template need to be changed or something? Thanks, Sean -- "All I'm saying is that when I'm around you I find myself showing off, which is the idiots version of being interesting." -- _LA_Story_ Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin From mhammond@skippinet.com.au Thu Jul 31 02:01:36 2003 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 31 Jul 2003 11:01:36 +1000 Subject: [Python-Dev] Switch to 2.4a0 on trunk? Message-ID: <004501c356ff$4b446a90$f502a8c0@eden> I notice that parts of the trunk are reporting themselves as Python 2.4, but other key parts for Windows are still Python 2.3 - eg, the DLL name, the PC\*.rc files, etc. Should I check code in to move everything to a 2.4 world on the trunk? And while I am asking, I am a little uncertain about the CVS tags. Can someone explain the distinction between release23-branch and release23-fork for me? Is there a branch that will track the "latest 2.3" for the next few years (ie, through 2.3.1, 2.3.2 etc?) Thanks, Mark. From tim.one@comcast.net Thu Jul 31 02:35:58 2003 From: tim.one@comcast.net (Tim Peters) Date: Wed, 30 Jul 2003 21:35:58 -0400 Subject: [Python-Dev] Switch to 2.4a0 on trunk? In-Reply-To: <004501c356ff$4b446a90$f502a8c0@eden> Message-ID: [Mark Hammond] > I notice that parts of the trunk are reporting themselves as Python > 2.4, but other key parts for Windows are still Python 2.3 - eg, the > DLL name, the PC\*.rc files, etc. > > Should I check code in to move everything to a 2.4 world on the trunk? Please do. I had hoped to do that, but a work crisis has me on the road and I won't be doing anything with Python this week. > And while I am asking, I am a little uncertain about the CVS tags. > Can someone explain the distinction between release23-branch and > release23-fork for me? Probably, but it doesn't matter . xyz-fork is just a tag on the HEAD, and xyz-branch is a branch that started life with the stuff with the xyz-fork tag. > Is there a branch that will track the "latest 2.3" for the next > few years (ie, through 2.3.1, 2.3.2 etc?) It doesn't appear that there is yet. Barry? It will be named release23-maint. From fdrake@acm.org Thu Jul 31 03:21:20 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 30 Jul 2003 22:21:20 -0400 Subject: [Python-Dev] How to get the .spec file version number updated. In-Reply-To: <20030730232347.GB25476@tummy.com> References: <20030730232347.GB25476@tummy.com> Message-ID: <16168.32032.656763.102665@grendel.zope.com> Sean Reifschneider writes: > What has to be done to make sure that the version number in the .spec > file gets updated along with other files before pushing a release out? > Is there a script I need to patch (or write) for this, or does the PEP > template need to be changed or something? An item needs to be added to each of the release process peps: PEP 101 Doing Python Releases 101 PEP 102 Doing Python Micro Releases Thanks for thinking about this! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From skip@pobox.com Thu Jul 31 05:40:23 2003 From: skip@pobox.com (Skip Montanaro) Date: Wed, 30 Jul 2003 23:40:23 -0500 Subject: [Python-Dev] Looking for a couple Emacs Lisp helper/guru types Message-ID: <16168.40375.103671.374290@montanaro.dyndns.org> Barry & Ken have run completely out of round tuits on which are written "python-mode". I believe Barry indicated privately that he is going to set up a SF project to allow other folks to contribute (maybe he's just going to give Python CVS developer privileges to anyone, he may be just that giddy after the 2.3 release). I have very little time as well and have very old, feeble Emacs Lisp skills to boot. Hell, I can't even get my Python files to save properly with tramp these days, and I never did like mapcar. I'm sure Barry will announce here and probably on c.l.py once the project's available, but in anticipation of that, if you are an Emacs or XEmacs person who uses python mode, please consider getting reacquainted with your inner functional self. Your parens will be so proud. Skip From martin@v.loewis.de Thu Jul 31 07:13:59 2003 From: martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) Date: 31 Jul 2003 08:13:59 +0200 Subject: [Python-Dev] Python version number in file names In-Reply-To: <53071234-C2D7-11D7-8C4A-000A27B19B96@cwi.nl> References: <53071234-C2D7-11D7-8C4A-000A27B19B96@cwi.nl> Message-ID: Jack Jansen writes: > Opinions? Please don't change Python-2.3-for-OSX to accomodate a beta that Apple had shipped. Regards, Martin From Jack.Jansen@oratrix.com Thu Jul 31 09:56:30 2003 From: Jack.Jansen@oratrix.com (Jack Jansen) Date: Thu, 31 Jul 2003 10:56:30 +0200 Subject: [Python-Dev] Python version number in file names In-Reply-To: Message-ID: On donderdag, jul 31, 2003, at 08:13 Europe/Amsterdam, Martin v. L=F6wis=20= wrote: > Jack Jansen writes: > >> Opinions? > > Please don't change Python-2.3-for-OSX to accomodate a beta that Apple > had shipped. Definitely not. I mustn't have phrased it right, I was wondering=20 whether we want to fix this for 2.4 and later. -- - Jack Jansen =20 http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma=20 Goldman - From harri.pasanen@trema.com Thu Jul 31 10:53:39 2003 From: harri.pasanen@trema.com (Harri Pasanen) Date: Thu, 31 Jul 2003 11:53:39 +0200 Subject: [Python-Dev] deadlock problem Message-ID: <200307311153.39665.harri.pasanen@trema.com> Hi, I'm having a deadlock on import in my embedded python 2.3rc2, on Win2000, built with Visual C++ 7.1. Having spent a fair amount of time going through the code, and various threads, it is still not clear to me if I'm hitting the problem described in the thread: http://mail.python.org/pipermail/python-dev/2003-February/033436.html or if I'm triggering it because of something else alltogether, as I'm only seeing the problem on Win2000, on Linux it works fine. Basically my code does this in one C level thread: PyGILState_STATE _tstate = PyGILState_Ensure (); PyObject* usermod = PyImport_ImportModule ("echo"); Where echo.py is just: print "ECHO" import time time.sleep(1) print "DONE" It never prints out "DONE". If I take away the sleep(), it finishes, printing DONE. running with THREADDEBUG=15, I'm getting the output below, and the last two lines leave me utterly puzzled, as if something would be quite wrong on my machine (Win2000 under VmWare Linux host). Why could the same thread be unable reacquire a lock it just held? PyThread_init_thread called 1084: PyThread_allocate_lock() -> 01647578 1084: PyThread_acquire_lock(01647578, 1) called 1084: PyThread_acquire_lock(01647578, 1) -> 1 1084: PyThread_release_lock(01647578) called 1084: PyThread_acquire_lock(01647578, 1) called 1084: PyThread_acquire_lock(01647578, 1) -> 1 1084: PyThread_release_lock(01647578) called PyThread_allocate_lock called 1084: PyThread_allocate_lock() -> 0164A280 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called PyThread_allocate_lock called 1084: PyThread_allocate_lock() -> 0256DD40 1084: PyThread_acquire_lock(0256DD40, 1) called 1084: PyThread_acquire_lock(0256DD40, 1) -> 1 1084: PyThread_release_lock(0256DD40) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called PyThread_allocate_lock called 1084: PyThread_allocate_lock() -> 01648DA8 1084: PyThread_acquire_lock(01648DA8, 1) called 1084: PyThread_acquire_lock(01648DA8, 1) -> 1 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_release_lock(01648DA8) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 1084: PyThread_release_lock(0164A280) called 1084: PyThread_acquire_lock(0164A280, 0) called 1084: PyThread_acquire_lock(0164A280, 0) -> 1 ECHO 1084: PyThread_release_lock(01648DA8) called 1084: PyThread_acquire_lock(01648DA8, 1) called Harri From oren-py-d@hishome.net Thu Jul 31 11:09:38 2003 From: oren-py-d@hishome.net (Oren Tirosh) Date: Thu, 31 Jul 2003 06:09:38 -0400 Subject: [Python-Dev] Re: zip() in Py2.4 In-Reply-To: <20030730125513.A25538@starship.python.net> References: <20030730125513.A25538@starship.python.net> Message-ID: <20030731100938.GA14826@hishome.net> On Wed, Jul 30, 2003 at 12:55:13PM -0400, Guido van Rossum wrote: ... > 2) How realistic is the use case for zip(*[])? About as realistic as the use case for '' in string. Oren From mcherm@mcherm.com Thu Jul 31 13:06:44 2003 From: mcherm@mcherm.com (Michael Chermside) Date: Thu, 31 Jul 2003 05:06:44 -0700 Subject: [Python-Dev] A syntax for function attributes? Message-ID: <1059653204.3f2906542bf30@mcherm.com> Pat Miller writes: > I can imagine: > > def sqr [inline=true](x): > return x*x [...] > I think it essential to use some dense syntax. It would be messy if it > were > > def sqr(x): > return x*x > sqr.inline = true I don't object to a syntax for function attributes... in fact, I've seen no specific proposal to object to. But I find your point above HIGHLY unconvincing: Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> version_1 = """def sqr [inline=true] (x): ... return x*x ... """ >>> version_2 = """def sqr(x): ... return x*x ... sqr.inline = true ... """ >>> len(version_2) - len(version_1) 4 Here's what WOULD convince me. Mark Nottingham writes: > I would very much like to use function > attributes for associating metadata with functions and methods, but the > lack of such syntactic support precludes their use, so I end up > (ab)using __doc__. Rather than introducing the syntax first, let's start by making it POSSIBLE somehow, even if the syntax is awkward. That's already been done -- functions can have attributes. THEN, let's write some cool code that uses feature, and we'll learn how it works out in practice. Only once we see how very useful this really is should we consider introducing special syntax for it, because the less special syntax that Python has, the better it is (if we keep functionality constant). Notice that this is the approach that Guido used for classmethod and its ilk, and we're still working out what the right "special syntax" is for those, but in the meantime we're seeing that they are getting lots of use. I think this approach (first prove it's useful for Python, THEN add syntax to the language) is preferable for ALL new "special syntax" except in three cases. One exception is features like generators, which are instantly recognized by all as being enormously useful, so we skipped the "whether to do it" stage and went right to the discussion of _what_ the special syntax should be. Another exception is features which simply CAN'T be done without introducing new syntax... like PEP 310 where we prevent the race condition. And the third exception is cases where the proponants claim that the syntax change itself is what makes the difference -- for instance those who point to ruby's blocks as very useful while Python's lambda's have just a little bit too much typing. (Not that I agree, necessarily, but they're entitled to make their point.) Other than that, let's always try things out before adding special syntax. Now-my-fourth--no-AMONGST-my-exceptions-lly yours, -- Michael Chermside From barry@python.org Thu Jul 31 13:22:14 2003 From: barry@python.org (Barry Warsaw) Date: 31 Jul 2003 08:22:14 -0400 Subject: [Python-Dev] Switch to 2.4a0 on trunk? In-Reply-To: References: Message-ID: <1059654134.24132.2.camel@anthem> On Wed, 2003-07-30 at 21:35, Tim Peters wrote: > > Is there a branch that will track the "latest 2.3" for the next > > few years (ie, through 2.3.1, 2.3.2 etc?) > > It doesn't appear that there is yet. Barry? It will be named > release23-maint. Yes, I'll get that set up later today. -Barry From harri.pasanen@trema.com Thu Jul 31 14:14:52 2003 From: harri.pasanen@trema.com (Harri Pasanen) Date: Thu, 31 Jul 2003 15:14:52 +0200 Subject: [Python-Dev] deadlock problem In-Reply-To: <200307311153.39665.harri.pasanen@trema.com> References: <200307311153.39665.harri.pasanen@trema.com> Message-ID: <200307311514.52891.harri.pasanen@trema.com> Some precisions to my mail: On Thursday 31 July 2003 11:53, Harri Pasanen wrote: > Hi, > > I'm having a deadlock on import in my embedded python 2.3rc2, on > Win2000, built with Visual C++ 7.1. It is actually Python 2.3b2, Win2000 under vmWare, linux (Mandrake 9.1 host). That python passes all tests, except test_httplib fails with socket.error: (10060, 'Operation timed out') Instrumenting the python code a bit, I noticed that import_lock is 0164A280 here and it the deadlocking 01648DA8 is something else. > 1084: PyThread_acquire_lock(0164A280, 0) called > 1084: PyThread_acquire_lock(0164A280, 0) -> 1 > ECHO > 1084: PyThread_release_lock(01648DA8) called > 1084: PyThread_acquire_lock(01648DA8, 1) called I'll try with Python 2.3 final and try to isolate it further. Harri From barry@python.org Thu Jul 31 15:25:08 2003 From: barry@python.org (Barry Warsaw) Date: 31 Jul 2003 10:25:08 -0400 Subject: [Python-Dev] Switch to 2.4a0 on trunk? In-Reply-To: References: Message-ID: <1059661508.1171.4.camel@yyz> On Wed, 2003-07-30 at 21:35, Tim Peters wrote: > > And while I am asking, I am a little uncertain about the CVS tags. > > Can someone explain the distinction between release23-branch and > > release23-fork for me? > > Probably, but it doesn't matter . xyz-fork is just a tag on the HEAD, > and xyz-branch is a branch that started life with the stuff with the > xyz-fork tag. > > > Is there a branch that will track the "latest 2.3" for the next > > few years (ie, through 2.3.1, 2.3.2 etc?) > > It doesn't appear that there is yet. Barry? It will be named > release23-maint. Well, here's the problem. The branch was already created with release23-branch, and there doesn't appear to be a way to rename a branch tag. Fred's going to dig into the docs to see if he can find a clue, but if anybody else has direct experience with renaming branch tags, please speak up! I've updated the pep so this won't happen again three years from now when Orlijn releases Python 2.4 . The other option is to just stick with release23-branch as the maintenance branch tag. -Barry From patmiller@llnl.gov Thu Jul 31 15:53:41 2003 From: patmiller@llnl.gov (Pat Miller) Date: Thu, 31 Jul 2003 07:53:41 -0700 Subject: [Python-Dev] A syntax for function attributes? Message-ID: <3F292D75.1030508@llnl.gov> Michael wrote: > I don't object to a syntax for function attributes... in fact, I've seen no > specific proposal to object to. But I find your point above HIGHLY > unconvincing: I agree that def sqr(x): return x*x sqr.inline = true is about the same length as def sqr [inline=true](x): return x*x But when this function is 60 lines long rather than 2 lines long, the association is broken. This is my major objection, not the number of characters I write, but rather the number of lines I must scan. People wouldn't be as likely to use doc strings if the syntax was: def function(x): code code code code function.__doc__ = "this is my doc string" > Notice that this is the approach that Guido used for classmethod and > its ilk, and we're still working out what the right "special syntax" I use the classmethod call because its the only (good) way to do the task, but I have the same objection. When I write class Foo: def method(self, ...): ... method = classmethod(method) Upon reading, I don't find out the "true meaning" of the method until I happen upon the classmethod call. Even in C++ with its bogus syntax, I can identify a class method at the point of definition class Foo { static void method(...); ... } so, it would be nice if there was a way to densely associate the information at the point of function definition just as the doc string is densely associated with the function definition. class Foo: def method [classmethod=true](self, ...): "doc string" def get_x [property="x"](self): return self.__x -- Patrick Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller The more original a discovery, the more obvious it seems afterward. -- Arthur Koestler From theller@python.net Thu Jul 31 16:00:00 2003 From: theller@python.net (Thomas Heller) Date: Thu, 31 Jul 2003 17:00:00 +0200 Subject: [Python-Dev] Switch to 2.4a0 on trunk? In-Reply-To: <1059661508.1171.4.camel@yyz> (Barry Warsaw's message of "31 Jul 2003 10:25:08 -0400") References: <1059661508.1171.4.camel@yyz> Message-ID: Barry Warsaw writes: > On Wed, 2003-07-30 at 21:35, Tim Peters wrote: > >> > And while I am asking, I am a little uncertain about the CVS tags. >> > Can someone explain the distinction between release23-branch and >> > release23-fork for me? >> >> Probably, but it doesn't matter . xyz-fork is just a tag on the HEAD, >> and xyz-branch is a branch that started life with the stuff with the >> xyz-fork tag. >> >> > Is there a branch that will track the "latest 2.3" for the next >> > few years (ie, through 2.3.1, 2.3.2 etc?) >> >> It doesn't appear that there is yet. Barry? It will be named >> release23-maint. > > Well, here's the problem. The branch was already created with > release23-branch, and there doesn't appear to be a way to rename a > branch tag. Fred's going to dig into the docs to see if he can find a > clue, but if anybody else has direct experience with renaming branch > tags, please speak up! As far as I know, you create a new tag with the new name, specifying '-r old-tag' as the revision to tag. Then you can delete the old tag. Thomas From python@discworld.dyndns.org Thu Jul 31 16:10:49 2003 From: python@discworld.dyndns.org (Charles Cazabon) Date: Thu, 31 Jul 2003 09:10:49 -0600 Subject: [Python-Dev] A syntax for function attributes? In-Reply-To: <3F292D75.1030508@llnl.gov>; from patmiller@llnl.gov on Thu, Jul 31, 2003 at 07:53:41AM -0700 References: <3F292D75.1030508@llnl.gov> Message-ID: <20030731091049.B8410@discworld.dyndns.org> Pat Miller wrote: > Michael wrote: > > I don't object to a syntax for function attributes [...] > I agree that > > def sqr(x): > return x*x > sqr.inline = true > > is about the same length as > > def sqr [inline=true](x): > return x*x If it's going to look like a mapping, and quack like a mapping, why not make it a mapping? def funcname(args) {attribute_mapping} : ... Docstrings then just become symantic sugar for this: def sqr(x) { '__doc__' : '''Return the square of x.''', 'inline' : True }: return x*x Charles -- ----------------------------------------------------------------------- Charles Cazabon GPL'ed software available at: http://www.qcc.ca/~charlesc/software/ ----------------------------------------------------------------------- From fdrake@acm.org Thu Jul 31 16:29:08 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 31 Jul 2003 11:29:08 -0400 Subject: [Python-Dev] Switch to 2.4a0 on trunk? In-Reply-To: <1059661508.1171.4.camel@yyz> References: <1059661508.1171.4.camel@yyz> Message-ID: <16169.13764.938399.262785@grendel.zope.com> Barry Warsaw writes: > Well, here's the problem. The branch was already created with > release23-branch, and there doesn't appear to be a way to rename a > branch tag. Fred's going to dig into the docs to see if he can find a > clue, but if anybody else has direct experience with renaming branch > tags, please speak up! Boy have we dug! Did the nasty with a test repository as well. > The other option is to just stick with release23-branch as the > maintenance branch tag. Thomas Heller writes: > As far as I know, you create a new tag with the new name, > specifying '-r old-tag' as the revision to tag. Then you can delete > the old tag. If these weren't branch tags, that would be exactly what we want. The CVS manual says this doesn't work for branch tags. It's right. Here's what we've come up with: 1. Create a fresh checkout from the release23-branch tag. Capture the cvs output (all the "U somefile" lines) for use in the next step. 2. Massage the cvs output to create input for xargs --null: sed 's/^U //' cvsoutput | tr '\n' '\000' >xargsinput 3. Use xargs --null to drive a cvs admin command: cat xargsinput | xargs --null cvs admin -N release23-maint:release23-branch 4. Send an email to python-dev to let people test. Note that the release23-branch tag is left alone. It's not worth the risk of removing it. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From pje@telecommunity.com Thu Jul 31 16:55:21 2003 From: pje@telecommunity.com (Phillip J. Eby) Date: Thu, 31 Jul 2003 11:55:21 -0400 Subject: [Python-Dev] A syntax for function attributes? In-Reply-To: <3F292D75.1030508@llnl.gov> Message-ID: <5.1.1.6.0.20030731115256.0201e180@telecommunity.com> At 07:53 AM 7/31/03 -0700, Pat Miller wrote: >Michael wrote: >>I don't object to a syntax for function attributes... in fact, I've seen no >>specific proposal to object to. But I find your point above HIGHLY >>unconvincing: > >I use the classmethod call because its the only (good) way to do >the task, but I have the same objection. When I write > >class Foo: > def method(self, ...): > ... > > method = classmethod(method) > > >Upon reading, I don't find out the "true meaning" of the method until I >happen upon the classmethod call. I agree with the need to put information about a method near the definition, but I don't think that we need a separate syntax specifically for function attributes. I think that with PEP 318 or some variant thereof, it is trivial to create an 'attrs(foo=bar, baz=spam)' function that can be used as a decorator, eg. in conjunction with classmethod. From kbk@shore.net Thu Jul 31 16:54:09 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Thu, 31 Jul 2003 11:54:09 -0400 Subject: [Python-Dev] Switch to 2.4a0 on trunk? In-Reply-To: <1059661508.1171.4.camel@yyz> (Barry Warsaw's message of "31 Jul 2003 10:25:08 -0400") References: <1059661508.1171.4.camel@yyz> Message-ID: Barry Warsaw writes: > Well, here's the problem. The branch was already created with > release23-branch, and there doesn't appear to be a way to rename a > branch tag. Fred's going to dig into the docs to see if he can find a > clue, but if anybody else has direct experience with renaming branch > tags, please speak up! Although renaming ordinary tags is straightforward, (update to the old tag, tag with the new name, update to the new name, delete the old tag), this is not the case with branch tags. Here's a procedure for renaming a branch tags: www.loria.fr/~molli/fom-serve/cache/83.html Recent cvs info nodes for Revisions/Modifying tags state: "Warning: Moving branch tags is very dangerous! If you think you need the -B option, think again....There is almost certainly another way to accomplish what you want to accomplish_" And that's for _moving_ tags. As far as I know, there is no easy way to duplicate a branch except by explicitly merging it, and that's not really a duplicate. The faqomatic entry talks about running admin on each file; that doesn't seem to be a reasonable option with Python. > I've updated the pep so this won't happen again three years from now >when Orlijn releases Python 2.4 . > > The other option is to just stick with release23-branch as the > maintenance branch tag. -1 :-) I thought of two ways. First, make a release23-maint branch tag off release23-fork and merge release23-fork to it. The problem with this is it's a lot of work and loses/obscures the history on the original branch. Or, do it like 2.2 was apparently forced to do (*): Switch to release23-branch, tag [the head of release23-branch] as release23-maint-fork, and add a branch tag release23-maint. That's a lot easier, of course. And safe. -- KBK (*) Looking at patchlevel.h, for instance: release22-fork magic number branch 2.60.0.2 release22 this was the first tag on that branch: 2.60.2.1 release22-maint magic number branch 2.60.2.1.0.2 r221c1 third tag on _that_ branch: 2.60.2.1.2.3 From aleaxit@yahoo.com Thu Jul 31 17:06:12 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Thu, 31 Jul 2003 18:06:12 +0200 Subject: [Python-Dev] buglet in interaction between pygame, Numeric & copy in Python 2.3 Message-ID: <200307311806.12701.aleaxit@yahoo.com> I'm sending this buglet-report to the discussion lists for each of pygame, Numeric, and Python-Dev, because it ends with a recommendation for changes (at least to docs) in each of the two extension packages and Python 2.3.1. I'm not a regular user of pygame [I am one of Numeric]. I helped some pygame users find out why their program was breaking (in just one point) when migrating Python 2.2 -> 2.3 (Numeric 23.0, pygame 1.5.6 from cvs snapshot). The problem can be narrowed down the following little buglet.py script: import copy, pygame.display, pygame.surfarray screen = pygame.display.set_mode((640,480),0,24) surf = pygame.surfarray.pixels3d(screen) xx = copy.copy(surf[10:20,30]) With python 2.2, this runs without errors. With 2.3: Traceback (most recent call last): File "buglet.py", line 6, in ? xx = copy.copy(surf[10:20,30]) File "/usr/local/lib/python2.3/copy.py", line 101, in copy raise Error("un(shallow)copyable object of type %s" % cls) copy.Error: un(shallow)copyable object of type Workaround for the problem: add an "import Numeric" at the top of buglet.py. Reason for the problem: copy.copy uses different mechanisms in 2.3 vs 2.2 for shallow copies of Numeric.array instances. In 2.2, it looked for a method __copy__ on the instance, found it, and happily used it. In 2.3, it relies on getting a 'reductor' function from the copy_reg.dispatch_table. Module Numeric installs such a reductor *WHEN IMPORTED* -- but pygame never imports it even though functions such as the above-used pixels3d do return instances of Numeric.array. So, Numeric.py doesn't run, and therefore cannot install its pickle_array function with the copy_reg module. Suggested fix in pygame: I would suggest making sure Numeric has been imported when Numeric.array instances are to be returned. That's up to the pygame maintainers, of course; at the very least, I think this issue should be mentioned in pygame's docs (asking the user to make sure "import Numeric" happens in any pygame-using program that manipulates such instances). Suggested fix in Numeric: Numeric cannot DO anything much about this issue, I think, but it should probably *mention* (in the docs regarding interfacing to Numeric from other C-coded extensions) that other extensions should make sure Numeric is _imported_ (from a Python POV), if said extensions return instances of Numeric.array, to ensure such instances have full functionality (and in particular shallow copyability). Suggested fix in Python: a mention in the "what's new" document, section "porting to Python 2.3", is probably warranted -- not so much about Numeric and/or pygame extensions per se, though these are both popular 3rd party extensions, but rather the excellent changes in the shallow copy mechanics, which may indeed require code changes on the part of extension authors. Thanks, Alex From jeremy@alum.mit.edu Thu Jul 31 17:29:56 2003 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Thu, 31 Jul 2003 12:29:56 -0400 Subject: [Python-Dev] Switch to 2.4a0 on trunk? In-Reply-To: <16169.13764.938399.262785@grendel.zope.com> Message-ID: > Barry Warsaw writes: > > The other option is to just stick with release23-branch as the > > maintenance branch tag. Could we just create a new branch with the same revisions of the files? Then we'd have the branch with the name we expect and a decoy branch named release23-branch. Jeremy From fdrake@acm.org Thu Jul 31 17:30:24 2003 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 31 Jul 2003 12:30:24 -0400 Subject: [Python-Dev] Switch to 2.4a0 on trunk? In-Reply-To: References: <1059661508.1171.4.camel@yyz> Message-ID: <16169.17440.340472.119765@grendel.zope.com> Kurt B. Kaiser writes: > Switch to release23-branch, tag [the head of release23-branch] as > release23-maint-fork, and add a branch tag release23-maint. > > That's a lot easier, of course. And safe. The problem we have with this is that it produces really horrid revision numbers with 6 places instead of 4. Appearantly modern versions of CVS work just fine with these, but... it makes our stomachs churn! (Er, that's *not* a good thing...) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From pf_moore@yahoo.co.uk Thu Jul 31 19:58:40 2003 From: pf_moore@yahoo.co.uk (Paul Moore) Date: Thu, 31 Jul 2003 19:58:40 +0100 Subject: [Python-Dev] Re: A syntax for function attributes? References: <3F292D75.1030508@llnl.gov> <5.1.1.6.0.20030731115256.0201e180@telecommunity.com> Message-ID: "Phillip J. Eby" writes: > I agree with the need to put information about a method near the > definition, but I don't think that we need a separate syntax > specifically for function attributes. I think that with PEP 318 or > some variant thereof, it is trivial to create an 'attrs(foo=bar, > baz=spam)' function that can be used as a decorator, eg. in > conjunction with classmethod. To be honest, the *only* serious reason for any of this syntax (PEP 318, something for attributes, whatever) is to keep metadata near the definition (or at least, the def statement, rather than after the code...) I like Michael Hudson's variation on PEP 318, def f() [mod1, mod2]: pass It's minimal, flexible, and has an implementation. The downsides that I see are: 1. It doesn't help with properties. To be honest, I don't see this as much of an issue, as properties are a very different beast (they effectively combine multiple functions in one). People have demonstrated clever hacks to make properties possible, which leads me nicely to... 2. It's possibly *too* flexible. The temptation to define clever hacks may be just a little high. The example of attrs() mentioned above is a good example. It satisfies a real need, it's simple, and it's easy to implement via the [...] syntax. But is it really the best way of handling function attributes? I really don't know, without trying it out. And that leads me onto... 3. It's almost impossible to tell whether it will look right in practice, without implementing it and trying it out. And once that happens, it'll probably never get removed, even if it's *not* the right answer. The canonical function modifier is classmethod (or staticmethod), and for that, Michael's syntax def f(...) [classmethod]: pass looks great. My canonical case for function attributes comes from the parser Spark, which (mis-)uses docstrings to contain the grammar rule for which the function is an action: def p_expr_term(self, args): ''' expr ::= expr + term term ::= term * factor ''' return AST(type=args[1], left=args[0], right=args[2]) To me, this certainly *isn't* going to work with something like attrs() - imagine def p_expr_term(self, args) [attrs( rule=''' expr ::= expr + term term ::= term * factor ''')]: return AST(type=args[1], left=args[0], right=args[2]) Yuk. The current function attribute syntax def p_expr_term(self, args): return AST(type=args[1], left=args[0], right=args[2]) p_expr_term.rule = ''' expr ::= expr + term term ::= term * factor ''' looks better than that, IMHO. I'm sorry, this rambled on a bit. I think that, in summary, my points are: * My preferred solution for PEP 318 is Michael Hudson's patch. * It may be too general, in tempting people to mis-use the feature in inappropriate ways (but what the heck, anything can be misused, at some level). * I don't think there's an obvious solution for function attributes yet. * I think properties are another unsolved problem. It's also interesting to note that classmethod/staticmethod and properties get used in spite of the lack of syntactic support, whereas function attributes generally don't seem to. I'm not quite sure what this implies about the usefulness of function attributes... Hope this was useful, Paul -- This signature intentionally left blank From scrosby@cs.rice.edu Thu Jul 31 19:59:23 2003 From: scrosby@cs.rice.edu (Scott A Crosby) Date: 31 Jul 2003 13:59:23 -0500 Subject: [Python-Dev] Looking for programs using regular expressions Message-ID: I'm working on techniques to automatically identify problematic regular expressions where carefully chosen inputs can cause a matcher to run for a long time. I need testcases, so I'm looking for Python software that that is widely used and also uses lots of regular expressions. Can anyone offer any suggestions of what I should look at? I'm also looking for Perl software. Thanks Scott I'm not on the list, so please CC me any replies. From amk@amk.ca Thu Jul 31 20:03:15 2003 From: amk@amk.ca (A.M. Kuchling) Date: Thu, 31 Jul 2003 15:03:15 -0400 Subject: [Python-Dev] Re: buglet in interaction between pygame, Numeric & copy in Python 2.3 References: <200307311806.12701.aleaxit@yahoo.com> Message-ID: On Thu, 31 Jul 2003 18:06:12 +0200, Alex Martelli wrote: > copy_reg.dispatch_table. Module > Numeric installs such a reductor *WHEN IMPORTED* -- but pygame never > imports it even though functions such as the above-used pixels3d do > return instances of Numeric.array. This is startling; how is it possible to return instances of Numeric.array without importing Numeric? --amk From drifty@alum.berkeley.edu Thu Jul 31 20:17:02 2003 From: drifty@alum.berkeley.edu (Brett C.) Date: Thu, 31 Jul 2003 12:17:02 -0700 Subject: [Python-Dev] Looking for programs using regular expressions In-Reply-To: References: Message-ID: <3F296B2E.6070203@ocf.berkeley.edu> Scott A Crosby wrote: > I'm working on techniques to automatically identify problematic > regular expressions where carefully chosen inputs can cause a matcher > to run for a long time. > > I need testcases, so I'm looking for Python software that that is > widely used and also uses lots of regular expressions. Can anyone > offer any suggestions of what I should look at? I'm also looking for > Perl software. > > Thanks Scott, this is the wrong place to be asking this. Python-dev is used to discuss the development of the Python language. A better place to look for an answer to your question is on comp.lang.python (which can also be reached through python-list@python.org ). But, to just go ahead an answer your question, the Python standard library has several places where regexes are used. You can search for ``import re`` or ``from re import`` to find modules that use regexes. -Brett From pje@telecommunity.com Thu Jul 31 20:38:21 2003 From: pje@telecommunity.com (Phillip J. Eby) Date: Thu, 31 Jul 2003 15:38:21 -0400 Subject: [Python-Dev] Re: A syntax for function attributes? In-Reply-To: References: <3F292D75.1030508@llnl.gov> <5.1.1.6.0.20030731115256.0201e180@telecommunity.com> Message-ID: <5.1.1.6.0.20030731152530.01ef94c0@telecommunity.com> At 07:58 PM 7/31/03 +0100, Paul Moore wrote: >To be honest, the *only* serious reason for any of this syntax (PEP >318, something for attributes, whatever) is to keep metadata near the >definition (or at least, the def statement, rather than after the >code...) Agreed. >I like Michael Hudson's variation on PEP 318, > > def f() [mod1, mod2]: > pass > >It's minimal, flexible, and has an implementation. > >The downsides that I see are: > >1. It doesn't help with properties. To be honest, I don't see this as > much of an issue, as properties are a very different beast (they > effectively combine multiple functions in one). People have > demonstrated clever hacks to make properties possible, which leads > me nicely to... > >2. It's possibly *too* flexible. The temptation to define clever hacks > may be just a little high. The example of attrs() mentioned above > is a good example. It satisfies a real need, it's simple, and it's > easy to implement via the [...] syntax. But is it really the best > way of handling function attributes? I really don't know, without > trying it out. And that leads me onto... > >3. It's almost impossible to tell whether it will look right in > practice, without implementing it and trying it out. And once that > happens, it'll probably never get removed, even if it's *not* the > right answer. Actually, between classmethod and PEAK's 'binding.Once', I use function modifiers a *lot*, and I'm not keen on waiting for 2.4 to address the issue. So I've been thinking about writing a processor that would let me do: def f(...): # [classmethod,...] ... f = classmethod(f) And the processor would make sure that the f=classmethod(f) part matched the comment. Actually, if I could work up an editor macro that would do this for me, it'd be even better. >My canonical case for function attributes comes from the parser Spark, >which (mis-)uses docstrings to contain the grammar rule for which the >function is an action: > > def p_expr_term(self, args): > ''' > expr ::= expr + term > term ::= term * factor > ''' > return AST(type=args[1], > left=args[0], > right=args[2]) > > >To me, this certainly *isn't* going to work with something like >attrs() - imagine > > def p_expr_term(self, args) [attrs( > rule=''' > expr ::= expr + term > term ::= term * factor > ''')]: > return AST(type=args[1], > left=args[0], > right=args[2]) > >Yuk. Me, I could probably live with: def p_expr_term(self,args) [ spark.rule( """expr ::= expr + term term ::= term * factor""" ) ]: return AST(...) But then, I'd personally be a bit more more likely to do: EXPR_TERM = spark.rule( """etc.""" ) def p_expr_term(self,args) [EXPR_TERM]: ... >I'm sorry, this rambled on a bit. I think that, in summary, my points >are: > > * My preferred solution for PEP 318 is Michael Hudson's patch. I like it too, but "as" isn't bad either. A number of people have objected to [] on the grounds that it is hard to look up in a documentation index. > * It may be too general, in tempting people to mis-use the feature > in inappropriate ways (but what the heck, anything can be > misused, at some level). What would you define as "inappropriate"? From jjl@pobox.com Thu Jul 31 21:03:08 2003 From: jjl@pobox.com (John J Lee) Date: Thu, 31 Jul 2003 21:03:08 +0100 (BST) Subject: [Python-Dev] urllib2 extensibility patch -- comments? Message-ID: It would be great if anyone could look at this RFE patch I posted a while back: http://python.org/sf/759792 One of urllib2's main reasons-for-being is to enable extensions that are reasonably independent of each other. This patch enables that for a fairly big class of extensions. I won't say any more here -- it's all in the RFE. The reason I'd appreciate comments on it now is that I'm working on cookie code that I hope to get into 2.4. I don't want to release a version of my code with this change if the change isn't going to get into the Python library. John From zack@codesourcery.com Thu Jul 31 21:11:54 2003 From: zack@codesourcery.com (Zack Weinberg) Date: Thu, 31 Jul 2003 13:11:54 -0700 Subject: [Python-Dev] Re: A syntax for function attributes? In-Reply-To: <5.1.1.6.0.20030731152530.01ef94c0@telecommunity.com> (Phillip J. Eby's message of "Thu, 31 Jul 2003 15:38:21 -0400") References: <3F292D75.1030508@llnl.gov> <5.1.1.6.0.20030731115256.0201e180@telecommunity.com> <5.1.1.6.0.20030731152530.01ef94c0@telecommunity.com> Message-ID: <87vftizcad.fsf@egil.codesourcery.com> "Phillip J. Eby" writes: > > > Me, I could probably live with: > > def p_expr_term(self,args) [ > spark.rule( > """expr ::= expr + term > term ::= term * factor""" > ) > ]: > return AST(...) Come to think, I tried to do something rather similar while attempting to write an expect clone in python. I would suggest the syntax def p_expr_term(self, args) {rule : """expr ::= expr + term term ::= term * factor"""}: return AST(...) I.e. allow a dictionary constructor expression between the argument list and the colon; this initializes the property dictionary of the code object. One could stick a call to spark.rule() in there, or have a metaclass do it automatically. This allows the square bracket notation to be reserved for [classmethod] and the like. I suppose there's nothing stopping square brackets from being used for both, but I like having consistency with other dictionary constructor expressions. zw From pf_moore@yahoo.co.uk Thu Jul 31 21:12:23 2003 From: pf_moore@yahoo.co.uk (Paul Moore) Date: Thu, 31 Jul 2003 21:12:23 +0100 Subject: [Python-Dev] Re: A syntax for function attributes? References: <3F292D75.1030508@llnl.gov> <5.1.1.6.0.20030731115256.0201e180@telecommunity.com> <5.1.1.6.0.20030731152530.01ef94c0@telecommunity.com> Message-ID: "Phillip J. Eby" writes: > At 07:58 PM 7/31/03 +0100, Paul Moore wrote: >> * It may be too general, in tempting people to mis-use the feature >> in inappropriate ways (but what the heck, anything can be >> misused, at some level). > > What would you define as "inappropriate"? "Ugly". And I know that's subjective, too :-) Paul. -- This signature intentionally left blank From esr@thyrsus.com Thu Jul 31 21:18:23 2003 From: esr@thyrsus.com (Eric S. Raymond) Date: Thu, 31 Jul 2003 16:18:23 -0400 Subject: [Python-Dev] Re: A syntax for function attributes? In-Reply-To: <87vftizcad.fsf@egil.codesourcery.com> References: <3F292D75.1030508@llnl.gov> <5.1.1.6.0.20030731115256.0201e180@telecommunity.com> <5.1.1.6.0.20030731152530.01ef94c0@telecommunity.com> <87vftizcad.fsf@egil.codesourcery.com> Message-ID: <20030731201823.GC24113@thyrsus.com> Zack Weinberg : > I.e. allow a dictionary constructor expression between the argument > list and the colon; this initializes the property dictionary of the > code object. One could stick a call to spark.rule() in there, or have > a metaclass do it automatically. > > This allows the square bracket notation to be reserved for > [classmethod] and the like. I suppose there's nothing stopping square > brackets from being used for both, but I like having consistency with > other dictionary constructor expressions. I like this argument. +1. -- Eric S. Raymond From aleaxit@yahoo.com Thu Jul 31 22:14:08 2003 From: aleaxit@yahoo.com (Alex Martelli) Date: Thu, 31 Jul 2003 23:14:08 +0200 Subject: [Python-Dev] Re: buglet in interaction between pygame, Numeric & copy in Python 2.3 In-Reply-To: References: <200307311806.12701.aleaxit@yahoo.com> Message-ID: <200307312314.08712.aleaxit@yahoo.com> On Thursday 31 July 2003 09:03 pm, A.M. Kuchling wrote: > On Thu, 31 Jul 2003 18:06:12 +0200, Alex Martelli > > wrote: > > copy_reg.dispatch_table. Module > > Numeric installs such a reductor *WHEN IMPORTED* -- but pygame never > > imports it even though functions such as the above-used pixels3d do > > return instances of Numeric.array. > > This is startling; how is it possible to return instances of Numeric.array > without importing Numeric? E.g., the way src/surfarray.c does it in pygame (simplifying just a bit): #include static PyObject* pixels3d(PyObject* self, PyObject* arg) { PyObject* array; ... array = PyArray_FromDimsAndData(3, dim, PyArray_UBYTE, startpixel); if(array) { ((PyArrayObject*)array)->flags = OWN_DIMENSIONS|OWN_STRIDES|SAVESPACE; ... etc, finish initializing the array object } return array; } The Numeric.array object thus built and returned works well enough (through calls to its methods) that the fact that the Numeric module has never been imported is not apparent to applications using pygame.surfarray.pixels3d and the like -- except that, _in 2.3_, shallow copying is NOT performed by getting and calling a method on the object (as it was in 2.2 -- method __copy__) but rather through a function which must be entered in copy_reg.dispatch_table -- and the task of thus entering said function is performed by Numeric.py's module body, therefore, performed only if and when the module's imported. It may be that calling PyArray_FromDimsAndData before Numeric is imported is considered an error (in this case, I guess pygame should be fixed to avoid such behavior), but, if so, it's an error that passes _quite_ silently in most cases (or used to, up to Python 2.2). Therefore, it appears to me that some mention that this error (if such it be) can now (2.3) give problems it would not give in 2.2 is warranted in the notes about porting code to 2.3 -- Numeric and pygame, being popular extensions, may be given as examples, perhaps, but the real issue in terms of the "porting to 2.3" docs seems to me to be that such docs DO require a mention about changes in copy.copy's mechanisms (those changes may require code changes on the part of the implementor of any copyable type -- Numeric has performed those changes -- AND even extensions just USING such a copyable type may need to change, as I think pygame should change in this case [to ensure it imports Numeric if needed]). Alex From mnot@mnot.net Thu Jul 31 22:55:51 2003 From: mnot@mnot.net (Mark Nottingham) Date: Thu, 31 Jul 2003 14:55:51 -0700 Subject: [Python-Dev] Re: A syntax for function attributes? In-Reply-To: <1059653204.3f2906542bf30@mcherm.com> Message-ID: On Thursday, July 31, 2003, at 05:06 AM, Michael Chermside wrote: > I don't object to a syntax for function attributes... in fact, I've > seen no > specific proposal to object to. See PEP 232 [1], which lists several. 1. http://www.python.org/peps/pep-0232.html > Only once we see how very useful this really is should we consider > introducing special syntax for it, because the less special syntax > that Python has, the better it is (if we keep functionality constant). I find function attributes very useful as a way of associating metadata with functions and methods; this style of coding is gaining a lot of traction elsewhere (e.g., JSRs 175 [2] and 181 [3] in the Java world). 2. http://www.jcp.org/en/jsr/detail?id=175 3. http://www.jcp.org/en/jsr/detail?id=181 I'll be happy to explain my use case if that would help. > syntax... like PEP 310 where we prevent the race condition. And the > third exception is cases where the proponants claim that the syntax > change itself is what makes the difference -- for instance those > who point to ruby's blocks as very useful while Python's lambda's > have just a little bit too much typing. (Not that I agree, necessarily, > but they're entitled to make their point.) I think that's the boat we're in now; the overhead of writing precludes most people from using function attributes for metadata, because it places too much of a readability as well as type-ability barrier in the way; using __doc__ is the path of least resistance, until there is a special syntax. Consider: def heres_my_function_name(args): heres_my_function_name.my_attribute = "Foo" Without a special syntax, I think we'll see more and more abuses of __doc__, like def heres_my_function_name(args): """my_attribute = "Foo" """ Cheers, From Jack.Jansen@cwi.nl Thu Jul 31 23:01:28 2003 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Fri, 1 Aug 2003 00:01:28 +0200 Subject: [Python-Dev] Re: buglet in interaction between pygame, Numeric & copy in Python 2.3 In-Reply-To: <200307312314.08712.aleaxit@yahoo.com> Message-ID: <88F97C26-C3A2-11D7-8996-000A27B19B96@cwi.nl> On donderdag, jul 31, 2003, at 23:14 Europe/Amsterdam, Alex Martelli wrote: > E.g., the way src/surfarray.c does it in pygame (simplifying just a > bit): > > #include > > static PyObject* pixels3d(PyObject* self, PyObject* arg) > { > PyObject* array; > ... > array = PyArray_FromDimsAndData(3, dim, PyArray_UBYTE, startpixel); > if(array) > { > ((PyArrayObject*)array)->flags = > OWN_DIMENSIONS|OWN_STRIDES|SAVESPACE; > ... etc, finish initializing the array object > } > return array; > } Are you using a static build? Because if you use a dynamic build then the PyArray_ functions are actually funky macros that call through a vector, and you have to add an explicit call the the "import_array()" matrix somewhere. And this imports Numeric and initializes the vector. No, wait! import_array() does a PyImport_ImportModule("_numpy"), not PyImport_ImportModule("Numeric"). So maybe fixing this is only a question of importing Numeric, and getting Numeric._numpy._ARRAY_API in import_array(). -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -