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: <LNBBLJKPBEHFEDALKOLCMEHGEMAB.tim.one@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?

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" <art@wiktorsadowski.com  Tue Jul  1 02:40:23 2003
From: Wiktor Sadowski" <art@wiktorsadowski.com (Wiktor Sadowski)
Date: Tue, 1 Jul 2003 03:40:23 +0200
Subject: [Python-Dev] A bit faster access to module attributes
Message-ID: <00ae01c33f71$bf122e80$0201010a@wiktor>

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: <LNBBLJKPBEHFEDALKOLCMEHGEMAB.tim.one@comcast.net>
References: <3F00CD7D.2090807@ocf.berkeley.edu>
 <LNBBLJKPBEHFEDALKOLCMEHGEMAB.tim.one@comcast.net>
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." <bac@OCF.Berkeley.EDU>

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: <OFA782656D.7D149A1D-ON85256D4F.00608E00-85256D4F.0060ED2D@modicon.com>
References: <OFA782656D.7D149A1D-ON85256D4F.00608E00-85256D4F.0060ED2D@modicon.com>
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" <python@rcn.com  Tue Jul  1 06:33:36 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Tue, 1 Jul 2003 01:33:36 -0400
Subject: [Python-Dev] String exceptions in the Tutorial
Message-ID: <009701c33f92$5a9cb3a0$125ffea9@oemcomputer>

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.  <fdrake at acm.org>
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
<http://mail.python.org/pipermail/python-dev/2003-January/032492.html>`__=
=20
and `February=20
<http://mail.python.org/pipermail/python-dev/2003-February/032864.html`__=
=20
of this year.

There was also discussion of adding the traceback for an exception as an=20
attribute of the exception.  This would make getting respective=20
tracebacks easier period but also easier if exception chaining was=20
implemented.  The traceback would most likely be attached to the=20
exception when it is caught and not at instantiation.

Both of these ideas are just that, ideas.  They most likely won't occur=20
until exceptions are moved over to new-style classes which probably=20
won't be for a while.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
`towards a faster Python`__
=3D=3D=3D=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:
   - `problem with assignment shadows builtin warning`__

__

A new warning has been added to Python for when you inject an attribute=20
into a module to shadows a built-in::

     import os
     os.open =3D 42

This is in hopes of making this kind of thing illegal so as to allow the=20
bytecode to be optimized for accessing built-ins.  It also led to=20
package imports, such as ``import A.B.C`` to work directly on the=20
namespace dict instead of doing essentially ``setattr(A, 'B', A.B);=20
setattr(A.B, 'C', A.B.C)``.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
`Sneaky 'super' instances`__
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
__

Splinter threads:
     - `PEP 246 and Protocols`__

__

Discovering that an instance to the 'super' type is both an instance of=20
a class *and* a non-data descriptor was causing issues for pydoc and=20
inspect led to the question of whether there was any definitive way to=20
tell whether an object was an instance of a class defined by using the=20
'class' statement in Python.  It turns out there is: if=20
object.__class__.__flags__ >> 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
<http://www.python.org/dev/summary/2003-02-01_2003-02-15.html#thunks>`__=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: <oq3chrfelr.fsf@titan.progiciels-bpi.ca>
References: <16128.30529.80713.425528@montanaro.dyndns.org> <20030630201510.GB14975@unpythonic.net> <oq3chrfelr.fsf@titan.progiciels-bpi.ca>
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."
 <LNBBLJKPBEHFEDALKOLCMEHGEMAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCMEHGEMAB.tim.one@comcast.net>
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> <LNBBLJKPBEHFEDALKOLCMEHGEMAB.tim.one@comcast.net>
 <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 -----
<db003g@mail.rochester.edu>
    (reason: 550 5.1.1 <db003g@mail.rochester.edu>... User unknown)

   ----- Transcript of session follows -----
... while talking to mail.rochester.edu.:
>>> DATA
<<< 550 5.1.1 <db003g@mail.rochester.edu>... User unknown
550 5.1.1 <db003g@mail.rochester.edu>... User unknown
<<< 503 5.0.0 Need RCPT (recipient)

   ----- Original message follows -----

Return-Path: <python-dev@python.org>
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 <db003g@mail.rochester.edu>; 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 <db003g@mail.rochester.edu>; Tue, 1 Jul 2003 09:18:34 -0400 (EDT)
Message-Id: <200307011318.h61DITsM000009@antivirus2.its.rochester.edu>
From: <python-dev@python.org>
To: <db003g@mail.rochester.edu>
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." <bac@OCF.Berkeley.EDU> 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.  <fdrake at acm.org>
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, <Jack.Jansen@cwi.nl>, 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 <sjoerd@acm.org>


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: <F7DB8D13DB61D511B6FF00B0D0F062330542EA6A@mail.hebmex.com>

> 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.    <DIR>          .
11/06/2003  05:43 p.m.    <DIR>          ..
11/06/2003  05:09 p.m.    <DIR>          Start Menu
11/06/2003  05:43 p.m.    <DIR>          My Documents
11/06/2003  05:43 p.m.    <DIR>          Favorites
11/06/2003  05:09 p.m.    <DIR>          Desktop
11/06/2003  06:22 p.m.    <DIR>          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.    <DIR>          .
11/06/2003  05:43 p.m.    <DIR>          ..
11/06/2003  05:09 p.m.    <DIR>          Start Menu
11/06/2003  05:43 p.m.    <DIR>          My Documents
11/06/2003  05:43 p.m.    <DIR>          Favorites
11/06/2003  05:09 p.m.    <DIR>          Desktop
11/06/2003  06:22 p.m.    <DIR>          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 <sjoerd@acm.org>
>

-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>
 <LNBBLJKPBEHFEDALKOLCMEHGEMAB.tim.one@comcast.net>
 <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: <F7DB8D13DB61D511B6FF00B0D0F062330542EA6A@mail.hebmex.com> (sismex's
 message of "Tue, 1 Jul 2003 10:02:25 -0500")
References: <F7DB8D13DB61D511B6FF00B0D0F062330542EA6A@mail.hebmex.com>
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: <F7DB8D13DB61D511B6FF00B0D0F062330542EAED@mail.hebmex.com>

> 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: <F7DB8D13DB61D511B6FF00B0D0F062330542EA6A@mail.hebmex.com>
Message-ID: <BIEJKCLHCIOIHAGOKOLHKECHGCAA.tim.one@comcast.net>

[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."
 <F7DB8D13DB61D511B6FF00B0D0F062330542EA6A@mail.hebmex.com>
References: <F7DB8D13DB61D511B6FF00B0D0F062330542EA6A@mail.hebmex.com>
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> <LNBBLJKPBEHFEDALKOLCMEHGEMAB.tim.one@comcast.net> <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: <BIEJKCLHCIOIHAGOKOLHKECHGCAA.tim.one@comcast.net> ("Tim
 Peters"'s message of "Tue, 1 Jul 2003 11:15:35 -0400")
References: <BIEJKCLHCIOIHAGOKOLHKECHGCAA.tim.one@comcast.net>
Message-ID: <2my8ziqn57.fsf@starship.python.net>

"Tim Peters" <tim.one@comcast.net> 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" <art@wiktorsadowski.com  Tue Jul  1 17:25:51 2003
From: Wiktor Sadowski" <art@wiktorsadowski.com (Wiktor Sadowski)
Date: Tue, 1 Jul 2003 18:25:51 +0200
Subject: [Python-Dev] A bit faster access to module attributes
Message-ID: <00be01c33fed$73880940$0201010a@wiktor>

>>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: <E19XRK9-00051E-00@sc8-pr-cvs1.sourceforge.net>
Message-ID: <r01050400-1026-6ABCC41EAC0011D7AE84003065D5E7E4@[10.0.0.23]>

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: <r01050400-1026-6ABCC41EAC0011D7AE84003065D5E7E4@[10.0.0.23]>
Message-ID: <BIEJKCLHCIOIHAGOKOLHMEEGGCAA.tim.one@comcast.net>

[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: <BIEJKCLHCIOIHAGOKOLHKECHGCAA.tim.one@comcast.net> <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." <bac@OCF.Berkeley.EDU> 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." <bac@OCF.Berkeley.EDU> 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: <BIEJKCLHCIOIHAGOKOLHKECHGCAA.tim.one@comcast.net> <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 <sjoerd@acm.org>


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: <BIEJKCLHCIOIHAGOKOLHKECHGCAA.tim.one@comcast.net>
 <2my8ziqn57.fsf@starship.python.net>
 <61F3070B-AC03-11D7-8DAC-000A27B19B96@cwi.nl>
Message-ID: <2mhe65qkj5.fsf@starship.python.net>

Jack Jansen <Jack.Jansen@cwi.nl> 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 <time.h>
>>> 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     <anthony@interlink.com.au>
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
<DavidA@ActiveState.com> 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 <stdio.h> "as described in
 * <stdarg.h>".  ANSI-C and POSIX require that the namespace of <stdio.h>
 * 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" <cweqxlpeu@dsg.cs.tcd.ie  Fri Jul  4 07:18:38 2003
From: Bill G" <cweqxlpeu@dsg.cs.tcd.ie (Bill G)
Date: Fri, 04 Jul 2003 09:18:38 +0300
Subject: [Python-Dev] enhance your cable viewing dramatically
Message-ID: <4f2101c341f4$1b2e7140$9634c9e5@"Bill G" cweqxlpeu>

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

<META HTTP-EQUIV=3D=22Content-Type=22 CONTENT=3D=22text/html;charset=3Di=
so-8859-1=22>
<=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22>
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D=22text/html; charset=3Diso-8=
859-1=22>
<META content=3D=22MSHTML 6.00.2600.0=22 name=3DGENERATOR>
<STYLE></STYLE>
</HEAD><FONT face=3DArial><FONT size=3D2>
<BODY>
<DIV>
<DIV>
<DIV><STRONG>This is a must if you have digital cable&nbsp;... <A 
href=3D=22http://www.homecheap123.com/index.php?RepID=3DRS=22>learn mor=
e</A></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D=23808080 size=3D1>If you don't want any more emails=
 from us, 
</FONT><A href=3D=22http://www.homecheap123.com/cleanlist.php=22><FONT =
color=3D=23808080 
size=3D1>go here</FONT></A></DIV></DIV></DIV></BODY></HTML></FONT></FON=
T>


------=_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: <E19YLo7-0006No-00@mail.python.org>

--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: <RM186061@shellus.com>
	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 <RM186061@shellus.com>; Fri, 4 Jul 2003 03:18:15 -0500 (CDT)
From: python-dev@python.org
Message-Id: <200307040818.DAA19383@mailgate1.shellus.com>
To: <RM186061@shellus.com>
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: <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com>

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: <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com> (amaury.forgeotdarc@ubitrade.com's
 message of "Fri, 4 Jul 2003 17:04:10 +0200")
References: <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com>
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 <antonio.beamud@linkend.com>



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."
 <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com>
References: <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com>
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: <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com>
 <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: <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com>
 <2madbupawc.fsf@starship.python.net>
 <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net>
Message-ID: <2m4r22p7qr.fsf@starship.python.net>

Guido van Rossum <guido@python.org> 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: <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com> <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: <OF338639F7.8D888AFC-ONC1256D59.004A5629@ubitrade.com>
 <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 <guido@python.org> 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: <LNBBLJKPBEHFEDALKOLCOEODEMAB.tim.one@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.

> 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."
 <LNBBLJKPBEHFEDALKOLCOEODEMAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCOEODEMAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCAEOHEMAB.tim.one@comcast.net>

[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: <m3he61z8gc.fsf@mira.informatik.hu-berlin.de>

Guido van Rossum <guido@python.org> 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 
<http://www.cwi.nl/~jack/macpython.html>, or (for the impatient) 
directly at 
<http://www.cwi.nl/ftp/jack/python/mac/MacPython-OSX-2.3b2-2.dmg>.

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        <Jack.Jansen@oratrix.com>        
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 <time.h>
>>>>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: <m3he61z8gc.fsf@mira.informatik.hu-berlin.de>
References: <200307021258.h62CwNAh012208@localhost.localdomain> <200307021320.h62DKeT16307@pcp02138704pcs.reston01.va.comcast.net> <m3he61z8gc.fsf@mira.informatik.hu-berlin.de>
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> <m3he61z8gc.fsf@mira.informatik.hu-berlin.de> <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> <m3he61z8gc.fsf@mira.informatik.hu-berlin.de> <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: <LNBBLJKPBEHFEDALKOLCOEODEMAB.tim.one@comcast.net>
References: <200307041627.h64GRwj22018@pcp02138704pcs.reston01.va.comcast.net> <LNBBLJKPBEHFEDALKOLCOEODEMAB.tim.one@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: <m3he61z8gc.fsf@mira.informatik.hu-berlin.de> (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>
 <m3he61z8gc.fsf@mira.informatik.hu-berlin.de>
Message-ID: <m3smpkx6mw.fsf@float.attbi.com>

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: <LNBBLJKPBEHFEDALKOLCAEBCENAB.tim.one@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).

[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 <wink>.



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: <LNBBLJKPBEHFEDALKOLCAEBEENAB.tim.one@comcast.net>

[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 <wink>.



From Anthony Baxter <anthony@interlink.com.au>  Sun Jul  6 05:30:54 2003
From: Anthony Baxter <anthony@interlink.com.au> (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     <anthony@interlink.com.au>   
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: <m365mf3h6y.fsf@mira.informatik.hu-berlin.de>

"M.-A. Lemburg" <mal@lemburg.com> 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 <anthony@interlink.com.au>  Sun Jul  6 14:42:43 2003
From: Anthony Baxter <anthony@interlink.com.au> (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     <anthony@interlink.com.au>   
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 <guido@python.org>
 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: <E19Z9uO-0008Mj-00@localhost>

 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: <m3smpj20ef.fsf@mira.informatik.hu-berlin.de>

Guido van Rossum <guido@python.org> 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: <E19Z9uO-0008Mj-00@localhost>
References: <200307060430.h664UtLC024975@localhost.localdomain>
 <3F07FDDD.9040701@lemburg.com>
 <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net>
 <E19Z9uO-0008Mj-00@localhost>
Message-ID: <m3of072075.fsf@mira.informatik.hu-berlin.de>

"Zooko" <zooko@zooko.com> 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." <m3of072075.fsf@mira.informatik.hu-berlin.de>
References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <200307061242.h66CgTK04757@pcp02138704pcs.reston01.va.comcast.net> <E19Z9uO-0008Mj-00@localhost>  <m3of072075.fsf@mira.informatik.hu-berlin.de>
Message-ID: <E19ZB5R-0008US-00@localhost>

> 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: <m3smpj20ef.fsf@mira.informatik.hu-berlin.de>
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> <m3smpj20ef.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030706155915.GA8819@panix.com>

On Sun, Jul 06, 2003, Martin v. L=F6wis wrote:
> Guido van Rossum <guido@python.org> 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: <m3smpj20ef.fsf@mira.informatik.hu-berlin.de>
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>
 <m3smpj20ef.fsf@mira.informatik.hu-berlin.de>
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 <wink>.  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: <LNBBLJKPBEHFEDALKOLCCEFLENAB.tim.one@comcast.net>

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: <m3smpj20ef.fsf@mira.informatik.hu-berlin.de>
 <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>
 <m3smpj20ef.fsf@mira.informatik.hu-berlin.de>
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."
 <LNBBLJKPBEHFEDALKOLCCEFLENAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCCEFLENAB.tim.one@comcast.net>
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: <m3adbqrkh2.fsf@mira.informatik.hu-berlin.de>

"Delaney, Timothy C (Timothy)" <tdelaney@avaya.com> 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>
 <LNBBLJKPBEHFEDALKOLCOEODEMAB.tim.one@comcast.net>
 <20030705160127.GI1237@epoch.metaslash.com>
Message-ID: <2mfzlio83r.fsf@starship.python.net>

Neal Norwitz <neal@metaslash.com> 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? <fiddle>
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: <DJECKOIDDEODMIODJIPHIENNCAAA.troels@2-10.org>

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
<string>: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: <DJECKOIDDEODMIODJIPHIENNCAAA.troels@2-10.org>
References: <DJECKOIDDEODMIODJIPHIENNCAAA.troels@2-10.org>
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
> 
> <string>: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.
<SNIP>
> 
> 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: <v0311071dbb2f7dc817fc@[192.168.0.2]>

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: <v0311071dbb2f7dc817fc@[192.168.0.2]>
References: <v0311071dbb2f7dc817fc@[192.168.0.2]>
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=<path>.  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: <uvfucr2lv.fsf@boost-consulting.com>

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: <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>

Neil Schemenauer <nas-python@python.ca> 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: <uvfucr2lv.fsf@boost-consulting.com>
References: <uvfucr2lv.fsf@boost-consulting.com>
Message-ID: <m33chggspa.fsf@mira.informatik.hu-berlin.de>

David Abrahams <dave@boost-consulting.com> 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: <uvfucr2lv.fsf@boost-consulting.com>
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: <uvfucr2lv.fsf@boost-consulting.com> (David Abrahams's message
 of "Tue, 08 Jul 2003 20:00:12 -0400")
References: <uvfucr2lv.fsf@boost-consulting.com>
Message-ID: <8yr8rtmu.fsf@python.net>

David Abrahams <dave@boost-consulting.com> 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: <DJECKOIDDEODMIODJIPHMEOACAAA.troels@2-10.org>

> > 
> > 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: <m33chggspa.fsf@mira.informatik.hu-berlin.de> (
 =?iso-8859-1?q?Martin_v._L=F6wis's_message_of?= "09 Jul 2003 07:44:17
 +0200")
References: <uvfucr2lv.fsf@boost-consulting.com>
 <m33chggspa.fsf@mira.informatik.hu-berlin.de>
Message-ID: <ullv7q10i.fsf@boost-consulting.com>

martin@v.loewis.de (Martin v. L=F6wis) writes:

> David Abrahams <dave@boost-consulting.com> 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: <DJECKOIDDEODMIODJIPHMEOACAAA.troels@2-10.org>
References: <3F09B170.7020300@ocf.berkeley.edu> <DJECKOIDDEODMIODJIPHMEOACAAA.troels@2-10.org>
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: <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
References: <16139.16141.291211.130239@montanaro.dyndns.org>
 <20030708222223.GB4059@glacier.arctrix.com>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
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: <ullv7q10i.fsf@boost-consulting.com>
References: <m33chggspa.fsf@mira.informatik.hu-berlin.de> ( Martin v. Löwis's message of "09 Jul 2003 07:44:17 +0200") <ullv7q10i.fsf@boost-consulting.com>
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>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
Message-ID: <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
References: <16139.16141.291211.130239@montanaro.dyndns.org>
 <20030708222223.GB4059@glacier.arctrix.com>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
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>        <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>        <16140.14242.937722.379766@montanaro.dyndns.org>        <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de> <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>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
 <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: <Pine.LNX.4.44.0307092335160.974-100000@alice>

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: <LNBBLJKPBEHFEDALKOLCKEKPENAB.tim.one@comcast.net>

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>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
 <16140.35161.656121.992065@montanaro.dyndns.org>
 <3F0C8DE8.3010403@v.loewis.de>
 <16140.37556.743704.816087@montanaro.dyndns.org>
Message-ID: <m3he5v3r09.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <Pine.LNX.4.44.0307101335500.1263-100000@alice>

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: <Pine.LNX.4.44.0307101335500.1263-100000@alice>
References: <Pine.LNX.4.44.0307101335500.1263-100000@alice>
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: <Pine.LNX.4.44.0307101419180.1287-100000@alice>

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: <OF4FDFD146.EF92327C-ON85256D5F.0049933B-85256D5F.0049D2A1@modicon.com>

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                                                                                                       
                      <jjl@pobox.com>          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: <Pine.LNX.4.44.0307101419180.1287-100000@alice>
References: <20030710131447.GA12277@panix.com> <Pine.LNX.4.44.0307101419180.1287-100000@alice>
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: <m3he5v3r09.fsf@mira.informatik.hu-berlin.de>
References: <16139.16141.291211.130239@montanaro.dyndns.org>
 <20030708222223.GB4059@glacier.arctrix.com>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
 <16140.35161.656121.992065@montanaro.dyndns.org>
 <3F0C8DE8.3010403@v.loewis.de>
 <16140.37556.743704.816087@montanaro.dyndns.org>
 <m3he5v3r09.fsf@mira.informatik.hu-berlin.de>
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" <pje@telecommunity.com> 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>        <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
 <16140.35161.656121.992065@montanaro.dyndns.org>        <3F0C8DE8.3010403@v.loewis.de>
 <16140.37556.743704.816087@montanaro.dyndns.org>
 <m3he5v3r09.fsf@mira.informatik.hu-berlin.de> <16141.30044.453979.807772@montanaro.dyndns.org>
Message-ID: <Pine.UW2.4.53.0307100955200.20112@ou8.int.multitalents.net>

  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: <Pine.UW2.4.53.0307100957360.20112@ou8.int.multitalents.net>
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: <Pine.LNX.4.44.0307092335160.974-100000@alice>
References: <Pine.LNX.4.44.0307092335160.974-100000@alice>
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.

<SNIP>
> 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: <Pine.UW2.4.53.0307100955200.20112@ou8.int.multitalents.net>
References: <16139.16141.291211.130239@montanaro.dyndns.org>
 <20030708222223.GB4059@glacier.arctrix.com>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
 <16140.35161.656121.992065@montanaro.dyndns.org>
 <3F0C8DE8.3010403@v.loewis.de>
 <16140.37556.743704.816087@montanaro.dyndns.org>
 <m3he5v3r09.fsf@mira.informatik.hu-berlin.de>
 <16141.30044.453979.807772@montanaro.dyndns.org>
 <Pine.UW2.4.53.0307100955200.20112@ou8.int.multitalents.net>
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>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
 <16140.35161.656121.992065@montanaro.dyndns.org>
 <3F0C8DE8.3010403@v.loewis.de>
 <16140.37556.743704.816087@montanaro.dyndns.org>
 <m3he5v3r09.fsf@mira.informatik.hu-berlin.de>
 <16141.30044.453979.807772@montanaro.dyndns.org>
 <Pine.UW2.4.53.0307100955200.20112@ou8.int.multitalents.net>
 <16141.50889.737066.126655@montanaro.dyndns.org>
Message-ID: <m3fzlexgxy.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>

Aahz <aahz@pythoncraft.com> 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: <m3fzlexgxy.fsf@mira.informatik.hu-berlin.de>
References: <16139.16141.291211.130239@montanaro.dyndns.org>
 <20030708222223.GB4059@glacier.arctrix.com>
 <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
 <16140.35161.656121.992065@montanaro.dyndns.org>
 <3F0C8DE8.3010403@v.loewis.de>
 <16140.37556.743704.816087@montanaro.dyndns.org>
 <m3he5v3r09.fsf@mira.informatik.hu-berlin.de>
 <16141.30044.453979.807772@montanaro.dyndns.org>
 <Pine.UW2.4.53.0307100955200.20112@ou8.int.multitalents.net>
 <16141.50889.737066.126655@montanaro.dyndns.org>
 <m3fzlexgxy.fsf@mira.informatik.hu-berlin.de>
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: <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
References: <20030710201559.GA5732@panix.com>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
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: <r01050400-1026-4918C3FFB31E11D7A953003065D5E7E4@[10.0.0.23]>

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>        <m37k6sgsv4.fsf@mira.informatik.hu-berlin.de>
 <16140.14242.937722.379766@montanaro.dyndns.org>
 <m3y8z71kmj.fsf@mira.informatik.hu-berlin.de>
 <16140.35161.656121.992065@montanaro.dyndns.org>        <3F0C8DE8.3010403@v.loewis.de>
 <16140.37556.743704.816087@montanaro.dyndns.org>
 <m3he5v3r09.fsf@mira.informatik.hu-berlin.de>
 <16141.30044.453979.807772@montanaro.dyndns.org>
 <Pine.UW2.4.53.0307100955200.20112@ou8.int.multitalents.net>
 <16141.50889.737066.126655@montanaro.dyndns.org>
 <m3fzlexgxy.fsf@mira.informatik.hu-berlin.de> <16141.53302.659976.764809@montanaro.dyndns.org>
Message-ID: <Pine.UW2.4.53.0307101559580.21429@ou8.int.multitalents.net>

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: <Pine.LNX.4.44.0307110143410.592-100000@alice>

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: <LNBBLJKPBEHFEDALKOLCAENAENAB.tim.one@comcast.net>

FYI, some highly deserved recognition came two Python-Dev'ers (overshadowing
Guido's feeble announcement of a new job <wink>):

    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: <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
References: <20030710201559.GA5732@panix.com>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
Message-ID: <1057931403.6408.22.camel@slothrop.zope.com>

On Thu, 2003-07-10 at 16:32, Martin v. L=F6wis wrote:
> Aahz <aahz@pythoncraft.com> 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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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.  <fred at zope.com>
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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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: <u19t3xak.fsf@python.net>

Jeremy Hylton <jeremy@zope.com> 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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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> <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de> <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>
 <m3brw2xgvk.fsf@mira.informatik.hu-berlin.de>
 <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: <oqof00l61d.fsf@titan.progiciels-bpi.ca>

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: <m33chalx6a.fsf@mira.informatik.hu-berlin.de>

"Brett C." <bac@OCF.Berkeley.EDU> 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: <m3ptkewalj.fsf@mira.informatik.hu-berlin.de>

"M.-A. Lemburg" <mal@lemburg.com> 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: <m3y8z2uuk1.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <LNBBLJKPBEHFEDALKOLCAEDPEOAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCAEDPEOAB.tim.one@comcast.net>
References: <16145.42415.10003.235348@montanaro.dyndns.org>
 <LNBBLJKPBEHFEDALKOLCAEDPEOAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCIEFGEOAB.tim.one@comcast.net>

[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 <anthony@interlink.com.au>  Mon Jul 14 08:47:34 2003
From: Anthony Baxter <anthony@interlink.com.au> (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: <PDEDIFMNJCFOKJPHIFJNKEOBDNAA.jeffh@activestate.com>
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     <anthony@interlink.com.au>   
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: <LNBBLJKPBEHFEDALKOLCIEFGEOAB.tim.one@comcast.net>
References: <16146.1745.865650.293138@montanaro.dyndns.org>
 <LNBBLJKPBEHFEDALKOLCIEFGEOAB.tim.one@comcast.net>
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 <anthony@interlink.com.au>  Mon Jul 14 16:31:54 2003
From: Anthony Baxter <anthony@interlink.com.au> (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: <m3y8z0etyr.fsf@mira.informatik.hu-berlin.de>

Christopher Blunck <blunck@gst.com> 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: <m3y8z0etyr.fsf@mira.informatik.hu-berlin.de>
References: <200307060430.h664UtLC024975@localhost.localdomain> <3F07FDDD.9040701@lemburg.com> <20030714140718.GC7911@homer.gst.com> <m3y8z0etyr.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030714210212.GA15492@homer.gst.com>

On Mon, Jul 14, 2003 at 10:25:48PM +0200, Martin v. L=F6wis wrote:
> Christopher Blunck <blunck@gst.com> 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: <m33chalx6a.fsf@mira.informatik.hu-berlin.de>
Message-ID: <r01050400-1026-1B0A4E15B70511D7977F003065D5E7E4@[10.0.0.23]>

Martin v. L=F6wis wrote:

> "Brett C." <bac@OCF.Berkeley.EDU> 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: <r01050400-1026-1B0A4E15B70511D7977F003065D5E7E4@[10.0.0.23]>
References: <m33chalx6a.fsf@mira.informatik.hu-berlin.de>
 <r01050400-1026-1B0A4E15B70511D7977F003065D5E7E4@[10.0.0.23]>
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: <m33chalx6a.fsf@mira.informatik.hu-berlin.de>
 <r01050400-1026-1B0A4E15B70511D7977F003065D5E7E4@[10.0.0.23]>
 <16148.29468.500711.746030@montanaro.dyndns.org>
Message-ID: <m365m3o3x0.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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 <jeremy@alum.mit.edu> 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 <jeremy@alum.mit.edu> 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: <m365m3o3x0.fsf@mira.informatik.hu-berlin.de>
References: <m33chalx6a.fsf@mira.informatik.hu-berlin.de>
 <r01050400-1026-1B0A4E15B70511D7977F003065D5E7E4@[10.0.0.23]>
 <16148.29468.500711.746030@montanaro.dyndns.org>
 <m365m3o3x0.fsf@mira.informatik.hu-berlin.de>
Message-ID: <16148.48024.605585.84838@montanaro.dyndns.org>

>>>>> "Martin" =3D=3D Martin v L=F6wis <martin@v.loewis.de> writes:

    Martin> Skip Montanaro <skip@pobox.com> 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 "<stdin>", 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: <LNBBLJKPBEHFEDALKOLCAEKJEOAB.tim.one@comcast.net>

[Skip, test_pep277.py]
> ...
> This seems better:

Not with hard tab characters it ain't <wink>.

>     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: <LNBBLJKPBEHFEDALKOLCAEKJEOAB.tim.one@comcast.net>
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
<wink>, 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: <m33chalx6a.fsf@mira.informatik.hu-berlin.de>
 <r01050400-1026-1B0A4E15B70511D7977F003065D5E7E4@[10.0.0.23]>
 <16148.29468.500711.746030@montanaro.dyndns.org>
 <m365m3o3x0.fsf@mira.informatik.hu-berlin.de>
 <16148.48024.605585.84838@montanaro.dyndns.org>
Message-ID: <m3smp7m6q6.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <m3oezvm66y.fsf@mira.informatik.hu-berlin.de>

Christian Reis <kiko@async.com.br> 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: <m3oezvm66y.fsf@mira.informatik.hu-berlin.de>
References: <20030715222422.GA3625@async.com.br> <m3oezvm66y.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030716144432.GH782@async.com.br>

On Wed, Jul 16, 2003 at 06:44:21AM +0200, Martin v. L=F6wis wrote:
> Christian Reis <kiko@async.com.br> 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: <uvfucr2lv.fsf@boost-consulting.com>
 <000a01c345f3$776ae710$f501a8c0@eden>
Message-ID: <usmp65r7r.fsf@boost-consulting.com>

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" <mhammond@skippinet.com.au> 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" <tim.one@comcast.net> 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 <theller@python.net> 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>
 <m3oezvm66y.fsf@mira.informatik.hu-berlin.de>
 <20030716144432.GH782@async.com.br>
Message-ID: <m3d6gajo0o.fsf@mira.informatik.hu-berlin.de>

Christian Reis <kiko@async.com.br> 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<int>
std_vector.long     std::vector<long>
std_vector.size_t   std::vector<size_t>
std_vector.float    std::vector<float>
std_vector.double   std::vector<double>

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" <python@rcn.com  Wed Jul 16 21:52:53 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Wed, 16 Jul 2003 16:52:53 -0400
Subject: [Python-Dev] WinME
Message-ID: <004101c34bdc$3a990120$44b22c81@oemcomputer>

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: <BIEJKCLHCIOIHAGOKOLHEEGPGFAA.tim.one@comcast.net>

[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: <m3d6gajo0o.fsf@mira.informatik.hu-berlin.de>
References: <20030715222422.GA3625@async.com.br>
 <m3oezvm66y.fsf@mira.informatik.hu-berlin.de>
 <20030716144432.GH782@async.com.br>
 <m3d6gajo0o.fsf@mira.informatik.hu-berlin.de>
Message-ID: <1058434206.19479.10.camel@spectrum.inescn.pt>

A Qua, 2003-07-16 =E0s 19:59, Martin v. L=F6wis escreveu:
> Christian Reis <kiko@async.com.br> 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
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>




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>	<m3oezvm66y.fsf@mira.informatik.hu-berlin.de>	<20030716144432.GH782@async.com.br>	<m3d6gajo0o.fsf@mira.informatik.hu-berlin.de> <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.  <fdrake at acm.org>
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: <r01050400-1026-3D055303B86411D7977F003065D5E7E4@[192.168.1.103]>

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: <r01050400-1026-3D055303B86411D7977F003065D5E7E4@[192.168.1.103]>
References: <r01050400-1026-3D055303B86411D7977F003065D5E7E4@[192.168.1.103]>
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> <m3oezvm66y.fsf@mira.informatik.hu-berlin.de> <20030716144432.GH782@async.com.br> <m3d6gajo0o.fsf@mira.informatik.hu-berlin.de> <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: <r01050400-1026-0E65C43DB86711D7977F003065D5E7E4@[192.168.1.103]>

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: <adbdxb7h.fsf@python.net>

Jeremy Hylton <jeremy@alum.mit.edu> 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>
 <m3oezvm66y.fsf@mira.informatik.hu-berlin.de>
 <20030716144432.GH782@async.com.br>
 <m3d6gajo0o.fsf@mira.informatik.hu-berlin.de>
 <1058434206.19479.10.camel@spectrum.inescn.pt>
 <20030717145354.GN524@async.com.br>
Message-ID: <m3isq0kbvf.fsf@mira.informatik.hu-berlin.de>

Christian Reis <kiko@async.com.br> 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: <m3el0okbsh.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <m3isq0kbvf.fsf@mira.informatik.hu-berlin.de>
References: <20030715222422.GA3625@async.com.br> <m3oezvm66y.fsf@mira.informatik.hu-berlin.de> <20030716144432.GH782@async.com.br> <m3d6gajo0o.fsf@mira.informatik.hu-berlin.de> <1058434206.19479.10.camel@spectrum.inescn.pt> <20030717145354.GN524@async.com.br> <m3isq0kbvf.fsf@mira.informatik.hu-berlin.de>
Message-ID: <20030717225730.GB4170@async.com.br>

On Fri, Jul 18, 2003 at 12:49:08AM +0200, Martin v. L=F6wis wrote:
> Christian Reis <kiko@async.com.br> 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: <m3adbckbaz.fsf@mira.informatik.hu-berlin.de>

Neil Schemenauer <nas@python.ca> 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: <m3adbckbaz.fsf@mira.informatik.hu-berlin.de>
References: <20030717172643.GA9305@glacier.arctrix.com> <m3adbckbaz.fsf@mira.informatik.hu-berlin.de>
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: <m3el0okbsh.fsf@mira.informatik.hu-berlin.de>
References: <16150.40252.164820.708110@montanaro.dyndns.org>
 <m3el0okbsh.fsf@mira.informatik.hu-berlin.de>
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

<table width=100% dir="ltr"><tr><td><DIV name="wrteplaceholder">Hi,</DIV>
<DIV name="wrteplaceholder">&nbsp;</DIV>
<DIV name="wrteplaceholder">I recently came across a bug in the SSL code in Modules/socketmodule.c.</DIV>
<DIV name="wrteplaceholder">Most of the SSL functions support python threads, but the the constructor function for the SSL session</DIV>
<DIV name="wrteplaceholder">does not. </DIV>
<DIV name="wrteplaceholder">&nbsp;</DIV>
<DIV name="wrteplaceholder">This can hang a multi threaded application if the SSL_connect stalls / hangs / takes a really long time etc.</DIV>
<DIV name="wrteplaceholder">In my application, for example,&nbsp;this prevented me from cancelling an SSL connection to a badly routed destination,</DIV>
<DIV name="wrteplaceholder">since the GUI hanged.</DIV>
<DIV name="wrteplaceholder">&nbsp;</DIV>
<DIV name="wrteplaceholder">Once I enabled threading support&nbsp;in that function in socketmodule.c,&nbsp;the problem was fixed. </DIV>
<DIV name="wrteplaceholder">Is there any reason for the SSL constructor to be thread unsafe?</DIV>
<DIV name="wrteplaceholder">&nbsp;</DIV>
<DIV name="wrteplaceholder">Just thought I'd let you know.</DIV>
<DIV name="wrteplaceholder">&nbsp;</DIV>
<DIV name="wrteplaceholder">PS: I'm not a subcriber to python-dev, could someone update me if / how this was resolved?</DIV>
<DIV name="wrteplaceholder">&nbsp;</DIV>
<DIV name="wrteplaceholder">
<HR SIZE=1>
</DIV></td></tr></table>
<br>
<hr size=1 noshade>
Walla! Mail, Get Your Private, Free E-mail from Walla! at:<br>
<a href="http://mail.walla.co.il">http://mail.walla.co.il</a><br>



--------=_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: <LNBBLJKPBEHFEDALKOLCOENDEOAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net>

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: <Pine.UW2.4.53.0307171936020.1262@ou8.int.multitalents.net>

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: <LNBBLJKPBEHFEDALKOLCOENDEOAB.tim.one@comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCKENKEOAB.tim.one@comcast.net>

[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 <wink>.



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: <Pine.UW2.4.53.0307171936020.1262@ou8.int.multitalents.net>
References: <Pine.UW2.4.53.0307171936020.1262@ou8.int.multitalents.net>
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: <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net>
 <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net>
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: <m2fzl45xff.fsf@slothrop.zope.com>

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: <E19dLmF-0004xu-00@sc8-pr-cvs1.sourceforge.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCCENPEOAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCIEOAEOAB.tim.one@comcast.net>

[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 <wink>.

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: <m2fzl45xff.fsf@slothrop.zope.com>
Message-ID: <005f01c34cdd$d7eca740$65ba958d@oemcomputer>

From: "Jeremy Hylton" <jeremy@zope.com>
> 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: <LNBBLJKPBEHFEDALKOLCOEOCEOAB.tim.one@comcast.net>

[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 <wink>.



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: <m2fzl45xff.fsf@slothrop.zope.com>
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: <BAY2-DAV32BnsyR9NEO00011440@hotmail.com>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am very new to Python.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Need to know if I can achieve this with =

Python:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>~ Read a mail from Outlook 2000 Clinet =
(or may be=20
from Exchange server directly; but from the Client machine)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>~ The mail will be filtered for certain =
words in=20
subject / body (I want to read only one perticular mail&nbsp;I will =
recieve=20
every week)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>~ 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 <A=20
href=3D"file://\\fileserver\foo\abc">\\fileserver\foo\abc</A> which can =
change to=20
<A =
href=3D"file://\\fileserver\foo\xyx">\\fileserver\foo\xyx</A>)</FONT></DI=
V>
<DIV><FONT face=3DArial size=3D2>~ Open this UNC path and copy the =
contents to a=20
local folder.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for the help.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>- apurv</FONT></DIV></BODY></HTML>

------=_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: <BAY2-DAV32BnsyR9NEO00011440@hotmail.com>
References: <BAY2-DAV32BnsyR9NEO00011440@hotmail.com>
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: <Pine.UW2.4.53.0307180822210.3180@ou8.int.multitalents.net>

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: <Pine.UW2.4.53.0307180822210.3180@ou8.int.multitalents.net>
References: <074c01c34d01$e2e943f0$f502a8c0@eden>
 <Pine.UW2.4.53.0307180822210.3180@ou8.int.multitalents.net>
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: <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net>
 <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net> <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net> <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: <m2fzl45xff.fsf@slothrop.zope.com>
References: <m2fzl45xff.fsf@slothrop.zope.com>
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>
 <m3adbckbaz.fsf@mira.informatik.hu-berlin.de>
 <20030718001425.GA10963@glacier.arctrix.com>
Message-ID: <m365lzn4v7.fsf@mira.informatik.hu-berlin.de>

Neil Schemenauer <nas-python@python.ca> 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: <LNBBLJKPBEHFEDALKOLCOENDEOAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCOENDEOAB.tim.one@comcast.net>
Message-ID: <m31xwnn4on.fsf@mira.informatik.hu-berlin.de>

"Tim Peters" <tim.one@comcast.net> 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: <LNBBLJKPBEHFEDALKOLCIEOAEOAB.tim.one@comcast.net>
References: <16151.24705.854058.611883@montanaro.dyndns.org> <LNBBLJKPBEHFEDALKOLCIEOAEOAB.tim.one@comcast.net>
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", 'Ë' <repeats 179 times>..., 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: <m31xwnn4on.fsf@mira.informatik.hu-berlin.de>
Message-ID: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net>

[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 <wink>:

>> 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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net>
 <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net>
 <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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net>
 <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net>
 <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 <http://www.python.org/~jeremy/>




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: <m24r1jilj4.fsf@slothrop.zope.com>

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: <Pine.LNX.4.44.0307181727270.6324-100000@korak.zope.com>

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: <m24r1jilj4.fsf@slothrop.zope.com>
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: <BIEJKCLHCIOIHAGOKOLHOENJGFAA.tim.one@comcast.net>

[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: <BIEJKCLHCIOIHAGOKOLHOENJGFAA.tim.one@comcast.net>
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: <BIEJKCLHCIOIHAGOKOLHGENMGFAA.tim.one@comcast.net>

[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
<wink>), 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: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net>
Message-ID: <m3oezrl3x8.fsf@mira.informatik.hu-berlin.de>

"Tim Peters" <tim.one@comcast.net> 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 <wink>:

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: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCIEPGEOAB.tim.one@comcast.net>

[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 <wink>.

> 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 <wink>,
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>
 <Pine.UW2.4.53.0307180822210.3180@ou8.int.multitalents.net>
 <1058542812.22834.0.camel@slothrop.zope.com>
Message-ID: <Pine.UW2.4.53.0307182210020.9026@ou8.int.multitalents.net>

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: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net>
 <20030719092642.G86863@bullseye.apana.org.au>
Message-ID: <m33ch2anb9.fsf@mira.informatik.hu-berlin.de>

Andrew MacIntyre <andymac@bullseye.apana.org.au> 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: <m3oezrl3x8.fsf@mira.informatik.hu-berlin.de>
References: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net> <m3oezrl3x8.fsf@mira.informatik.hu-berlin.de>
Message-ID: <3F191F97.5060304@algroup.co.uk>

Martin v. Löwis wrote:
> "Tim Peters" <tim.one@comcast.net> 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: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net>
 <m3oezrl3x8.fsf@mira.informatik.hu-berlin.de>
 <3F191F97.5060304@algroup.co.uk>
Message-ID: <m3lluu93id.fsf@mira.informatik.hu-berlin.de>

Ben Laurie <ben@algroup.co.uk> 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: <m3lluu93id.fsf@mira.informatik.hu-berlin.de>
References: <BIEJKCLHCIOIHAGOKOLHEEMDGFAA.tim.one@comcast.net>	<m3oezrl3x8.fsf@mira.informatik.hu-berlin.de>	<3F191F97.5060304@algroup.co.uk> <m3lluu93id.fsf@mira.informatik.hu-berlin.de>
Message-ID: <3F194282.3070205@algroup.co.uk>

Martin v. Löwis wrote:

> Ben Laurie <ben@algroup.co.uk> 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
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>

--=-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 <stdlib.h>
#include <locale.h>
#include <assert.h>
#include <string.h>
#include <errno.h>
#include <ctype.h>

//#define __PYSTRTOD_DEBUG

/* Note: glib functions are based on gstrfuncs.c, version 1.94.2.3 */

/* ------------------------------------------ */
  /* <glib-stuff> */
    /* 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 <ctype.h> 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;
}


  /* </glib-stuff> */
/* ------------------------------------------ */
#ifdef __PYSTRTOD_DEBUG
# include <stdio.h>
#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: <LNBBLJKPBEHFEDALKOLCIEPGEOAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCIEPGEOAB.tim.one@comcast.net>
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 <wink>.

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: <LNBBLJKPBEHFEDALKOLCIEPGEOAB.tim.one@comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEAHEPAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCOEAHEPAB.tim.one@comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEAKEPAB.tim.one@comcast.net>

[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 <wink>.

> 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: <LNBBLJKPBEHFEDALKOLCAEAKEPAB.tim.one@comcast.net>
Message-ID: <EDCFE54D-BA43-11D7-8A29-000A27B19B96@cwi.nl>

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        <Jack.Jansen@oratrix.com>        
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: <EDCFE54D-BA43-11D7-8A29-000A27B19B96@cwi.nl>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEBHEPAB.tim.one@comcast.net>

[Jack Jansen]
> Hi folks, I'm back!

While we never left <wink>.  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 <wink>.

> - 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: <EDCFE54D-BA43-11D7-8A29-000A27B19B96@cwi.nl>
References: <LNBBLJKPBEHFEDALKOLCAEAKEPAB.tim.one@comcast.net>
 <EDCFE54D-BA43-11D7-8A29-000A27B19B96@cwi.nl>
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: <m31xwlirr4.fsf@woof.play-bow.org>

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: <m3brvpr0go.fsf@mira.informatik.hu-berlin.de>

Christian Reis <kiko@async.com.br> 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: <m31xwlirr4.fsf@woof.play-bow.org>
References: <m31xwlirr4.fsf@woof.play-bow.org>
Message-ID: <m37k6dqzx2.fsf@mira.informatik.hu-berlin.de>

Bob Halley <halley@play-bow.org> 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: <m37k6dqzx2.fsf@mira.informatik.hu-berlin.de>
References: <m31xwlirr4.fsf@woof.play-bow.org>
 <m37k6dqzx2.fsf@mira.informatik.hu-berlin.de>
Message-ID: <m3vftxh3dv.fsf@woof.play-bow.org>

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 <asm/types.h>
#include <sys/types.h>
#include <pthread.h>
#include <time.h>

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: <m3vftxh3dv.fsf@woof.play-bow.org>
References: <m31xwlirr4.fsf@woof.play-bow.org> <m37k6dqzx2.fsf@mira.informatik.hu-berlin.de> <m3vftxh3dv.fsf@woof.play-bow.org>
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: <m3brvpr0go.fsf@mira.informatik.hu-berlin.de>
References: <1058620108.3395.5.camel@emperor.localdomain>
 <3F19563D.5000909@v.loewis.de> <20030719154504.GU1158@async.com.br>
 <m3brvpr0go.fsf@mira.informatik.hu-berlin.de>
Message-ID: <1058705856.1165.8.camel@emperor.localdomain>

A Dom, 2003-07-20 =E0s 10:50, Martin v. L=F6wis escreveu:
> Christian Reis <kiko@async.com.br> 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
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>



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."
 <m3vftxh3dv.fsf@woof.play-bow.org>
References: <m31xwlirr4.fsf@woof.play-bow.org> <m37k6dqzx2.fsf@mira.informatik.hu-berlin.de>
 <m3vftxh3dv.fsf@woof.play-bow.org>
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 <just@letterror.com>
 of "Thu, 10 Jul 2003 23:34:19 +0200." <r01050400-1026-4918C3FFB31E11D7A953003065D5E7E4@[10.0.0.23]>
References: <r01050400-1026-4918C3FFB31E11D7A953003065D5E7E4@[10.0.0.23]>
Message-ID: <E19alJ3-0003JH-00@localhost>

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: <LNBBLJKPBEHFEDALKOLCAEAKEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCAEAKEPAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCAEBHEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCAEBHEPAB.tim.one@comcast.net>
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: <m3brvpr0go.fsf@mira.informatik.hu-berlin.de>
References: <1058620108.3395.5.camel@emperor.localdomain>
 <3F19563D.5000909@v.loewis.de> <20030719154504.GU1158@async.com.br>
 <m3brvpr0go.fsf@mira.informatik.hu-berlin.de>
Message-ID: <1058730171.1296.2.camel@emperor.localdomain>

A Dom, 2003-07-20 =E0s 10:50, Martin v. L=F6wis escreveu:
> Christian Reis <kiko@async.com.br> 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
<gjc@inescporto.pt> <gustavo@users.sourceforge.net>



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: <LNBBLJKPBEHFEDALKOLCGEEJEPAB.tim.one@comcast.net>

[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 <wink>.

> 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>
 <m3brvpr0go.fsf@mira.informatik.hu-berlin.de>
 <1058705856.1165.8.camel@emperor.localdomain>
Message-ID: <m3ptk4nbfo.fsf@mira.informatik.hu-berlin.de>

Gustavo J A M Carneiro <gjc@inescporto.pt> 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: <m3vftxh3dv.fsf@woof.play-bow.org>
References: <m31xwlirr4.fsf@woof.play-bow.org>
 <m37k6dqzx2.fsf@mira.informatik.hu-berlin.de>
 <m3vftxh3dv.fsf@woof.play-bow.org>
Message-ID: <m3llusnavu.fsf@mira.informatik.hu-berlin.de>

Bob Halley <halley@play-bow.org> 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: <m3he5gnarl.fsf@mira.informatik.hu-berlin.de>

Adam Langley <lists.pythondev@imperialviolet.org> 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: <LNBBLJKPBEHFEDALKOLCGEEJEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCGEEJEPAB.tim.one@comcast.net>
Message-ID: <m3d6g4namv.fsf@mira.informatik.hu-berlin.de>

"Tim Peters" <tim.one@comcast.net> 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: <E19alJ3-0003JH-00@localhost>
References: <r01050400-1026-4918C3FFB31E11D7A953003065D5E7E4@[10.0.0.23]>
 <E19alJ3-0003JH-00@localhost>
Message-ID: <m38yqsnafz.fsf@mira.informatik.hu-berlin.de>

"Zooko" <zooko@zooko.com> 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: <m3d6g4namv.fsf@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCEEFDEPAB.tim.one@comcast.net>

[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: <m3oezrl3x8.fsf@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEFOEPAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCGEEJEPAB.tim.one@comcast.net>
References: <1058726864.939.44.camel@anthem>
 <LNBBLJKPBEHFEDALKOLCGEEJEPAB.tim.one@comcast.net>
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" <akubota@ntsp.nec.co.jp  Mon Jul 21 02:45:01 2003
From: Aki Kubota" <akubota@ntsp.nec.co.jp (Aki Kubota)
Date: Mon, 21 Jul 2003 09:45:01 +0800
Subject: [Python-Dev] Python Coding Tools
Message-ID: <001701c34f29$b331e1b0$503b1cac@hq.ntsp.nec.co.jp>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"MS Serif" size=3D2>Im new to this mailing list. And =
Im interested=20
in Python tools.</FONT></DIV>
<DIV><FONT face=3D"MS Serif" size=3D2>Stuff you use to make coding =
easier. like=20
Eclipse for Java.</FONT></DIV></BODY></HTML>

------=_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: <LNBBLJKPBEHFEDALKOLCGEFOEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCGEFOEPAB.tim.one@comcast.net>
Message-ID: <m38yqs1mtq.fsf@mira.informatik.hu-berlin.de>

"Tim Peters" <tim.one@comcast.net> 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: <LNBBLJKPBEHFEDALKOLCIEOAEOAB.tim.one@comcast.net>
References: <16151.24705.854058.611883@montanaro.dyndns.org> <LNBBLJKPBEHFEDALKOLCIEOAEOAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net>
References: <20030717204729.GA652@tishler.net> <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net> <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net> <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: <LNBBLJKPBEHFEDALKOLCOEAHEPAB.tim.one@comcast.net> <LNBBLJKPBEHFEDALKOLCAEAKEPAB.tim.one@comcast.net>
Message-ID: <oprsnv1wt1qmnqtt@news.gmane.org>

On Sat, 19 Jul 2003 17:32:52 -0400, Tim Peters <tim.one@comcast.net> 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 <kiko at async.com.br>
Status: 	Draft
Type:       Standards Track
Content-Type: 	text/plain <pep-xxxx.html>
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
    <gjc at inescporto.pt>. 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: <LNBBLJKPBEHFEDALKOLCGEEJEPAB.tim.one@comcast.net>
Message-ID: <F4666940-BB86-11D7-9366-000A27B19B96@cwi.nl>

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        <Jack.Jansen@oratrix.com>        
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: <m3d6g4namv.fsf@mira.informatik.hu-berlin.de>
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" <tim.one@comcast.net> 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        <Jack.Jansen@oratrix.com>       =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: <LNBBLJKPBEHFEDALKOLCGEEJEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCGEEJEPAB.tim.one@comcast.net>
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 <wink>.
> 
> > 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 <anthony@interlink.com.au>  Mon Jul 21 15:39:13 2003
From: Anthony Baxter <anthony@interlink.com.au> (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     <anthony@interlink.com.au>   =

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: <F4666940-BB86-11D7-9366-000A27B19B96@cwi.nl>
References: <F4666940-BB86-11D7-9366-000A27B19B96@cwi.nl>
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: <BIEJKCLHCIOIHAGOKOLHMEAIGGAA.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net>
 <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net>
 <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: <oprsnv1wt1qmnqtt@news.gmane.org>
References: <LNBBLJKPBEHFEDALKOLCOEAHEPAB.tim.one@comcast.net>
 <LNBBLJKPBEHFEDALKOLCAEAKEPAB.tim.one@comcast.net>
 <oprsnv1wt1qmnqtt@news.gmane.org>
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.  <fdrake at acm.org>
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: <oprsnv1wt1qmnqtt@news.gmane.org>
Message-ID: <BIEJKCLHCIOIHAGOKOLHEEALGGAA.tim.one@comcast.net>

[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> <LNBBLJKPBEHFEDALKOLCIEOAEOAB.tim.one@comcast.net> <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: <LNBBLJKPBEHFEDALKOLCEENFEOAB.tim.one@comcast.net> <LNBBLJKPBEHFEDALKOLCAENHEOAB.tim.one@comcast.net> <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: <BIEJKCLHCIOIHAGOKOLHGENMGFAA.tim.one@comcast.net>
References: <007b01c34d7b$827c3480$f7bc2c81@oemcomputer>
 <BIEJKCLHCIOIHAGOKOLHGENMGFAA.tim.one@comcast.net>
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.  <fdrake at acm.org>
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: <BIEJKCLHCIOIHAGOKOLHCECMGGAA.tim.one@comcast.net>

[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
<wink>.

> 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 <procfs.h>, 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 <stdio.h>
#define _LP64
#include <procfs.h>
#undef _LP64
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

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: <BIEJKCLHCIOIHAGOKOLHCECMGGAA.tim.one@comcast.net>
References: <20030721180249.GG1664@tishler.net> <BIEJKCLHCIOIHAGOKOLHCECMGGAA.tim.one@comcast.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 <wink>.

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: <BIEJKCLHCIOIHAGOKOLHKEDAGGAA.tim.one@comcast.net>

[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 <wink>.

[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: <BIEJKCLHCIOIHAGOKOLHKEDAGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHKEDAGGAA.tim.one@comcast.net>
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.  <wink>
> 
> > 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 <http://python.org/sf/774751>.  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: <m3d6g34jrx.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <m38yqr4jcb.fsf@mira.informatik.hu-berlin.de>

Barry Warsaw <barry@python.org> 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: <m34r1f4ivz.fsf@mira.informatik.hu-berlin.de>

John Abel <johnfabel@btinternet.com> 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: <m3d6g34jrx.fsf@mira.informatik.hu-berlin.de>
References: <65E00892-BB87-11D7-9366-000A27B19B96@cwi.nl>
 <200307211439.h6LEdECc006696@localhost.localdomain>
 <16156.2064.781257.761849@montanaro.dyndns.org>
 <m3d6g34jrx.fsf@mira.informatik.hu-berlin.de>
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: <m38yqr4jcb.fsf@mira.informatik.hu-berlin.de>
References: <1058807191.2036.76.camel@yyz>
 <m38yqr4jcb.fsf@mira.informatik.hu-berlin.de>
Message-ID: <1058827492.2036.214.camel@yyz>

On Mon, 2003-07-21 at 18:15, Martin v. L=F6wis wrote:
> Barry Warsaw <barry@python.org> 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 <wink> 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>
 <m3d6g34jrx.fsf@mira.informatik.hu-berlin.de>
 <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: <m38yqr4jcb.fsf@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEHFEPAB.tim.one@comcast.net>

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: <EBF936B1-BBE7-11D7-81D1-000A95A06FC6@shangri-la.dropbear.id.au>

-----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 <zen@shangri-la.dropbear.id.au>
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: <LNBBLJKPBEHFEDALKOLCMEHFEPAB.tim.one@comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCOEHMEPAB.tim.one@comcast.net>

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



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: <LNBBLJKPBEHFEDALKOLCMEHFEPAB.tim.one@comcast.net>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEHNEPAB.tim.one@comcast.net>

[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 <anthony@interlink.com.au>  Tue Jul 22 03:29:08 2003
From: Anthony Baxter <anthony@interlink.com.au> (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: <EBF936B1-BBE7-11D7-81D1-000A95A06FC6@shangri-la.dropbear.id.au>
References: <16156.27381.925389.777799@montanaro.dyndns.org>
 <EBF936B1-BBE7-11D7-81D1-000A95A06FC6@shangri-la.dropbear.id.au>
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 <sys/time.h>
    #include <sys/types.h>
    #include <sys/socket.h>
    #include <netdb.h>
    #include <stdio.h>

    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: <m38yqs1mtq.fsf@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEICEPAB.tim.one@comcast.net>

[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 <wink>.

> 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 <wink>.  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: <LNBBLJKPBEHFEDALKOLCAEICEPAB.tim.one@comcast.net>
References: <m38yqs1mtq.fsf@mira.informatik.hu-berlin.de>
 <LNBBLJKPBEHFEDALKOLCAEICEPAB.tim.one@comcast.net>
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? <wink>

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>
 <m3d6g34jrx.fsf@mira.informatik.hu-berlin.de>
 <16156.27381.925389.777799@montanaro.dyndns.org>
Message-ID: <m3ptk33x93.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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 <anthony@interlink.com.au>  Tue Jul 22 07:15:50 2003
From: Anthony Baxter <anthony@interlink.com.au> (Anthony Baxter)
Date: Tue, 22 Jul 2003 16:15:50 +1000
Subject: [Python-Dev] New branch for r23c2 work
In-Reply-To: <m3ptk33x93.fsf@mira.informatik.hu-berlin.de>
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>
 <EBF936B1-BBE7-11D7-81D1-000A95A06FC6@shangri-la.dropbear.id.au>
 <16156.42473.441618.555308@montanaro.dyndns.org>
Message-ID: <m3llur3x3t.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <m3he5f3x02.fsf@mira.informatik.hu-berlin.de>

Barry Warsaw <barry@python.org> 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: <LNBBLJKPBEHFEDALKOLCOEHMEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCOEHMEPAB.tim.one@comcast.net>
Message-ID: <m3d6g33wu5.fsf@mira.informatik.hu-berlin.de>

"Tim Peters" <tim.one@comcast.net> 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, <Jack.Jansen@cwi.nl>, 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 <richie@entrian.com>  Tue Jul 22 09:49:56 2003
From: Richie Hindle <richie@entrian.com> (Richie Hindle)
Date: Tue, 22 Jul 2003 09:49:56 +0100
Subject: [Python-Dev] bsddb3 test hang
Message-ID: <v4uphv4988tg2hf4rkeqf0vh236f208cju@4ax.com>

[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: <m3llur3x3t.fsf@mira.informatik.hu-berlin.de>
References: <16156.27381.925389.777799@montanaro.dyndns.org>
 <EBF936B1-BBE7-11D7-81D1-000A95A06FC6@shangri-la.dropbear.id.au>
 <16156.42473.441618.555308@montanaro.dyndns.org>
 <m3llur3x3t.fsf@mira.informatik.hu-berlin.de>
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: <BIEJKCLHCIOIHAGOKOLHKEDAGGAA.tim.one@comcast.net> <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.
> <wink>

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>
 <EBF936B1-BBE7-11D7-81D1-000A95A06FC6@shangri-la.dropbear.id.au>
 <16156.42473.441618.555308@montanaro.dyndns.org>
Message-ID: <2mznj6oclj.fsf@starship.python.net>

Skip Montanaro <skip@pobox.com> 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: <lluqpqpd.fsf@python.net>

Is it too late to get this small patch in?

<http://www.python.org/sf/775637>

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 <skip@pobox.com> 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, <Jack.Jansen@cwi.nl>, 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: <lluqpqpd.fsf@python.net>
References: <lluqpqpd.fsf@python.net>
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?
> 
> <http://www.python.org/sf/775637>
> 
> 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: <lluqpqpd.fsf@python.net> <1058886052.13235.19.camel@yyz>
Message-ID: <he5epora.fsf@python.net>

Barry Warsaw <barry@python.org> writes:

> On Tue, 2003-07-22 at 10:43, Thomas Heller wrote:
>> Is it too late to get this small patch in?
>> 
>> <http://www.python.org/sf/775637>
>> 
>> 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, <Jack.Jansen@cwi.nl>, 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
>> <http://www.python.org/sf/775637>
>>=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: <he5epora.fsf@python.net>
References: <lluqpqpd.fsf@python.net> <1058886052.13235.19.camel@yyz>
 <he5epora.fsf@python.net>
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: <m3d6g33wu5.fsf@mira.informatik.hu-berlin.de>
Message-ID: <BIEJKCLHCIOIHAGOKOLHOEHJGGAA.tim.one@comcast.net>

[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: <lluqpqpd.fsf@python.net> <1058886052.13235.19.camel@yyz>
 <he5epora.fsf@python.net> <1058888748.13235.42.camel@yyz>
Message-ID: <d6g2pn05.fsf@python.net>

Barry Warsaw <barry@python.org> 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" <Paul.Moore@atosorigin.com> 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 <Jack.Jansen@cwi.nl> 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: <smoyo4yc.fsf@python.net>

Barry Warsaw <barry@python.org> 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: <smoyo4yc.fsf@python.net>
Message-ID: <BIEJKCLHCIOIHAGOKOLHMEIDGGAA.tim.one@comcast.net>

[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: <smoyo4yc.fsf@python.net>
References: <16E1010E4581B049ABC51D4975CEDB88619AD3@UKDCX001.uk.int.atosorigin.com>
 <1058890446.13235.50.camel@yyz>  <smoyo4yc.fsf@python.net>
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: <m34r1f4ivz.fsf@mira.informatik.hu-berlin.de>
References: <3F1C4808.2090102@btinternet.com> <m34r1f4ivz.fsf@mira.informatik.hu-berlin.de>
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 <johnfabel@btinternet.com> 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." <bac@OCF.Berkeley.EDU> 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 <wink>.

-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: <oprsp8zkjt5ctagx@mail.data-fortress.com>

On 22 Jul 2003 15:31:47 -0400, Barry Warsaw <barry@python.org> 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.  <fdrake at acm.org>
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." <bac@OCF.Berkeley.EDU> 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: <d6g2pn05.fsf@python.net>
References: <lluqpqpd.fsf@python.net> <1058886052.13235.19.camel@yyz>
 <he5epora.fsf@python.net> <1058888748.13235.42.camel@yyz>
 <d6g2pn05.fsf@python.net>
Message-ID: <m37k6ajpt5.fsf@mira.informatik.hu-berlin.de>

Thomas Heller <theller@python.net> 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>
 <m34r1f4ivz.fsf@mira.informatik.hu-berlin.de>
 <3F1D8D42.4020605@btinternet.com>
Message-ID: <m33cgyjpob.fsf@mira.informatik.hu-berlin.de>

John Abel <johnfabel@btinternet.com> 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" <pje@telecommunity.com> 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 <wink>.

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: <m37k6ajpt5.fsf@mira.informatik.hu-berlin.de> (Martin v.'s
 message of "22 Jul 2003 21:59:18 +0200")
References: <lluqpqpd.fsf@python.net> <1058886052.13235.19.camel@yyz>
 <he5epora.fsf@python.net> <1058888748.13235.42.camel@yyz>
 <d6g2pn05.fsf@python.net>
 <m37k6ajpt5.fsf@mira.informatik.hu-berlin.de>
Message-ID: <4r1enww2.fsf@python.net>

martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:

> Thomas Heller <theller@python.net> 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.  <fdrake at acm.org>
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: <BIEJKCLHCIOIHAGOKOLHMEAIGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHMEAIGGAA.tim.one@comcast.net>
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" <tim.one@comcast.net>
 of "Tue, 22 Jul 2003 11:58:11 EDT." <BIEJKCLHCIOIHAGOKOLHOEHJGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHOEHJGGAA.tim.one@comcast.net>
Message-ID: <E19f3g5-000529-00@localhost>

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: <LNBBLJKPBEHFEDALKOLCOEOCEOAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCOEOCEOAB.tim.one@comcast.net>
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 <wink>.
> 

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: <BIEJKCLHCIOIHAGOKOLHCEJMGGAA.tim.one@comcast.net>

[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: <E19f3g5-000529-00@localhost>
Message-ID: <BIEJKCLHCIOIHAGOKOLHOEJMGGAA.tim.one@comcast.net>

[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: <oprsp8zkjt5ctagx@mail.data-fortress.com>
References: <3F10D7E7.3080304@ocf.berkeley.edu>  <3F1D8E67.8010609@ocf.berkeley.edu> <1058902307.13235.90.camel@yyz> <oprsp8zkjt5ctagx@mail.data-fortress.com>
Message-ID: <oprsqb6plz5ctagx@mail.data-fortress.com>

On Tue, 22 Jul 2003 12:41:34 -0700, Jordan Krushen <jordan@krushen.com> 
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: <BIEJKCLHCIOIHAGOKOLHCEJMGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHCEJMGGAA.tim.one@comcast.net>
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><m34r1f4ivz.fsf@mira.informatik.hu-berlin.de><3F1D8D42.4020605@btinternet.com> <m33cgyjpob.fsf@mira.informatik.hu-berlin.de>
Message-ID: <001601c35094$d66ebfb0$66656565@hallows>

> John Abel <johnfabel@btinternet.com> 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: <BIEJKCLHCIOIHAGOKOLHAEKBGGAA.tim.one@comcast.net>

[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: <BIEJKCLHCIOIHAGOKOLHAEKBGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHAEKBGGAA.tim.one@comcast.net>
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: <BIEJKCLHCIOIHAGOKOLHCEJMGGAA.tim.one@comcast.net>
 <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: <D50587B9-BC88-11D7-A6B7-000A27B19B96@cwi.nl>

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: <D50587B9-BC88-11D7-A6B7-000A27B19B96@cwi.nl>
References: <3F10D7E7.3080304@ocf.berkeley.edu>
 <3F1D8E67.8010609@ocf.berkeley.edu>
 <D50587B9-BC88-11D7-A6B7-000A27B19B96@cwi.nl>
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>
 <m34r1f4ivz.fsf@mira.informatik.hu-berlin.de>
 <3F1D8D42.4020605@btinternet.com>
 <m33cgyjpob.fsf@mira.informatik.hu-berlin.de>
 <001601c35094$d66ebfb0$66656565@hallows>
Message-ID: <m3n0f6tg4s.fsf@mira.informatik.hu-berlin.de>

"John Abel" <john.abel@pa.press.net> 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> <D50587B9-BC88-11D7-A6B7-000A27B19B96@cwi.nl> <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>
 <D50587B9-BC88-11D7-A6B7-000A27B19B96@cwi.nl>
 <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.  <fdrake at acm.org>
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>        <D50587B9-BC88-11D7-A6B7-000A27B19B96@cwi.nl> <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: <m3u19ep83e.fsf@float.attbi.com>

Michael Hudson <mwh@python.net> 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 <stdlib.h>
  #include <time.h>
  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 <stdlib.h>
  #include <time.h>
+ #include <string.h>
  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 "<string>", 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: <BIEJKCLHCIOIHAGOKOLHIEKGGGAA.tim.one@comcast.net>

[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 <wink>.
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>
 <D50587B9-BC88-11D7-A6B7-000A27B19B96@cwi.nl>
 <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: <BIEJKCLHCIOIHAGOKOLHEEKFGGAA.tim.one@comcast.net>

[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: <BIEJKCLHCIOIHAGOKOLHGEKEGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHGEKEGGAA.tim.one@comcast.net>
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: <m3r84ip7cf.fsf@float.attbi.com>

Michael Hudson <mwh@python.net> 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 "<string>", 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: <BIEJKCLHCIOIHAGOKOLHCEJMGGAA.tim.one@comcast.net>
Message-ID: <BIEJKCLHCIOIHAGOKOLHGEKEGGAA.tim.one@comcast.net>

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: <m3u19ep83e.fsf@float.attbi.com>
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> <m3u19ep83e.fsf@float.attbi.com>
Message-ID: <3F1DB0AD.90407@ocf.berkeley.edu>

Kurt B. Kaiser wrote:

> Michael Hudson <mwh@python.net> 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: <BIEJKCLHCIOIHAGOKOLHIEKGGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHIEKGGGAA.tim.one@comcast.net>
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 
> <wink>.
> 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: <BIEJKCLHCIOIHAGOKOLHCEKLGGAA.tim.one@comcast.net>

[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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><m34r1f4ivz.fsf@mira.informatik.hu-berlin.de><3F1D8D42.4020605@btinternet.com><m33cgyjpob.fsf@mira.informatik.hu-berlin.de><001601c35094$d66ebfb0$66656565@hallows> <m3n0f6tg4s.fsf@mira.informatik.hu-berlin.de>
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 <procfs.h>

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>

#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> <m3u19ep83e.fsf@float.attbi.com>
 <3F1DB0AD.90407@ocf.berkeley.edu>
Message-ID: <m3n0f6p6qm.fsf@float.attbi.com>

"Brett C." <bac@OCF.Berkeley.EDU> 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: <BIEJKCLHCIOIHAGOKOLHCEKNGGAA.tim.one@comcast.net>

[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> <m3u19ep83e.fsf@float.attbi.com>
 <3F1DB0AD.90407@ocf.berkeley.edu>
Message-ID: <m3k7aap5m7.fsf@float.attbi.com>

"Brett C." <bac@OCF.Berkeley.EDU> 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 "<string>", 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: <oprsqb6plz5ctagx@mail.data-fortress.com>
References: <3F10D7E7.3080304@ocf.berkeley.edu>  <3F1D8E67.8010609@ocf.berkeley.edu> <1058902307.13235.90.camel@yyz> <oprsp8zkjt5ctagx@mail.data-fortress.com> <oprsqb6plz5ctagx@mail.data-fortress.com>
Message-ID: <oprsqg1ge15ctagx@mail.data-fortress.com>

On Tue, 22 Jul 2003 13:50:39 -0700, Jordan Krushen <jordan@krushen.com> 
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: <m3k7aap5m7.fsf@float.attbi.com>
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> <m3u19ep83e.fsf@float.attbi.com>	<3F1DB0AD.90407@ocf.berkeley.edu> <m3k7aap5m7.fsf@float.attbi.com>
Message-ID: <3F1DBD75.9060504@ocf.berkeley.edu>

Kurt B. Kaiser wrote:
> "Brett C." <bac@OCF.Berkeley.EDU> 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 "<string>", 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: <BIEJKCLHCIOIHAGOKOLHCEKLGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHCEKLGGAA.tim.one@comcast.net>
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']
> 
> '(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
> [1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
> :(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
> 
> '(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
> [1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
> :(?P<M>[0-5]\\d|\\d):(?P<S>6[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: <oprsqg1ge15ctagx@mail.data-fortress.com>
References: <3F10D7E7.3080304@ocf.berkeley.edu>  <3F1D8E67.8010609@ocf.berkeley.edu> <1058902307.13235.90.camel@yyz> <oprsp8zkjt5ctagx@mail.data-fortress.com> <oprsqb6plz5ctagx@mail.data-fortress.com> <oprsqg1ge15ctagx@mail.data-fortress.com>
Message-ID: <3F1DC14A.7040304@ocf.berkeley.edu>

Jordan Krushen wrote:

> On Tue, 22 Jul 2003 13:50:39 -0700, Jordan Krushen <jordan@krushen.com> 
> 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: <LNBBLJKPBEHFEDALKOLCMEIOEPAB.tim.one@comcast.net>

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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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 <wink>.


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: <LNBBLJKPBEHFEDALKOLCGEJAEPAB.tim.one@comcast.net>

[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 <wink>.

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: <LNBBLJKPBEHFEDALKOLCMEIOEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCMEIOEPAB.tim.one@comcast.net>
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']
> '(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
> [1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
> :(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
> '(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
> [1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
> :(?P<M>[0-5]\\d|\\d):(?P<S>6[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 <wink>.

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: <LNBBLJKPBEHFEDALKOLCGEJAEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCGEJAEPAB.tim.one@comcast.net>
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 <wink>.
> 

=)  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: <LNBBLJKPBEHFEDALKOLCGEJDEPAB.tim.one@comcast.net>

>> 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" <wink>.  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 <wink>.



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: <LNBBLJKPBEHFEDALKOLCEEJFEPAB.tim.one@comcast.net>

[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
'(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
[1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
:(?P<M>[0-5]\\d|\\d):(?P<S>6[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 <neal@metaslash.com>, 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
<a href="http://sco.iwethey.org">SCO</a>


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 <gward@python.net>                         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: <LNBBLJKPBEHFEDALKOLCMEIOEPAB.tim.one@comcast.net>
 <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 <wink>.
> 
> 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 <wink>.

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: <LNBBLJKPBEHFEDALKOLCGEKBEPAB.tim.one@comcast.net>

[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: <m3d6g1q1kr.fsf@float.attbi.com>

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 <zen@shangri-la.dropbear.id.au>
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: <m3y8ypojp9.fsf@float.attbi.com>

Stuart Bishop <zen@shangri-la.dropbear.id.au> 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: <lluqpqpd.fsf@python.net> <1058886052.13235.19.camel@yyz>
 <he5epora.fsf@python.net> <1058888748.13235.42.camel@yyz>
 <d6g2pn05.fsf@python.net>
 <m37k6ajpt5.fsf@mira.informatik.hu-berlin.de>
 <4r1enww2.fsf@python.net>
Message-ID: <wue9n3s9.fsf@python.net>

Thomas Heller <theller@python.net> writes:

> martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:
>
>> Thomas Heller <theller@python.net> 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: <BIEJKCLHCIOIHAGOKOLHIEKGGGAA.tim.one@comcast.net>
 <6E0614E7-BC8E-11D7-A6B7-000A27B19B96@cwi.nl>
Message-ID: <2mbrvloebn.fsf@starship.python.net>

Jack Jansen <Jack.Jansen@cwi.nl> 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
>> <wink>.
>> 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> <m3u19ep83e.fsf@float.attbi.com>
 <3F1DB0AD.90407@ocf.berkeley.edu> <m3k7aap5m7.fsf@float.attbi.com>
 <3F1DBD75.9060504@ocf.berkeley.edu>
Message-ID: <2m8yqpoe6g.fsf@starship.python.net>

"Brett C." <bac@OCF.Berkeley.EDU> 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: <m3d6g1q1kr.fsf@float.attbi.com>
Message-ID: <A0FCA33E-BCE6-11D7-85DF-0030655234CE@cwi.nl>

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, <Jack.Jansen@cwi.nl>, 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>
 <EBF936B1-BBE7-11D7-81D1-000A95A06FC6@shangri-la.dropbear.id.au>
 <16156.42473.441618.555308@montanaro.dyndns.org>
Message-ID: <2mznj5mp37.fsf@starship.python.net>

Skip Montanaro <skip@pobox.com> 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: <m3d6g1q1kr.fsf@float.attbi.com>
References: <m3d6g1q1kr.fsf@float.attbi.com>
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: <E7ABF47D-BD07-11D7-85DF-0030655234CE@cwi.nl>

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, <Jack.Jansen@cwi.nl>, 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: <C89E3B87-BD08-11D7-85DF-0030655234CE@cwi.nl>

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, <Jack.Jansen@cwi.nl>, 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: <E7ABF47D-BD07-11D7-85DF-0030655234CE@cwi.nl> (Jack Jansen's
 message of "Wed, 23 Jul 2003 14:19:27 +0200")
References: <E7ABF47D-BD07-11D7-85DF-0030655234CE@cwi.nl>
Message-ID: <2mn0f5mncc.fsf@starship.python.net>

Jack Jansen <Jack.Jansen@cwi.nl> 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: <E7ABF47D-BD07-11D7-85DF-0030655234CE@cwi.nl>
References: <E7ABF47D-BD07-11D7-85DF-0030655234CE@cwi.nl>
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: <C89E3B87-BD08-11D7-85DF-0030655234CE@cwi.nl>
References: <C89E3B87-BD08-11D7-85DF-0030655234CE@cwi.nl>
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: <E7ABF47D-BD07-11D7-85DF-0030655234CE@cwi.nl>
References: <E7ABF47D-BD07-11D7-85DF-0030655234CE@cwi.nl>
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.  <fdrake at acm.org>
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 <wink>.




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: <LNBBLJKPBEHFEDALKOLCMEGNEOAB.tim.one@comcast.net>

[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 <wink>.

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: <BAY2-DAV37kqC5EtrUV0001d41b@hotmail.com>

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 "<stdin>", 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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Need Help.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am writing a wrapper for a small .c =
function=20
using SWIG</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The problem i am facing is that I am =
not able to=20
import the module generated by SWIG.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Is there any special setting to be done =
to import=20
custom modules in Windows (Windows2000 to be specific)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Below is the error that =
appears:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; File "&lt;stdin&gt;", line 1, in =
?<BR>&nbsp;=20
File "example.py", line 4, in ?<BR>&nbsp;&nbsp;&nbsp; import=20
_example<BR>ImportError: No module named _example</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>apurv</FONT></DIV></BODY></HTML>

------=_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: <BAY2-DAV37kqC5EtrUV0001d41b@hotmail.com>
References: <BAY2-DAV37kqC5EtrUV0001d41b@hotmail.com>
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: <wue9n3s9.fsf@python.net>
Message-ID: <r01050400-1026-D6307BE4BD3C11D789A6003065D5E7E4@[10.0.0.23]>

Thomas Heller wrote:

> Thomas Heller <theller@python.net> writes:
> 
> > martin@v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) writes:
> >
> >> Thomas Heller <theller@python.net> 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> <m3u19ep83e.fsf@float.attbi.com>	<3F1DB0AD.90407@ocf.berkeley.edu> <m3k7aap5m7.fsf@float.attbi.com>	<3F1DBD75.9060504@ocf.berkeley.edu> <2m8yqpoe6g.fsf@starship.python.net>
Message-ID: <3F1EDAE5.4070003@ocf.berkeley.edu>

Michael Hudson wrote:

> "Brett C." <bac@OCF.Berkeley.EDU> 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: <r01050400-1026-D6307BE4BD3C11D789A6003065D5E7E4@[10.0.0.23]>
References: <r01050400-1026-D6307BE4BD3C11D789A6003065D5E7E4@[10.0.0.23]>
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> <m3u19ep83e.fsf@float.attbi.com>
 <3F1DB0AD.90407@ocf.berkeley.edu> <m3k7aap5m7.fsf@float.attbi.com>
 <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: <LNBBLJKPBEHFEDALKOLCEEJFEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCEEJFEPAB.tim.one@comcast.net>
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):
> 

<SNIP of tests passing with test_logging modified>

> 
> 
> 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']
> '(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
> [1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
> :(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
> '(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
> [1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
> :(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
> '(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
> [1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
> :(?P<M>[0-5]\\d|\\d):(?P<S>6[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']
> '(?P<m>1[0-2]|0[1-9]|[1-9])/(?P<d>3[0-1]|[1-2]\\d|0[1-9]|
> [1-9]| [1-9])/(?P<y>\\d\\d)\\s*(?P<H>2[0-3]|[0-1]\\d|\\d)
> :(?P<M>[0-5]\\d|\\d):(?P<S>6[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> <m3u19ep83e.fsf@float.attbi.com>	 <3F1DB0AD.90407@ocf.berkeley.edu> <m3k7aap5m7.fsf@float.attbi.com>	 <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: <LNBBLJKPBEHFEDALKOLCEEJFEPAB.tim.one@comcast.net> <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:


<SNIP>
> 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: <LNBBLJKPBEHFEDALKOLCGEIKEOAB.tim.one@comcast.net>

[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        <Jack.Jansen@oratrix.com>        
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.  <fdrake at acm.org>
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: <D2EE0BA1-BD5A-11D7-A35F-000A27B19B96@cwi.nl>

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        <Jack.Jansen@oratrix.com>        
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: <D2EE0BA1-BD5A-11D7-A35F-000A27B19B96@cwi.nl>
References: <03Jul23.145838pdt."58611"@synergy1.parc.xerox.com>
 <D2EE0BA1-BD5A-11D7-A35F-000A27B19B96@cwi.nl>
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: <LNBBLJKPBEHFEDALKOLCMELBEPAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCOELJEPAB.tim.one@comcast.net>

[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 <wink>.  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 <wink>.



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: <LNBBLJKPBEHFEDALKOLCGELOEPAB.tim.one@comcast.net>

[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 "<stdin>", 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: <LNBBLJKPBEHFEDALKOLCCEMAEPAB.tim.one@comcast.net>

[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 <wink>.

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



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: <LNBBLJKPBEHFEDALKOLCIEMAEPAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCGELOEPAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCAEMDEPAB.tim.one@comcast.net>

[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 <wink>.



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: <LNBBLJKPBEHFEDALKOLCOEMEEPAB.tim.one@comcast.net>

[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 <wink>.

> 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 <wink>.  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 <wink>.  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: <LNBBLJKPBEHFEDALKOLCOEMEEPAB.tim.one@comcast.net>
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 <wink>.

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: <LNBBLJKPBEHFEDALKOLCKEMKEPAB.tim.one@comcast.net>

[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 <locale.h>
	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 <wink> 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: <LNBBLJKPBEHFEDALKOLCMELBEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCMELBEPAB.tim.one@comcast.net>
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 <wink> 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 <locale.h>
#include <stdio.h>
#include <stdlib.h>

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 <janssen@parc.com> 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.  <fdrake at acm.org>
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: <Pine.GSO.4.51.0307241452350.10223@techunix.technion.ac.il>

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

-- 
Beni Cherniavsky <cben@tx.technion.ac.il>


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: <Pine.GSO.4.51.0307241452350.10223@techunix.technion.ac.il>
References: <16159.50979.38979.687400@grendel.zope.com>
 <Pine.GSO.4.51.0307241452350.10223@techunix.technion.ac.il>
Message-ID: <16159.51835.108668.704443@grendel.zope.com>

Beni Cherniavsky writes:
 > s/2.4/2.3/, right?  It's a meta-typo <wink>...

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.  <fdrake at acm.org>
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: <LNBBLJKPBEHFEDALKOLCMELBEPAB.tim.one@comcast.net>
 <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? <wink>

-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: <oqznj4cb5l.fsf@alcyon.progiciels-bpi.ca>

[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: <BIEJKCLHCIOIHAGOKOLHKEMOGGAA.tim.one@comcast.net>

[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: <BIEJKCLHCIOIHAGOKOLHCEOCGGAA.tim.one@comcast.net>

[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 <locale.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> 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 <wink>.

> 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 <wink>), 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: <BIEJKCLHCIOIHAGOKOLHCEOCGGAA.tim.one@comcast.net>
References: <1ED4ECF91CDED24C8D012BCF2B034F13027ABCEB@its-xchg4.massey.ac.nz>
 <BIEJKCLHCIOIHAGOKOLHCEOCGGAA.tim.one@comcast.net>
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: <BIEJKCLHCIOIHAGOKOLHKEMOGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHKEMOGGAA.tim.one@comcast.net>
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: <BIEJKCLHCIOIHAGOKOLHEEPAGGAA.tim.one@comcast.net>

[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 <wink>.  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: <BIEJKCLHCIOIHAGOKOLHEEPAGGAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHEEPAGGAA.tim.one@comcast.net>
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 <wink>.  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 <wink>), 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: <E19fr5a-0002wA-00@sc8-pr-cvs1.sourceforge.net>
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: <LNBBLJKPBEHFEDALKOLCIEOGEPAB.tim.one@comcast.net>

[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 <wink>.

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

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



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: <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.  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: <LNBBLJKPBEHFEDALKOLCIEOJEPAB.tim.one@comcast.net>

[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 <wink>.



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: <LNBBLJKPBEHFEDALKOLCEEOKEPAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCIEOJEPAB.tim.one@comcast.net>
References: <20030725031445.GA9648@panix.com> <LNBBLJKPBEHFEDALKOLCIEOJEPAB.tim.one@comcast.net>
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 <wink>.

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>
 <LNBBLJKPBEHFEDALKOLCIEOJEPAB.tim.one@comcast.net>
 <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: <m3llunl0wd.fsf@float.attbi.com>

Stuart Bishop <zen@shangri-la.dropbear.id.au> 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: <LNBBLJKPBEHFEDALKOLCMEPCEPAB.tim.one@comcast.net>

[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 <wink>.



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: <m3k7a76uub.fsf@mira.informatik.hu-berlin.de>

"Mark Hammond" <mhammond@skippinet.com.au> 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: <E19fr5a-0002wA-00@sc8-pr-cvs1.sourceforge.net> <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: <m3k7a76uub.fsf@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEPJEPAB.tim.one@comcast.net>

[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: <E19fr5a-0002wA-00@sc8-pr-cvs1.sourceforge.net> <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: <E19fr5a-0002wA-00@sc8-pr-cvs1.sourceforge.net>
 <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: <LNBBLJKPBEHFEDALKOLCMEPCEPAB.tim.one@comcast.net>
References: <1ED4ECF91CDED24C8D012BCF2B034F130290AA0C@its-xchg4.massey.ac.nz> <LNBBLJKPBEHFEDALKOLCMEPCEPAB.tim.one@comcast.net>
Message-ID: <bfrajj$ucp$1@main.gmane.org>

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: <bfrajj$ucp$1@main.gmane.org>
References: <1ED4ECF91CDED24C8D012BCF2B034F130290AA0C@its-xchg4.massey.ac.nz>
 <LNBBLJKPBEHFEDALKOLCMEPCEPAB.tim.one@comcast.net>
 <bfrajj$ucp$1@main.gmane.org>
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: <bfrajj$ucp$1@main.gmane.org>
Message-ID: <BIEJKCLHCIOIHAGOKOLHIEBGGHAA.tim.one@comcast.net>

[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: <BIEJKCLHCIOIHAGOKOLHIEBGGHAA.tim.one@comcast.net>
References: <BIEJKCLHCIOIHAGOKOLHIEBGGHAA.tim.one@comcast.net>
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: <BIEJKCLHCIOIHAGOKOLHCEBMGHAA.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCIEPJEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCIEPJEPAB.tim.one@comcast.net>
Message-ID: <m3adb2xn6r.fsf@mira.informatik.hu-berlin.de>

"Tim Peters" <tim.one@comcast.net> 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> <LNBBLJKPBEHFEDALKOLCGEOJEPAB.tim.one@comcast.net>
Message-ID: <bfsloj$n8c$1@main.gmane.org>

"Tim Peters" <tim.one@comcast.net> 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: <bfsloj$n8c$1@main.gmane.org>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEAKFAAB.tim.one@comcast.net>

[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 <lannert@uni-duesseldorf.de>
 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: <E19gQf8-0008JB-00@localhost>

 Detlef Lannert <lannert@uni-duesseldorf.de> 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: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>

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: <E19gQf8-0008JB-00@localhost>
References: <20030722204201.11589.74038.Mailman@mail.python.org>
 <20030723163450.E22274@lannert.rz.uni-duesseldorf.de>
 <E19gQf8-0008JB-00@localhost>
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: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
References: <200307261254.15092.aleaxit@yahoo.com> <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
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: <m3d6fxw95c.fsf@float.attbi.com>

Alex Martelli <aleaxit@yahoo.com> 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>
 <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
 <20030726160447.GA16886@panix.com>
Message-ID: <m37k65w8nk.fsf@float.attbi.com>

Aahz <aahz@pythoncraft.com> 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: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net> <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: <m37k65w8nk.fsf@float.attbi.com>
References: <200307261254.15092.aleaxit@yahoo.com> <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net> <20030726160447.GA16886@panix.com> <m37k65w8nk.fsf@float.attbi.com>
Message-ID: <20030726163851.GA29436@panix.com>

On Sat, Jul 26, 2003, Kurt B. Kaiser wrote:
> Aahz <aahz@pythoncraft.com> 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: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
 <200307261805.20985.aleaxit@yahoo.com>
Message-ID: <m34r19w86g.fsf@float.attbi.com>

Alex Martelli <aleaxit@yahoo.com> 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: <m3d6fxw95c.fsf@float.attbi.com>
References: <200307261254.15092.aleaxit@yahoo.com> <m3d6fxw95c.fsf@float.attbi.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>
 <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
 <20030726160447.GA16886@panix.com> <m37k65w8nk.fsf@float.attbi.com>
 <20030726163851.GA29436@panix.com>
Message-ID: <m3znj1usye.fsf@float.attbi.com>

Aahz <aahz@pythoncraft.com> writes:

> That'd work, provided .idlerc/ is stored in a user's directory.

On XP it's in \Documents and Settings\<usr>\.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>
 <m3d6fxw95c.fsf@float.attbi.com>
 <200307261849.58008.aleaxit@yahoo.com>
Message-ID: <m3u199us3l.fsf@float.attbi.com>

Alex Martelli <aleaxit@yahoo.com> 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: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
 <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: <m3isppuour.fsf@float.attbi.com>

Skip Montanaro <skip@pobox.com> 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: <m3isppuour.fsf@float.attbi.com>
References: <20030726164547.GA987@panix.com> <16162.49785.800687.878189@montanaro.dyndns.org> <m3isppuour.fsf@float.attbi.com>
Message-ID: <200307262040.35424.aleax@aleax.it>

On Saturday 26 July 2003 20:25, Kurt B. Kaiser wrote:
   ...
> Skip Montanaro <skip@pobox.com> 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>
 <m3isppuour.fsf@float.attbi.com> <200307262040.35424.aleax@aleax.it>
Message-ID: <wue5ara0.fsf@yahoo.co.uk>

Alex Martelli <aleax@aleax.it> 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>        <E19gQf8-0008JB-00@localhost> <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> <m3isppuour.fsf@float.attbi.com> <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>
 <E19gQf8-0008JB-00@localhost>
 <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: <m3isppuour.fsf@float.attbi.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCOECOFAAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCOEDAFAAB.tim.one@comcast.net>

[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: <wue5ara0.fsf@yahoo.co.uk>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEDCFAAB.tim.one@comcast.net>

[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" <wink>.

> 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 <wink>.  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: <m3isppuour.fsf@float.attbi.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCEEDEFAAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCOEDAFAAB.tim.one@comcast.net> ("Tim
 Peters"'s message of "Sat, 26 Jul 2003 19:27:53 -0400")
References: <LNBBLJKPBEHFEDALKOLCOEDAFAAB.tim.one@comcast.net>
Message-ID: <m3y8yku5na.fsf@float.attbi.com>

"Tim Peters" <tim.one@comcast.net> 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: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net> ("Tim
 Peters"'s message of "Sat, 26 Jul 2003 19:54:44 -0400")
References: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net>
Message-ID: <m3vftou5au.fsf@float.attbi.com>

"Tim Peters" <tim.one@comcast.net> 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: <m3vftou5au.fsf@float.attbi.com>
References: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net> <m3vftou5au.fsf@float.attbi.com>
Message-ID: <20030727013206.GA3944@panix.com>

On Sat, Jul 26, 2003, Kurt B. Kaiser wrote:
> "Tim Peters" <tim.one@comcast.net> 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: <LNBBLJKPBEHFEDALKOLCMEDCFAAB.tim.one@comcast.net> ("Tim
 Peters"'s message of "Sat, 26 Jul 2003 19:45:27 -0400")
References: <LNBBLJKPBEHFEDALKOLCMEDCFAAB.tim.one@comcast.net>
Message-ID: <m3n0f0u46m.fsf@float.attbi.com>

"Tim Peters" <tim.one@comcast.net> 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: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net>
 <m3vftou5au.fsf@float.attbi.com> <20030727013206.GA3944@panix.com>
Message-ID: <m3fzksu1x4.fsf@float.attbi.com>

Aahz <aahz@pythoncraft.com> 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: <LNBBLJKPBEHFEDALKOLCOECOFAAB.tim.one@comcast.net> ("Tim
 Peters"'s message of "Sat, 26 Jul 2003 19:00:30 -0400")
References: <LNBBLJKPBEHFEDALKOLCOECOFAAB.tim.one@comcast.net>
Message-ID: <m3d6fwtxcc.fsf@float.attbi.com>

"Tim Peters" <tim.one@comcast.net> 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: <m3y8yku5na.fsf@float.attbi.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCMEDPFAAB.tim.one@comcast.net>

[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: <m3n0f0u46m.fsf@float.attbi.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCAEEBFAAB.tim.one@comcast.net>

[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 <wink>
>>> 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: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCMEDPFAAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCMEDPFAAB.tim.one@comcast.net>
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>
 <E19gQf8-0008JB-00@localhost>
 <16162.42452.940978.48426@montanaro.dyndns.org>
 <3F22F94A.7030401@v.loewis.de>
 <16163.593.704035.46802@montanaro.dyndns.org>
Message-ID: <m38yqk5s6d.fsf@mira.informatik.hu-berlin.de>

Skip Montanaro <skip@pobox.com> 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: <LNBBLJKPBEHFEDALKOLCMEDPFAAB.tim.one@comcast.net> ("Tim
 Peters"'s message of "Sun, 27 Jul 2003 01:06:03 -0400")
References: <LNBBLJKPBEHFEDALKOLCMEDPFAAB.tim.one@comcast.net>
Message-ID: <m3he585hlc.fsf@float.attbi.com>

"Tim Peters" <tim.one@comcast.net> 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: <m3d6fwtxcc.fsf@float.attbi.com> (kbk@shore.net's message of
 "Sun, 27 Jul 2003 00:20:03 -0400")
References: <LNBBLJKPBEHFEDALKOLCOECOFAAB.tim.one@comcast.net>
 <m3d6fwtxcc.fsf@float.attbi.com>
Message-ID: <m3d6fw5hg0.fsf@float.attbi.com>

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?

<h2>
<font color="red">WARNING:</font>
</h2>
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 <strong>will</strong> 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> <h2>
    aahz> <font color="red">WARNING:</font>
    aahz> </h2>
    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> <h2>
>     aahz> <font color="red">WARNING:</font>
>     aahz> </h2>
>     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: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
 <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: <m34r19w86g.fsf@float.attbi.com>
References: <LNBBLJKPBEHFEDALKOLCKEBLFAAB.tim.one@comcast.net>
 <200307261805.20985.aleaxit@yahoo.com>  <m34r19w86g.fsf@float.attbi.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: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCIEDDFAAB.tim.one@comcast.net>
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: <wue5ara0.fsf@yahoo.co.uk>
References: <20030726164547.GA987@panix.com>
 <16162.49785.800687.878189@montanaro.dyndns.org>
 <m3isppuour.fsf@float.attbi.com> <200307262040.35424.aleax@aleax.it>
 <wue5ara0.fsf@yahoo.co.uk>
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?
> 
> <h2>
> <font color="red">WARNING:</font>
> </h2>
> 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 <strong>will</strong> 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:

<b>Please note: running the new IDLE in Python 2.3 may produce spurious
warnings from personal firewall software on some Windows machines. 
Please see <a href="bugs.html">the known bugs list</a> for more
information.</b>

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: <LNBBLJKPBEHFEDALKOLCAEFIFAAB.tim.one@comcast.net>

[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?
>
> <h2>
> <font color="red">WARNING:</font>
> </h2>
> 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 <strong>will</strong> 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 <wink>.



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: <LNBBLJKPBEHFEDALKOLCKEFKFAAB.tim.one@comcast.net>

[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 <wink>.

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: <LNBBLJKPBEHFEDALKOLCAEFIFAAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCAEFIFAAB.tim.one@comcast.net>
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 <wink>.

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:
>
> <b>Please note: running the new IDLE in Python 2.3 may produce spurious
> warnings from personal firewall software on some Windows machines.
> Please see <a href="bugs.html">the known bugs list</a> for more
> information.</b>

+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: <GCEDKONBLEFPPADDJCOEKEPEMBAA.whisper@oz.net>

> 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: <LNBBLJKPBEHFEDALKOLCIEGFFAAB.tim.one@comcast.net>

[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: <m3he585hlc.fsf@float.attbi.com>
Message-ID: <LNBBLJKPBEHFEDALKOLCKEGGFAAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCMEGHFAAB.tim.one@comcast.net>

[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: <m3adb2xn6r.fsf@mira.informatik.hu-berlin.de>
Message-ID: <LNBBLJKPBEHFEDALKOLCGEGJFAAB.tim.one@comcast.net>

[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: <LNBBLJKPBEHFEDALKOLCMEGHFAAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCMEGHFAAB.tim.one@comcast.net>
Message-ID: <m3el0bir3j.fsf@mira.informatik.hu-berlin.de>

"Tim Peters" <tim.one@comcast.net> 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:
> 
> <b>Please note: running the new IDLE in Python 2.3 may produce spurious
> warnings from personal firewall software on some Windows machines. 
> Please see <a href="bugs.html">the known bugs list</a> for more
> information.</b>

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: <LNBBLJKPBEHFEDALKOLCGEOJEPAB.tim.one@comcast.net>
References: <1ED4ECF91CDED24C8D012BCF2B034F13027ABDD8@its-xchg4.massey.ac.nz> <LNBBLJKPBEHFEDALKOLCGEOJEPAB.tim.one@comcast.net>
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 <http://python.org/sf/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: <m3d6fulz9f.fsf@mira.informatik.hu-berlin.de>

Barry Warsaw <barry@python.org> writes:

> The last one is 775985 <http://python.org/sf/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: <m3d6fulz9f.fsf@mira.informatik.hu-berlin.de>
References: <1059451484.28413.24.camel@anthem>
 <m3d6fulz9f.fsf@mira.informatik.hu-berlin.de>
Message-ID: <1059480899.28413.37.camel@anthem>

On Tue, 2003-07-29 at 00:42, Martin v. L=F6wis wrote:
> Barry Warsaw <barry@python.org> writes:
>=20
> > The last one is 775985 <http://python.org/sf/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.  <fdrake at acm.org>
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.  <fdrake at acm.org>
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: <LNBBLJKPBEHFEDALKOLCCEMOEOAB.tim_one@email.msn.com>

[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 <wink>.

> 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 <wink>).



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: <m3y8ygfwd9.fsf@mira.informatik.hu-berlin.de>

"Brett C." <bac@OCF.Berkeley.EDU> 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
<wink>.

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: <LNBBLJKPBEHFEDALKOLCCEMOEOAB.tim_one@email.msn.com>
References: <LNBBLJKPBEHFEDALKOLCCEMOEOAB.tim_one@email.msn.com>
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 <wink>.

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<eom>
Message-ID: <BAY2-DAV20M6K6jteJn0000d262@hotmail.com>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000D_01C356AE.D7AC2FF0--


From Raymond Hettinger" <python@rcn.com  Wed Jul 30 14:00:46 2003
From: Raymond Hettinger" <python@rcn.com (Raymond Hettinger)
Date: Wed, 30 Jul 2003 09:00:46 -0400
Subject: [Python-Dev] zip() in Py2.4
Message-ID: <009801c3569b$05b6ede0$b7b7958d@oemcomputer>

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: <LNBBLJKPBEHFEDALKOLCCEMOEOAB.tim_one@email.msn.com>
References: <3F2732E8.70205@ocf.berkeley.edu>
 <LNBBLJKPBEHFEDALKOLCCEMOEOAB.tim_one@email.msn.com>
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> <LNBBLJKPBEHFEDALKOLCCEMOEOAB.tim_one@email.msn.com> <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: <D49752D9-C2A3-11D7-BF6E-00039396E15A@mnot.net>

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: <Pine.LNX.4.44.0307301122490.31494-100000@penguin.theopalgroup.com>

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: <D49752D9-C2A3-11D7-BF6E-00039396E15A@mnot.net>
References: <D49752D9-C2A3-11D7-BF6E-00039396E15A@mnot.net>
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 <wink>.

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: <D49752D9-C2A3-11D7-BF6E-00039396E15A@mnot.net>
References: <D49752D9-C2A3-11D7-BF6E-00039396E15A@mnot.net>
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: <D49752D9-C2A3-11D7-BF6E-00039396E15A@mnot.net>
 <1059581100.30752.78.camel@yyz>
Message-ID: <2mfzkoasl7.fsf@starship.python.net>

Barry Warsaw <barry@python.org> 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 <wink>.

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: <D49752D9-C2A3-11D7-BF6E-00039396E15A@mnot.net>	<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        <Jack.Jansen@oratrix.com>        
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 <jafo@tummy.com>
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: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>

[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 <wink>.  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.  <fdrake at acm.org>
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: <m33cgnnryw.fsf@mira.informatik.hu-berlin.de>

Jack Jansen <Jack.Jansen@cwi.nl> 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: <m33cgnnryw.fsf@mira.informatik.hu-berlin.de>
Message-ID: <E0EA0298-C334-11D7-9F76-003065517236@oratrix.com>

On donderdag, jul 31, 2003, at 08:13 Europe/Amsterdam, Martin v. L=F6wis=20=

wrote:

> Jack Jansen <Jack.Jansen@cwi.nl> 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        <Jack.Jansen@oratrix.com>       =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: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>
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: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>
References: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>
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 <wink>.  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 <wink>.

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: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>
 <1059661508.1171.4.camel@yyz>
Message-ID: <adauwxlb.fsf@python.net>

Barry Warsaw <barry@python.org> 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 <wink>.  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 <patmiller@llnl.gov> 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                           <python@discworld.dyndns.org>
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: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>
 <1059661508.1171.4.camel@yyz>
 <adauwxlb.fsf@python.net>
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.  <fdrake at acm.org>
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: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>
 <1059661508.1171.4.camel@yyz>
Message-ID: <m3wudyd74u.fsf@float.attbi.com>

Barry Warsaw <barry@python.org> 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 <wink>.
>
> 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 <type 'array'>


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: <AFELKANNALMBPOACBPADCEJPDEAA.jeremy@alum.mit.edu>

> 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: <m3wudyd74u.fsf@float.attbi.com>
References: <LNBBLJKPBEHFEDALKOLCGEALEPAB.tim.one@comcast.net>
 <1059661508.1171.4.camel@yyz>
 <m3wudyd74u.fsf@float.attbi.com>
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.  <fdrake at acm.org>
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: <he52wmjj.fsf@yahoo.co.uk>

"Phillip J. Eby" <pje@telecommunity.com> 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: <oyd7k5ywmic.fsf@bert.cs.rice.edu>

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: <oprs6u7psvqmnqtt@news.gmane.org>

On Thu, 31 Jul 2003 18:06:12 +0200, Alex Martelli <aleaxit@yahoo.com> 
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: <oyd7k5ywmic.fsf@bert.cs.rice.edu>
References: <oyd7k5ywmic.fsf@bert.cs.rice.edu>
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: <he52wmjj.fsf@yahoo.co.uk>
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: <Pine.LNX.4.44.0307312035410.633-100000@alice>

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" <pje@telecommunity.com> 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: <wudyv4k8.fsf@yahoo.co.uk>

"Phillip J. Eby" <pje@telecommunity.com> 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 <zack@codesourcery.com>:
> 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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


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: <oprs6u7psvqmnqtt@news.gmane.org>
References: <200307311806.12701.aleaxit@yahoo.com> <oprs6u7psvqmnqtt@news.gmane.org>
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 <aleaxit@yahoo.com>
>
> 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 <Numeric/arrayobject.h>

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: <C080001A-C3A1-11D7-B3AE-00039396E15A@mnot.net>

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 <Numeric/arrayobject.h>
>
> 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        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -