From noreply at sourceforge.net  Thu Jul  1 00:37:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 00:37:08 2004
Subject: [ python-Bugs-980925 ] Possible contradiction in "extending" and
	PyArg_ParseTuple()
Message-ID: <E1BftJp-0004Zf-00@sc8-sf-web2.sourceforge.net>

Bugs item #980925, was opened at 2004-06-27 20:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980925&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible contradiction in "extending" and PyArg_ParseTuple()

Initial Comment:
In section 1.3 of the "extending" tutorial (http://www.python.org/
dev/doc/devel/ext/backToExample.html), in the discussion of the 
use of PyArg_ParseTuple() for a string argument, it says that "in 
Standard C, the variable ... should properly be declared as "const 
char *" ".  But if you look at any example code (such as in section 
1.7, which covers parsing arguments; http://www.python.org/dev/
doc/devel/ext/parseTuple.html) and the docs for 
PyArg_ParseTuple() (found at http://www.python.org/dev/doc/
devel/api/arg-parsing.html) just use ``char *`` as the type for the 
argument for a string.

Which is correct?  I suspect that it is not required but more correct 
to have the variables declared ``const char *`` since you are not 
supposed to play with the string that is being pointed to (which is 
probably why the Unicode arguments in the docs for 
PyArg_ParseTuple() say it is ``const char *`` instead of just 
``char *``).  If this is true I will change the docs and the tutorial 
to use ``const char *``.  But if it isn't, I will rip out the line saying 
that you should ``const char *`` since this is a contradiction at the 
moment of recommended practice.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-01 00:37

Message:
Logged In: YES 
user_id=31435

"const char *" is best C practice, so the docs should 
encourage it, and that should be the officially documented 
signature.  All the standard C library functions to which it's 
safe to pass a string gotten via PyArg_ParseTuple already 
have const char* prototypes, so the danger of const 
poisoning (needing to supply a cascading number of casts) is 
minimal here.  Most of the likely Python C API functions to 
which we'd pass one of these things are already prototyped 
with const char* too (e.g., PyDict_GetItemString and 
PyString_InternFromString).  Some others should be.  Fighting 
a hopeless rear-guard reactionary battle isn't like Raymond -- 
don't listen to old farts, Brett, our youth is our future <wink>.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-28 23:50

Message:
Logged In: YES 
user_id=357491

Perhaps a comment about it then?  So it would still say ``char *`` in 
bold, but in the body mention that ``const char *`` is more proper, but 
could lead to extra casting.  Would that bump you to >= +0?

Regardless of that issue I went ahead and changed Doc/ext/extending.tex 
sans section 1.8 where the example is accredited to someone specific.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-28 11:51

Message:
Logged In: YES 
user_id=80475

-0 on changing anything here.  While technically correct,
the proposed revisions can potentially create issues where
none currently exist.  I ignore const and things work find.
 The last thing I want to see are coercions like (const char
*) sprouting-up here and there.  --my two cents

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-28 00:59

Message:
Logged In: YES 
user_id=357491

OK, I will definitely change the code examples.  How about the docs for 
PyArg_ParseTuple() for "s" and friends?  Should that stay ``char *`` as 
its listed argument type, or should I change that as well (Unicode 
arguments already say ``const char *`` so there is precedence).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-27 20:33

Message:
Logged In: YES 
user_id=31435

Most of Python, and its docs, were written before C89 
("Standard C") was required.  const is used sporadically as a 
result, mostly just in newer code and docs.

Changing examples to use const char * should be fine, as 
that is best C practice.  Just make sure the examples still 
work <wink -- but sticking "const" in has a way of 
propagating; e.g., once you have a const char *, you can't 
pass it directly to a function taking a (non-const) char * 
argument anymore>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980925&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 04:53:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 04:53:59 2004
Subject: [ python-Bugs-983269 ] incorrect len
Message-ID: <E1BfxKL-0004Jl-00@sc8-sf-web2.sourceforge.net>

Bugs item #983269, was opened at 2004-07-01 16:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983269&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: calvinlow (calvinlow)
Assigned to: Fredrik Lundh (effbot)
Summary: incorrect len

Initial Comment:
a=12345678901
len(`a`) returns 12.

notice that the the length of a numeric value after 10
digits is actually + 1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983269&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 05:42:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 05:42:33 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1Bfy5L-0006Gu-00@sc8-sf-web2.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 02:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 05:52:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 05:52:35 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1BfyF5-0006go-00@sc8-sf-web2.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 02:42
Message generated for change (Comment added) made by simon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

>Comment By: Simon Michael (simon)
Date: 2004-07-01 02:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 06:03:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 06:03:23 2004
Subject: [ python-Bugs-983269 ] incorrect len
Message-ID: <E1BfyPV-0001Rg-00@sc8-sf-web3.sourceforge.net>

Bugs item #983269, was opened at 2004-07-01 10:53
Message generated for change (Comment added) made by effbot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983269&group_id=5470

Category: Regular Expressions
Group: Python 2.3
>Status: Deleted
>Resolution: Rejected
Priority: 5
Submitted By: calvinlow (calvinlow)
Assigned to: Fredrik Lundh (effbot)
Summary: incorrect len

Initial Comment:
a=12345678901
len(`a`) returns 12.

notice that the the length of a numeric value after 10
digits is actually + 1

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2004-07-01 12:03

Message:
Logged In: YES 
user_id=38376

12345678901 is a long integer; `x` and repr(x) of long 
integers includes the trailing "L":

>>> a = 12345678901
>>> print repr(a)
12345678901L

to get just the digits, use str(x).  see the docs for more 
information on long integers and repr vs. str.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983269&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 06:34:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 06:34:41 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1Bfytp-00006X-00@sc8-sf-web1.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 05:42
Message generated for change (Comment added) made by ajung
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2004-07-01 06:34

Message:
Logged In: YES 
user_id=11084

Works for me with Python 2.3.3/4 on three different Linux
systems.


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 05:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 10:52:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 10:53:02 2004
Subject: [ python-Bugs-924301 ] A leak case with cmd.py &amp; readline &amp;
	exception
Message-ID: <E1Bg2vn-0002mw-00@sc8-sf-web2.sourceforge.net>

Bugs item #924301, was opened at 2004-03-27 00:28
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924301&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sverker Nilsson (svenil)
Assigned to: Michael Hudson (mwh)
Summary: A leak case with cmd.py &amp; readline &amp; exception

Initial Comment:
A leak to do with readline & cmd, in Python 2.3.

I found out what hold on to my interactive objects
too long ('for ever') in certain circumstances.  The
circumstance had to do with an exception being
raised in Cmd.cmdloop and handled (or not handled)
outside of Cmd.cmdloop.

In cmd.py, class Cmd, in cmdloop(), if an
exception is raised and propagated out from the
interior of cmdloop, the function postloop() is
not called. The default function of this, (in 2.3)
when the readline library is present, is to
restore the completer, via:

readline.set_completer(self.old_completer)

If this is not done, the newly (by preloop)
inserted completer will remain. Even if the loop
is called again and run without exception, the new
completer will remain, because then in postloop
the old completer will be set to our new
completer. When we exit, the completer will remain
the one we set. This will hold on to our object,
aka 'leak'. - In cmd.py in 2.2 no attempt was made
to restore the completer, so this was also a kind
of leak, but it was replaced the next time a Cmd
instance was initialized.  Now, however, the next
time we will not replace the old completer, but
both of them will remain in memory. The old one
will be stored as self.old_completer.  If we
terminate with an exception, bad luck... the
stored completer retains both of the instances. If
we terminate normally, the old one will be
retained.  In no case do we restore the space of
the first instance. The only way that would
happen, would be if the second instance first
exited the loop with an exception, and then
entered the loop again an exited normally. But
then, the second instance is retained instead! If
each instance happens to terminate with an
exception, it seems well possible that an ever
increasing chain of leaking instances will be
accumulated.

My fix is to always call the postloop, given the
preloop succeeded. This is done via a try:finally
clause.

    def cmdloop(self, intro=None):
	...

        self.preloop()
	try:
		...
	finally: # Make sure postloop called
	    self.postloop()

I am attaching my patched version of cmd.py.  It
was originally from the tarball of Python 2.3.3
downloaded from Python.org some month or so ago in
which cmd.py had this size & date:

14504 Feb 19 2003 cmd.py


Best regards,

Sverker Nilsson


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-01 15:52

Message:
Logged In: YES 
user_id=6656

Good.  Checked in as

Lib/cmd.py revision 1.38

If you want to fix any of the other issues, please file a separate 
patch...

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-06-30 17:20

Message:
Logged In: YES 
user_id=356603

I agree you should check it in. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-29 19:59

Message:
Logged In: YES 
user_id=6656

OK, so I was misreading (or reading an old version, or
something).

I agree with your comments about the bogosities, however
it's not my problem today :-)

Do you think I should check the attached patch in?  I do.

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-06-23 18:58

Message:
Logged In: YES 
user_id=356603

The constructor takes parameters stdin and stdout, and sets
self.stdin and self.stdout from them or from sys.
sys.std[in,out] are then not used directly except implicitly
by raw_input. This seems to have changed somewhere between
Python 2.2 and 2.3. Also, I remember an old version had the
cmdqueue list as a class variable which was not at all
thread safe - now it is an instance variable. I am
hoping/thinking it is thread safe now...

It seems  superfluos to have both the use_rawinput
flag and stdin parameter. At least raw_input should not
be used if stdin is some other file than the raw input.
But I don't have a simple suggestion to fix this, for one
thing, it wouldn't be sufficient to compare the stdin
parameter to sys.stdin since that file could have been
changed so it wasn't the raw stdin anymore. Perhaps the
module could store away the original sys.stdin as it was
imported... but that wouldn't quite work since there is no
guarantee sys.stdin hadn't already been changed. I guess if
it is worth the trouble, if someone has an idea, could be a
good thing to fix, anyway...


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-22 10:07

Message:
Logged In: YES 
user_id=6656

Um.  Unless I'm *hopelessly* misreading things, cmd.Cmd writes 
to sys.stdout unconditionally and either calls raw_input() or 
sys.stdin.readline().  So I'm not sure how one would "use a 
cmd.Cmd instance in a separate thread, talking eg via a socket 
file" without rewriting such huge amounts of the class that thread-
safety becomes your own problem.

Apologies if I'm being dumb... also, please note: I didn't write this 
module :-)

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-06-22 01:34

Message:
Logged In: YES 
user_id=356603

Your comment about threads worries me, I am not sure I
understand it. Would it be unsafe to use a cmd.Cmd instance
in a separate thread, talking eg via a socket file? The
instance is used only by that thread and not by others, but
there may be other threads using other instances. I
understand that it could be unsafe to have two threads share
the same instance, but how about different instances?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-21 11:35

Message:
Logged In: YES 
user_id=6656

Well, that would seem to be easy enough to fix (see attached).

If you're using cmd.Cmd instances from different threads at the 
same time, mind, I think you're screwed anyway.  You're certainly 
walking on thin ice...

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-06-18 20:13

Message:
Logged In: YES 
user_id=356603

I think it is OK.
Just noting that it changes the completer (just like my
version) even if use_rawinput is false. I guess one should
remember to pass a null completekey in that case, in case
some other thread was using raw_input. Perhaps a check for
use_rawinput could be added in cmd.py to avoid changing the
completer in that case, for less risk of future mistakes.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-11 13:29

Message:
Logged In: YES 
user_id=6656

yay, that appears to have worked.

let me know what you think.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-11 13:26

Message:
Logged In: YES 
user_id=6656

trying again...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-01 11:10

Message:
Logged In: YES 
user_id=6656

Bah.

I don't have the laptop with the patch with me, I'll try
uploading again in a couple of days.

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-05-29 08:43

Message:
Logged In: YES 
user_id=356603

I couldn't find a new attached file.
I acknowledge some problems with my original patch,
but have no other suggestion at the moment.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-05-26 17:36

Message:
Logged In: YES 
user_id=6656

What do you think of the attached?

This makes the documentation of pre & post loop more accurate 
again, which I think is nice.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-05-19 10:38

Message:
Logged In: YES 
user_id=6656

This is where I go "I wish I'd reviewed that patch more
carefully".

In particular, the documentation of {pre,post}loop is now
out of date.

I wonder setting/getting the completer in these functions
was a good idea.  Hmm.  This bug report confuses me :-) but
I can certainly see the intent of the patch...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-19 02:52

Message:
Logged In: YES 
user_id=80475

Michael, this touches some of your code.  Do you want to
handle this one?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924301&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 11:06:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 11:06:52 2004
Subject: [ python-Bugs-215126 ] Over restricted type checking on eval()
	function
Message-ID: <E1Bg39E-0003WQ-00@sc8-sf-web2.sourceforge.net>

Bugs item #215126, was opened at 2000-09-22 19:36
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Armin Rigo (arigo)
Summary: Over restricted type checking on eval() function

Initial Comment:
The built-in function eval() takes a string argument and a dictionary.  The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries.

The following example creates a type error:
  eval, argument 2: expected dictionary,   instance found

class SpreadSheet:
    _cells = {}
    def __setitem__( self, key, formula ):
        self._cells[key] = formula
    def __getitem__( self, key ):
        return eval( self._cells[key], self )

ss = SpreadSheet()
ss['a1'] = '5'
ss['a2'] = 'a1*5'
ss['a2']


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2004-07-01 15:06

Message:
Logged In: YES 
user_id=4771

Patch reviewed:

As eval(expr, mapping) is not accepted but eval(expr, {},
mapping) is, we could have a helpful error message along the
line of
  if (!PyDict_Check(globals)) {
      PyErr_SetString(PyExc_TypeError,
          PyMapping_Check(globals) ? 
              "globals must be a real dict; try eval(expr,
{}, mapping)"
            : "globals must be a dict");
  }

LOAD_NAME: you are doing a speed hack here we will bypass a
user-defined __getitem__ on a subclass of dict if the key
actually exists in the dictionary.  In other words your test
with the subclass of dict would fail if the dict aditionally
had another real value for the key 'a'.  Better use
PyDict_CheckExact() in all cases and only call
PyDict_GetItem() if it is true, as this is really cheap. 
Also, no PyErr_Clear() masking arbitrary exceptions please!


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-29 20:38

Message:
Logged In: YES 
user_id=80475

Are you comfortable doing this in two steps.  Commit the
patch as-is so that eval() works properly and then craft a
separate patch 
to thoroughly implement, test, and document the same thing
for exec and execfile()?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-29 10:36

Message:
Logged In: YES 
user_id=4771

Doing the type check in exec and execfile() but not in
eval() is not something that seems particularly useful to
me.  Any program can be written as an expression in Python
if you are crazy enough to do that...  So it doesn't offer
any extra security to be more strict in exec than in eval().
 People who really want to do it would have to go through
incredible pain just to work around the type check.

For the implications, I believe it is sufficient (and
necessary) to carefully review all usages of f_locals
throughout the code, and document f_locals as no longer
necessary a dictionary for those extension writers that
would have used this fact.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-29 08:51

Message:
Logged In: YES 
user_id=80475

Okay, a new patch is ready for second review.

It is essentially, Armin's patch with the following changes:

* leaves the syntax for eval() intact with no automatic
globals=locals trick

* has the faster approach for LOAD_NAME, incorporating your
suggestion for PyDict_CheckExact

* omits the code to enable the same liberties for '.exec'. 
That is beyond the OP's request and well beyond something
whose implications I've thought through.  Am not opposed to
it, but would like it to be left for a separate patch with
thorough unittests.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 18:08

Message:
Logged In: YES 
user_id=80475

Nix, that last comment.  Have examples that call setitem().

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 17:36

Message:
Logged In: YES 
user_id=80475

Changed to PyDict_CheckExact().

Are you sure about having to change the sets and dels.  I've
tried several things at the interactive prompt and can't get
it to fail:

  >>> [locals() for i in (2,3)]

Do you have any examples (in part, so I can use them as test
cases)?


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-27 11:33

Message:
Logged In: YES 
user_id=4771

eval() can set items in the locals, e.g. by using list comprehension.  Moreover the ability to exec in custom dicts would be extremely useful too, e.g. to catch definitions while they appear.

If you really want to avoid any performance impact, using PyDict_CheckExact() in all critical parts looks good (do not use PyDict_Check(), it's both slower and not what we want because it prevents subclasses of dicts to override __xxxitem__).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 08:37

Message:
Logged In: YES 
user_id=80475

Okay, the patch is ready for second review.
Attaching the revision with unittests.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 07:50

Message:
Logged In: YES 
user_id=80475

Attaching my minimal version of the patch.  It runs the
attached demo without exception and does not measurably show
on any of my timings.

The approach is to restrict the generalization to eval()
instead of exec().  Since eval() can't set values in the
locals dict, no changes  are needed to the setitem and
delitem calls.  Instead of using PyObject_GetItem()
directly, I do a regular lookup and fallback to the
generalizaiton if necessary -- this is why the normal case
doesn't get slowed down (the cost is a PyDict_Check which
uses values already in cache, and a branch predicatable
comparison)..

While the demo script runs, and the test_suite passes, it is
slightly too simple and doesn't yet handle eval('dir()',
globals(), M()) where M is a non-dict mapping.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-23 16:59

Message:
Logged In: YES 
user_id=80475

The quick patch works fine.

Do change the PyArg_ParseTuple() into the faster
PyArg_UnpackTuple().

Does this patch show any changes to pystone or other key
metrics?  Would the PyDict_GetItem trick have better
performance?  My guess is that it would.

+1 on using PyMapping_Check() for checking the locals
argument to eval().  That is as good as you can get without
actually running it.



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-22 21:07

Message:
Logged In: YES 
user_id=4771

Quick patch attached.  I didn't try to use the PyDict_GetItem trick described, but just systematically use PyObject_GetItem/SetItem/DelItem when working with f_locals.

This might confuse some extension modules that expect PyEval_GetLocals() to return a dict object.

The eval trick is now: eval(code, nondict) --> eval(code, globals(), nondict).

Besides eval() I removed the relevant typecheck from execfile() and the exec statement.  Any other place I am missing?

We might want to still somehow check the type of the locals, to avoid strange errors caused by e.g. eval("a", "b").  PyMapping_Check() is the obvious candidate, but it looks like a hack.

More testing is needed.  test_descrtut.py line 84 now succeeds, unexpectedly, which is interpreted as a test failure.

Needs some docs, too.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-12 07:27

Message:
Logged In: YES 
user_id=80475

Armin, can you whip-up a quick patch so that we can explore
the implications of your suggestion.  Ideally, I would like
to see something like this go in for Py2.4.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-22 16:53

Message:
Logged In: YES 
user_id=80475

+1

Amrin's idea provides most of the needed functionality with
zero performance impact.  

Also, using a local dictionary for the application variables
is likely to be just exactly what a programmer would want to do.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-05-19 18:21

Message:
Logged In: YES 
user_id=4771

With minimal work and performance impact, we could allow
frame->f_locals to be something else than a real dictionary.
 It looks like it would be easily possible as long as we
don't touch the time-critical frame->f_globals.  Code
compiled by eval() always uses LOAD_NAME and STORE_NAME,
which is anyway allowed to be a bit slower than LOAD_FAST or
LOAD_GLOBAL.

Note that PyDict_GetItem() & co., as called by
LOAD/STORE_NAME, do a PyDict_Check() anyway.  We could just
replace it with PyDict_CheckExact() and if it fails fall
back to calling the appropriate ob_type->tp_as_mapping
method.  This would turn some of the PyDict_Xxx() API into a
general mapping API, half-way between its current dict-only
usage and the fully abstract PyObject_Xxx() API.

This is maybe a bit strange from the user's point of view,
because eval("expr", mydict) still wouldn't work: only
eval("expr", {}, mydict) would.
which does which does 
Now, there is no way I can think of that code compiled by
eval() could contain LOAD_GLOBAL or STORE_GLOBAL.  The only
way to tell the difference between eval("expr", mydict) and
eval("expr", {}, mydict) appears to be by calling globals()
or somehow inspecting the frame directly.  Therefore it
might be acceptable to redefine the two-argument eval(expr,
dict) to be equivalent not to eval(expr, dict, dict) but
eval(expr, {}, dict).  This hack might be useful enough even
if it won't work with the exec statement.

----------------------------------------------------------------------

Comment By: Philippe Fremy (pfremy)
Date: 2004-03-03 09:40

Message:
Logged In: YES 
user_id=233844

I have exactly the same need as the original poster. The
only difference in my case is that I inhreted a dictionnary.

I want to use the eval() function as a simple expression
evaluator. I have the
follwing dictionnary:
d['a']='1'
d['b']='2'
d['c']='a+b'

I want the following results:
d[a] -> 1 
d[b] -> 2 
d[c] -> 3

To do that, I was planning to use the eval() function and
overloading the __getitem__ of the global or local dictionnary:

class MyDict( dict ) : 
	def __getitem__( self, key ):
		print "__getitem__", key
		val = dict.__getitem__( self, key )
		print "val = '%s'" % val
		return eval( val , self )

But it does not work:
d[a]:
__getitem__ a
val = '1'
-> 1

d[b]:
__getitem__ b
val = '2'
-> 2

d[c]:
__getitem__ c
val = 'e+1'
ERROR
Traceback (most recent call last):
  File "test_parse_jaycos_config.py", line 83, in testMyDict
    self.assertEquals( d['c'], 2 )
  File "parse_config_file.py", line 10, in __getitem__
    return eval( val , self )
  File "<string>", line 0, in ?
TypeError: cannot concatenate 'str' and 'int' objects

d['c'] did fetch the 'a+1' value, which was passed to eval.
However, eval()
tried to evaluate the expression using the content of the
dictionnary instead
of using __getitem__. So it fetched the string '1' for 'a'
instead of the value 1, so the result is not suitable for
the addition.



----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-01-12 22:01

Message:
Logged In: YES 
user_id=99874

Hmm... I like this!

Of course, I am wary of adding *yet another* special double-
underscore function to satisfy a single special purpose, but 
this would satisfy all of *my* needs, and without any 
performance impact for lookups that are FOUND. Lookups that 
are NOT found would have a slight performance degrade (I 
know better than to speculate about the size of the effect 
without measuring it). I'm not really sure what percentage of 
dict lookups succeed.

At any rate, what are these "other contexts" you mention in 
which a __keyerror__ would "also be useful"? Because if we 
can find other places where it is useful, that significantly 
improves the usefulness.

OTOH, if the tests can be done ONLY for eval (I don't really 
think that's possible), then I'm certain no one cares about the 
performance of eval.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2004-01-12 19:38

Message:
Logged In: YES 
user_id=292741

This may be  a compromise solution, which could also be
useful in other contexts: What if the object passed
is derived from dict - presumably that doesn't help
because the point is to do low-level calls to the
actual dict's lookup functions.
 Now, suppose we modify the basic dict type, so
that before throwing
a KeyError, it checks to see if it is really a derived
object with a method __keyerror__, and if so, calls
that and returns its result (or lets it throw)?
Now you can make objects that look like dicts, and
act like them at the low level, but can automatically
populate themselves when non-existent keys are requested.
Of course, __keyerror__('x') does not have to make
an 'x' entry in the dict; it could make no change, or
add several entries, depending on the desired semantics
regarding future lookups. It could be set up so that
every lookup fails and is forwarded by __keyerror__ to
the __getitem__ of another object, for instance.

The cost of this to the 'normal' dict lookup is that
the need to do PyDict_CheckExact() each time
a lookup fails.


----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2003-12-16 15:37

Message:
Logged In: YES 
user_id=99874

I'll just add my voice as somebody who would find this to 
be &quot;darn handy&quot; if it could ever done without noticably 
impacting the speed of python code that DOESN'T use eval().

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-23 04:18

Message:
Added to PEP 42.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-22 19:42

Message:
Changed Group to Feature Request.  Should be added to PEP 42 (I'll do that if nobody beats me to it).

CPython requires a genuine dict now for speed.  I believe JPython allows any mapping object.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 11:20:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 11:20:24 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1Bg3MK-00031n-00@sc8-sf-web1.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 09:42
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2004-07-01 15:20

Message:
Logged In: YES 
user_id=4771

If this bug involves C extension modules specific to Zope
then I'd first consider it as a bug in one of these modules.
 I would be particularly suspicious that this is the case in
a file called testSecurity: isn't its goal to check some
C-implemented security feature of Zope?

If I am wrong please try to provide a Python code sample. 
Reading a class attribute out of some class tends to work
just fine.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2004-07-01 10:34

Message:
Logged In: YES 
user_id=11084

Works for me with Python 2.3.3/4 on three different Linux
systems.


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 09:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 14:15:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 14:15:49 2004
Subject: [ python-Bugs-983585 ] test_repr() fails with id() values that
	appear negative
Message-ID: <E1Bg665-0002Mi-00@sc8-sf-web2.sourceforge.net>

Bugs item #983585, was opened at 2004-07-01 14:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983585&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_repr() fails with id() values that appear negative

Initial Comment:
test_repr() fails when memory allocations are handed
out at high addresses.

test_repr
test test_repr failed -- Traceback (most recent call last):
  File
"/home/fdrake/projects/python/trunk/Lib/test/test_repr.py",
line 109, in test_instance
    eq(r(i3), ("<ClassWithFailingRepr instance at
%x>"%id(i3)))
AssertionError: '<ClassWithFailingRepr instance at
x42373cf4>' != '<ClassWithFailingRepr instance at
-42373cf4>'
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983585&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 14:16:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 14:16:48 2004
Subject: [ python-Bugs-983585 ] test_repr() fails with id() values that
	appear negative
Message-ID: <E1Bg672-0002Ok-00@sc8-sf-web2.sourceforge.net>

Bugs item #983585, was opened at 2004-07-01 14:15
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983585&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_repr() fails with id() values that appear negative

Initial Comment:
test_repr() fails when memory allocations are handed
out at high addresses.

test_repr
test test_repr failed -- Traceback (most recent call last):
  File
"/home/fdrake/projects/python/trunk/Lib/test/test_repr.py",
line 109, in test_instance
    eq(r(i3), ("<ClassWithFailingRepr instance at
%x>"%id(i3)))
AssertionError: '<ClassWithFailingRepr instance at
x42373cf4>' != '<ClassWithFailingRepr instance at
-42373cf4>'
 

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-01 14:16

Message:
Logged In: YES 
user_id=3066

I'll add that this was run on a Fedora Core 1 system.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983585&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 15:25:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 15:25:46 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1Bg7Bj-0004vL-00@sc8-sf-web2.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 02:42
Message generated for change (Comment added) made by simon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

>Comment By: Simon Michael (simon)
Date: 2004-07-01 12:25

Message:
Logged In: YES 
user_id=572

UnownedDTML is indeed a zope extension class.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 08:20

Message:
Logged In: YES 
user_id=4771

If this bug involves C extension modules specific to Zope
then I'd first consider it as a bug in one of these modules.
 I would be particularly suspicious that this is the case in
a file called testSecurity: isn't its goal to check some
C-implemented security feature of Zope?

If I am wrong please try to provide a Python code sample. 
Reading a class attribute out of some class tends to work
just fine.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2004-07-01 03:34

Message:
Logged In: YES 
user_id=11084

Works for me with Python 2.3.3/4 on three different Linux
systems.


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 02:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 16:21:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 16:21:26 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1Bg83d-00049r-00@sc8-sf-web4.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 09:42
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2004-07-01 20:21

Message:
Logged In: YES 
user_id=4771

What I mean here is that you should report this bug to Zope, not to Python, unless there is a good reason to suspect that a bug in the Python core is causing it.  But to me it really looks like a bug in the Zope extension module, which for some reason shows up only with some version of Python or on some platform.

----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 19:25

Message:
Logged In: YES 
user_id=572

UnownedDTML is indeed a zope extension class.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 15:20

Message:
Logged In: YES 
user_id=4771

If this bug involves C extension modules specific to Zope
then I'd first consider it as a bug in one of these modules.
 I would be particularly suspicious that this is the case in
a file called testSecurity: isn't its goal to check some
C-implemented security feature of Zope?

If I am wrong please try to provide a Python code sample. 
Reading a class attribute out of some class tends to work
just fine.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2004-07-01 10:34

Message:
Logged In: YES 
user_id=11084

Works for me with Python 2.3.3/4 on three different Linux
systems.


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 09:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 16:02:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 16:21:28 2004
Subject: [ python-Bugs-983585 ] test_repr() fails with id() values that
	appear negative
Message-ID: <E1Bg7kw-0003VF-00@sc8-sf-web4.sourceforge.net>

Bugs item #983585, was opened at 2004-07-01 14:15
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983585&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: test_repr() fails with id() values that appear negative

Initial Comment:
test_repr() fails when memory allocations are handed
out at high addresses.

test_repr
test test_repr failed -- Traceback (most recent call last):
  File
"/home/fdrake/projects/python/trunk/Lib/test/test_repr.py",
line 109, in test_instance
    eq(r(i3), ("<ClassWithFailingRepr instance at
%x>"%id(i3)))
AssertionError: '<ClassWithFailingRepr instance at
x42373cf4>' != '<ClassWithFailingRepr instance at
-42373cf4>'
 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-01 16:02

Message:
Logged In: YES 
user_id=31435

Fred, please try the attached patch.  If it works on your box, 
just check it in.  repr.py was doing a dumb thing, assuming 
that hex(number) always starts with '0x'.  The patch also 
does a dumb thing, but it's the same as the dumb thing 
test_repr.py does <wink>.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-01 14:16

Message:
Logged In: YES 
user_id=3066

I'll add that this was run on a Fedora Core 1 system.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983585&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 16:29:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 16:29:19 2004
Subject: [ python-Bugs-983585 ] test_repr() fails with id() values that
	appear negative
Message-ID: <E1Bg8BG-0000cH-00@sc8-sf-web3.sourceforge.net>

Bugs item #983585, was opened at 2004-07-01 14:15
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983585&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: test_repr() fails with id() values that appear negative

Initial Comment:
test_repr() fails when memory allocations are handed
out at high addresses.

test_repr
test test_repr failed -- Traceback (most recent call last):
  File
"/home/fdrake/projects/python/trunk/Lib/test/test_repr.py",
line 109, in test_instance
    eq(r(i3), ("<ClassWithFailingRepr instance at
%x>"%id(i3)))
AssertionError: '<ClassWithFailingRepr instance at
x42373cf4>' != '<ClassWithFailingRepr instance at
-42373cf4>'
 

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-01 16:29

Message:
Logged In: YES 
user_id=3066

This does the trick, thanks!

Committed as Lib/repr.py revision 1.20.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-01 16:02

Message:
Logged In: YES 
user_id=31435

Fred, please try the attached patch.  If it works on your box, 
just check it in.  repr.py was doing a dumb thing, assuming 
that hex(number) always starts with '0x'.  The patch also 
does a dumb thing, but it's the same as the dumb thing 
test_repr.py does <wink>.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-01 14:16

Message:
Logged In: YES 
user_id=3066

I'll add that this was run on a Fedora Core 1 system.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983585&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 16:58:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 16:58:12 2004
Subject: [ python-Bugs-980925 ] Possible contradiction in "extending" and
	PyArg_ParseTuple()
Message-ID: <E1Bg8dE-0005a2-00@sc8-sf-web4.sourceforge.net>

Bugs item #980925, was opened at 2004-06-27 17:02
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980925&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible contradiction in "extending" and PyArg_ParseTuple()

Initial Comment:
In section 1.3 of the "extending" tutorial (http://www.python.org/
dev/doc/devel/ext/backToExample.html), in the discussion of the 
use of PyArg_ParseTuple() for a string argument, it says that "in 
Standard C, the variable ... should properly be declared as "const 
char *" ".  But if you look at any example code (such as in section 
1.7, which covers parsing arguments; http://www.python.org/dev/
doc/devel/ext/parseTuple.html) and the docs for 
PyArg_ParseTuple() (found at http://www.python.org/dev/doc/
devel/api/arg-parsing.html) just use ``char *`` as the type for the 
argument for a string.

Which is correct?  I suspect that it is not required but more correct 
to have the variables declared ``const char *`` since you are not 
supposed to play with the string that is being pointed to (which is 
probably why the Unicode arguments in the docs for 
PyArg_ParseTuple() say it is ``const char *`` instead of just 
``char *``).  If this is true I will change the docs and the tutorial 
to use ``const char *``.  But if it isn't, I will rip out the line saying 
that you should ``const char *`` since this is a contradiction at the 
moment of recommended practice.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-01 13:58

Message:
Logged In: YES 
user_id=357491

My youth caused rev. 1.15 on Doc/api/utilities.tex to help move us 
forward to a more correct ISO C89 programming world.

Now we just need to move CPython over to C99 before I start telling 
people *their* youth is *my* future and everything will be set.  =)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-30 21:37

Message:
Logged In: YES 
user_id=31435

"const char *" is best C practice, so the docs should 
encourage it, and that should be the officially documented 
signature.  All the standard C library functions to which it's 
safe to pass a string gotten via PyArg_ParseTuple already 
have const char* prototypes, so the danger of const 
poisoning (needing to supply a cascading number of casts) is 
minimal here.  Most of the likely Python C API functions to 
which we'd pass one of these things are already prototyped 
with const char* too (e.g., PyDict_GetItemString and 
PyString_InternFromString).  Some others should be.  Fighting 
a hopeless rear-guard reactionary battle isn't like Raymond -- 
don't listen to old farts, Brett, our youth is our future <wink>.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-28 20:50

Message:
Logged In: YES 
user_id=357491

Perhaps a comment about it then?  So it would still say ``char *`` in 
bold, but in the body mention that ``const char *`` is more proper, but 
could lead to extra casting.  Would that bump you to >= +0?

Regardless of that issue I went ahead and changed Doc/ext/extending.tex 
sans section 1.8 where the example is accredited to someone specific.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-28 08:51

Message:
Logged In: YES 
user_id=80475

-0 on changing anything here.  While technically correct,
the proposed revisions can potentially create issues where
none currently exist.  I ignore const and things work find.
 The last thing I want to see are coercions like (const char
*) sprouting-up here and there.  --my two cents

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-27 21:59

Message:
Logged In: YES 
user_id=357491

OK, I will definitely change the code examples.  How about the docs for 
PyArg_ParseTuple() for "s" and friends?  Should that stay ``char *`` as 
its listed argument type, or should I change that as well (Unicode 
arguments already say ``const char *`` so there is precedence).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-27 17:33

Message:
Logged In: YES 
user_id=31435

Most of Python, and its docs, were written before C89 
("Standard C") was required.  const is used sporadically as a 
result, mostly just in newer code and docs.

Changing examples to use const char * should be fine, as 
that is best C practice.  Just make sure the examples still 
work <wink -- but sticking "const" in has a way of 
propagating; e.g., once you have a const char *, you can't 
pass it directly to a function taking a (non-const) char * 
argument anymore>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980925&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 17:57:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 17:57:39 2004
Subject: [ python-Bugs-977343 ] Solaris likes sys/loadavg.h
Message-ID: <E1Bg9Yi-0001SG-00@sc8-sf-web1.sourceforge.net>

Bugs item #977343, was opened at 2004-06-22 10:19
Message generated for change (Comment added) made by chomo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977343&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Solaris likes sys/loadavg.h

Initial Comment:
Recent Solaris puts the prototype for getloadavg() in
<sys/loadavg.h>

The following patch adds a configure check for
sys/loadavg.h, 
and #includes it in Modules/posixmodule.c

If someone can give it a cursory glance, I'll check it in.



----------------------------------------------------------------------

Comment By: alan johnson (chomo)
Date: 2004-07-01 21:57

Message:
Logged In: YES 
user_id=943591

sounds alright

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-06-22 18:14

Message:
Logged In: YES 
user_id=21627

Looks fine, please apply.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977343&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 18:05:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 18:05:10 2004
Subject: [ python-Bugs-965206 ] importing dynamic modules via embedded python
Message-ID: <E1Bg9g1-0007iG-00@sc8-sf-web4.sourceforge.net>

Bugs item #965206, was opened at 2004-06-02 18:42
Message generated for change (Comment added) made by chomo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=965206&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anne Wilson (awilson123456)
Assigned to: Nobody/Anonymous (nobody)
Summary: importing dynamic modules via embedded python

Initial Comment:
I had existing C and Python code in which the C code
invoked the Python interpreter via a system call.  For
efficiency reasons, the code needed modification to
invoke the interpreter directly from the code.  This is
a Fedora Core Linux system using Python 2.2.

Based on the Extending/Embedding documentation it all
seemed very easy, but it was not.  It cost me 12 hours
just to figure out why both PyImport_Import and
PyImport_ImportModule would fail.  Turns on that when
embeddeding Python and importing dynamically linked
modules or modules that in turn import dynamically
linked modules, the code must be linked with the -Wl,-E
option to the compiler (e.g. the -E option to ld).

In my up-until-then-blissful ignorance, I didn't know
(or care) that some modules were statically linked
while others were dynamic.  And, of course, I was
clueless about the implications wrt embedded Python. 
It took much painful debugging to track this down. 
(Special thanks to Bob Hepple and Jim Bublitz for
helping me sort this out.)

This should be mentioned up front in the documentation.

Thanks!

Anne



----------------------------------------------------------------------

Comment By: alan johnson (chomo)
Date: 2004-07-01 22:05

Message:
Logged In: YES 
user_id=943591

needs documenting

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=965206&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 19:52:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 19:52:49 2004
Subject: [ python-Bugs-935091 ] bdist_winist post-install script fails on
	non-admin Python
Message-ID: <E1BgBM9-0004yD-00@sc8-sf-web1.sourceforge.net>

Bugs item #935091, was opened at 2004-04-15 03:54
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=935091&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David R. Handy (davidhandy)
Assigned to: Thomas Heller (theller)
Summary: bdist_winist post-install script fails on non-admin Python

Initial Comment:
Python version 2.3.3
Windows 98

If you install Python on Windows, and you selected a
"Non Admin" install, then later on when you run any
distutils-created installer that has a post-install
script, the post-install script will not run. This in
turn causes shortcuts to not be created, skips
additional install steps, etc.

The reason for this is pretty simple: a non-admin
install of Python puts python23.dll in the C:\Python23
directory instead of in C:\WINDOWS\SYSTEM (or the
equivalent on your version of windows). The extractor
stub used by bdist_wininst does a simple LoadLibrary(),
with no path information, to get python23.dll. This
only looks in the current directory or in the PATH.

What the extractor stub program ought to do in this
case is a LoadLibrary() giving the full path (i.e.
C:\Python23\python23.dll) since the Python installation
directory is known.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-02 09:52

Message:
Logged In: YES 
user_id=14198

I can't repro this on the trunk at the moment - a non-admin
install of Python allowed my non-admin user to correctly
install an extension with a post-install script.

The log of install.c shows Thomas did it in revision 1.4, so
I'm closing this as fixed.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-05-12 01:16

Message:
Logged In: YES 
user_id=11105

This is already fixed in the release23-maint branch, so it
should be fixed in Python 2.3.4.
I will port this to the trunk later.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=935091&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 20:34:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 20:34:14 2004
Subject: [ python-Bugs-982215 ] Next button not greyed out during file copy.
Message-ID: <E1BgC0E-0005z9-00@sc8-sf-web2.sourceforge.net>

Bugs item #982215, was opened at 2004-06-30 05:54
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982215&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Rittenhouse (prittenh)
Assigned to: Thomas Heller (theller)
Summary:  Next button not greyed out during file copy.

Initial Comment:
I've noticed a problem with a couple of distutils based
installers (py2exe and pywin32) that I think may be a
problem in all distutils based windows installers.

When you click Next to start the file copy, the Next 
button is not greyed out or disabled.  If you click it 
again, it seems to start another file copy process 
running, because you then get an "Overwrite Existing 
Files?" dialog.  If you click Yes, the install may throw a 
Runtime Error with the message "The process cannot 
access the file because it is being used by another 
process..." and it may lock up.

I'm running Python 2.3.3 and have seen this in py2exe 
0.5.0 and pywin32 build 201.  I have tried a number of 
Windows OSs including 2000 and ME.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-02 10:34

Message:
Logged In: YES 
user_id=14198

I see this too!  Attached is a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982215&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 20:41:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 20:41:22 2004
Subject: [ python-Bugs-870479 ] Scripts need platform-dependent handling
Message-ID: <E1BgC7A-00068d-00@sc8-sf-web1.sourceforge.net>

Bugs item #870479, was opened at 2004-01-05 06:00
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Cederqvist (ceder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Scripts need platform-dependent handling

Initial Comment:
When a  script is installed on Unix, it should be named
something like "mailman-discard", with no extension.
When it is installed on Windows, it should be named
"mailman-discard.py", so that it is associated with
Python.  I think that "scripts" should be smart enough
to handle this.

My suggestion is that "scripts" should be set to a list
of the scripts, including the extension, and that
distutils will remove the extension when it installs
programs on platforms where this is true:

    os.name == 'posix'

It is possible to override the install_scripts class to
get this behaviour, but if you want to make a binary
distribution you also have to override bdist_wininst,
et c, since the install_scripts class is used on the
host system while building a directory tree that will
later be installed on the target system. See this
example script:

http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/mailman-discard/setup.py?rev=1.2&cvsroot=mailman-discard&content-type=text/vnd.viewcvs-markup
 
Peter ?strand also suggests that on Windows, you should
create a command file named "mailman-discard.cmd" and
put it in the same directory as the
"mailman-discard.py" file.  It should contain a single
line:

start %~dp0\mailman-discard.py

That way, you will be able to start the script from a
dos shell, and not just by double-clicking it in a file
browser.  It would be nice if Distutils created this
file automatically when installing on the win32 platform.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-02 10:41

Message:
Logged In: YES 
user_id=14198

The obvious issue is that we can't change the semantics for
packages already out there.  Existing package maintainers
will not want this change made for them automatically, and
it is not clear that this is the desirable default behaviour
anyway.  Therefore, this isn't going to be considered a 'bug'.

I think what you are asking for is a new feature - a way to
give distutils the behaviour you desire, but leaving the
default semantics alone.  I suggest you close this bug as
"wont fix", and add a new feature request.  After that, try
and get some support for your idea from someone willing or
able to submit a patch.

----------------------------------------------------------------------

Comment By: Per Cederqvist (ceder)
Date: 2004-01-06 05:44

Message:
Logged In: YES 
user_id=129207

You have convinced me that the ".cmd" file was a bad idea,
so let's forget I ever mentioned it.

I still think that the extension should be removed on POSIX
platforms, however.  However, if you have "foo.py" and
"foo.sh" they would both end up as "foo"; this should
produce a diagnostic.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-06 03:25

Message:
Logged In: YES 
user_id=113328

Having a ".cmd" file isn't a good idea. For a start, it isn't 
Windows 9x compatible (and %~dp0 isn't available in 
command.com). Also, you need to include a way of passing 
any command line arguments on to the script. And 
finally, "start" probably isn't right. This will run the command 
in a new console window, rather than in the existing console.

A XXX.cmd file which just does @%~dp0\XXX.py %* is 
better, but I still don't think it's needed. Just adding ".py" to 
PATHEXT (which is something the user can do if they want, 
at the same time they add the Python scripts directory to 
their PATH) is enough, at least on NT/2000/XP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 20:46:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 20:46:59 2004
Subject: [ python-Bugs-809846 ] distutils/bdistwin32 doesn't clean up RO
	files properly
Message-ID: <E1BgCCd-0006Fj-00@sc8-sf-web1.sourceforge.net>

Bugs item #809846, was opened at 2003-09-21 03:49
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809846&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils/bdistwin32 doesn't clean up RO files properly

Initial Comment:
Using Windows XP SP1, Python 2.3, Win32Extensions 
build 159:

I recently added some data_files to my setup script as 
so:

setup( ..., data_files = [ ( 'files', ['file.txt'] ) ] )

and when I ran my setup script with the build 
option 'bdist_wininst', I get the following error at the 
cleanup stage of the build:

removing 'build\bdist.win32\wininst' (and everything 
under it)
error removing build\bdist.win32\wininst: 
build\bdist.win32\wininst\DATA\file.txt: Permission denied

The error is followed by more errors attempting to 
remove the parent directories because they're not 
empty.

The reason permission is denied is because the file is 
marked as read-only (via file attributes, not file 
permissions).  The source file is marked as read-only in 
this case because it is being taken from a Visual 
SourceSafe project which uses the RO attribute to 
indicate check-out status.  If I check out the file or 
remove the RO flag, the script runs without errors.

Regardless of the reason for a file being marked RO, the 
temporary files in wininst\DATA should not be copied 
with their RO attribute or when cleaning up, the routine 
should delete the files regardless of RO status.

I'm not sure what is the best way to approach this 
problem, but I will be willing to provide input or even 
code patches.  I need input from the community, 
however, on how to best fix this issue.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-02 10:46

Message:
Logged In: YES 
user_id=14198

Do other distutils commands suffer the same problem cleaning
their temp files?  If so, the problem is a little more
delicate (special-casing these attributes on Linux, for
example, would be non-trivial), but if only bdist_win32 has
the problem we could be more brutal (there are very few
attributes we need to worry about!).

The other potential problem is that people may actually want
this r/o attribute to end up on the installed file - which
means the installer and uninstaller need to deal with it too.

So I too am unsure what the "correct" thing to do is.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809846&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 21:02:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 21:03:09 2004
Subject: [ python-Bugs-870479 ] Scripts need platform-dependent handling
Message-ID: <E1BgCS1-0006eX-00@sc8-sf-web1.sourceforge.net>

Bugs item #870479, was opened at 2004-01-04 14:00
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Cederqvist (ceder)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Scripts need platform-dependent handling

Initial Comment:
When a  script is installed on Unix, it should be named
something like "mailman-discard", with no extension.
When it is installed on Windows, it should be named
"mailman-discard.py", so that it is associated with
Python.  I think that "scripts" should be smart enough
to handle this.

My suggestion is that "scripts" should be set to a list
of the scripts, including the extension, and that
distutils will remove the extension when it installs
programs on platforms where this is true:

    os.name == 'posix'

It is possible to override the install_scripts class to
get this behaviour, but if you want to make a binary
distribution you also have to override bdist_wininst,
et c, since the install_scripts class is used on the
host system while building a directory tree that will
later be installed on the target system. See this
example script:

http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/mailman-discard/setup.py?rev=1.2&cvsroot=mailman-discard&content-type=text/vnd.viewcvs-markup
 
Peter ?strand also suggests that on Windows, you should
create a command file named "mailman-discard.cmd" and
put it in the same directory as the
"mailman-discard.py" file.  It should contain a single
line:

start %~dp0\mailman-discard.py

That way, you will be able to start the script from a
dos shell, and not just by double-clicking it in a file
browser.  It would be nice if Distutils created this
file automatically when installing on the win32 platform.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-01 21:02

Message:
Logged In: YES 
user_id=31435

Note this was an active topic on distutils-sig last week.  
Assigned to Fred in hopes that he can summarize current 
thinking as a comment here.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-01 20:41

Message:
Logged In: YES 
user_id=14198

The obvious issue is that we can't change the semantics for
packages already out there.  Existing package maintainers
will not want this change made for them automatically, and
it is not clear that this is the desirable default behaviour
anyway.  Therefore, this isn't going to be considered a 'bug'.

I think what you are asking for is a new feature - a way to
give distutils the behaviour you desire, but leaving the
default semantics alone.  I suggest you close this bug as
"wont fix", and add a new feature request.  After that, try
and get some support for your idea from someone willing or
able to submit a patch.

----------------------------------------------------------------------

Comment By: Per Cederqvist (ceder)
Date: 2004-01-05 13:44

Message:
Logged In: YES 
user_id=129207

You have convinced me that the ".cmd" file was a bad idea,
so let's forget I ever mentioned it.

I still think that the extension should be removed on POSIX
platforms, however.  However, if you have "foo.py" and
"foo.sh" they would both end up as "foo"; this should
produce a diagnostic.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-05 11:25

Message:
Logged In: YES 
user_id=113328

Having a ".cmd" file isn't a good idea. For a start, it isn't 
Windows 9x compatible (and %~dp0 isn't available in 
command.com). Also, you need to include a way of passing 
any command line arguments on to the script. And 
finally, "start" probably isn't right. This will run the command 
in a new console window, rather than in the existing console.

A XXX.cmd file which just does @%~dp0\XXX.py %* is 
better, but I still don't think it's needed. Just adding ".py" to 
PATHEXT (which is something the user can do if they want, 
at the same time they add the Python scripts directory to 
their PATH) is enough, at least on NT/2000/XP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 21:52:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 21:52:13 2004
Subject: [ python-Bugs-870479 ] Scripts need platform-dependent handling
Message-ID: <E1BgDDi-0007vL-00@sc8-sf-web1.sourceforge.net>

Bugs item #870479, was opened at 2004-01-05 06:00
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Cederqvist (ceder)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Scripts need platform-dependent handling

Initial Comment:
When a  script is installed on Unix, it should be named
something like "mailman-discard", with no extension.
When it is installed on Windows, it should be named
"mailman-discard.py", so that it is associated with
Python.  I think that "scripts" should be smart enough
to handle this.

My suggestion is that "scripts" should be set to a list
of the scripts, including the extension, and that
distutils will remove the extension when it installs
programs on platforms where this is true:

    os.name == 'posix'

It is possible to override the install_scripts class to
get this behaviour, but if you want to make a binary
distribution you also have to override bdist_wininst,
et c, since the install_scripts class is used on the
host system while building a directory tree that will
later be installed on the target system. See this
example script:

http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/mailman-discard/setup.py?rev=1.2&cvsroot=mailman-discard&content-type=text/vnd.viewcvs-markup
 
Peter ?strand also suggests that on Windows, you should
create a command file named "mailman-discard.cmd" and
put it in the same directory as the
"mailman-discard.py" file.  It should contain a single
line:

start %~dp0\mailman-discard.py

That way, you will be able to start the script from a
dos shell, and not just by double-clicking it in a file
browser.  It would be nice if Distutils created this
file automatically when installing on the win32 platform.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-02 11:52

Message:
Logged In: YES 
user_id=14198

Thanks Tim - I found the thread - interesting, and funnily
enough covers the same issues!  I also note
www.python.org/sf/976869 which is where Fred has made a patch.

My summary: nothing should be done implicitly.  Whatever is
done must be explicitly specified by the packager.  However,
no one is sure exactly how to spell it yet.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-02 11:02

Message:
Logged In: YES 
user_id=31435

Note this was an active topic on distutils-sig last week.  
Assigned to Fred in hopes that he can summarize current 
thinking as a comment here.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-02 10:41

Message:
Logged In: YES 
user_id=14198

The obvious issue is that we can't change the semantics for
packages already out there.  Existing package maintainers
will not want this change made for them automatically, and
it is not clear that this is the desirable default behaviour
anyway.  Therefore, this isn't going to be considered a 'bug'.

I think what you are asking for is a new feature - a way to
give distutils the behaviour you desire, but leaving the
default semantics alone.  I suggest you close this bug as
"wont fix", and add a new feature request.  After that, try
and get some support for your idea from someone willing or
able to submit a patch.

----------------------------------------------------------------------

Comment By: Per Cederqvist (ceder)
Date: 2004-01-06 05:44

Message:
Logged In: YES 
user_id=129207

You have convinced me that the ".cmd" file was a bad idea,
so let's forget I ever mentioned it.

I still think that the extension should be removed on POSIX
platforms, however.  However, if you have "foo.py" and
"foo.sh" they would both end up as "foo"; this should
produce a diagnostic.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-06 03:25

Message:
Logged In: YES 
user_id=113328

Having a ".cmd" file isn't a good idea. For a start, it isn't 
Windows 9x compatible (and %~dp0 isn't available in 
command.com). Also, you need to include a way of passing 
any command line arguments on to the script. And 
finally, "start" probably isn't right. This will run the command 
in a new console window, rather than in the existing console.

A XXX.cmd file which just does @%~dp0\XXX.py %* is 
better, but I still don't think it's needed. Just adding ".py" to 
PATHEXT (which is something the user can do if they want, 
at the same time they add the Python scripts directory to 
their PATH) is enough, at least on NT/2000/XP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 21:58:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 21:58:16 2004
Subject: [ python-Bugs-870479 ] Scripts need platform-dependent handling
Message-ID: <E1BgDJb-000860-00@sc8-sf-web1.sourceforge.net>

Bugs item #870479, was opened at 2004-01-04 14:00
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Cederqvist (ceder)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Scripts need platform-dependent handling

Initial Comment:
When a  script is installed on Unix, it should be named
something like "mailman-discard", with no extension.
When it is installed on Windows, it should be named
"mailman-discard.py", so that it is associated with
Python.  I think that "scripts" should be smart enough
to handle this.

My suggestion is that "scripts" should be set to a list
of the scripts, including the extension, and that
distutils will remove the extension when it installs
programs on platforms where this is true:

    os.name == 'posix'

It is possible to override the install_scripts class to
get this behaviour, but if you want to make a binary
distribution you also have to override bdist_wininst,
et c, since the install_scripts class is used on the
host system while building a directory tree that will
later be installed on the target system. See this
example script:

http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/mailman-discard/setup.py?rev=1.2&cvsroot=mailman-discard&content-type=text/vnd.viewcvs-markup
 
Peter ?strand also suggests that on Windows, you should
create a command file named "mailman-discard.cmd" and
put it in the same directory as the
"mailman-discard.py" file.  It should contain a single
line:

start %~dp0\mailman-discard.py

That way, you will be able to start the script from a
dos shell, and not just by double-clicking it in a file
browser.  It would be nice if Distutils created this
file automatically when installing on the win32 platform.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-01 21:58

Message:
Logged In: YES 
user_id=31435

Yup, I agree, Mark.  Fred too.  This has hit heated 
temperatures at times in the Zope world, where Windows 
users need .py extensions for sane script life under cmd.exe, 
but somewhat over half of Unixish geeks go on like they're 
being raped if an informative extension assults their prissy 
eyeballs <wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-01 21:52

Message:
Logged In: YES 
user_id=14198

Thanks Tim - I found the thread - interesting, and funnily
enough covers the same issues!  I also note
www.python.org/sf/976869 which is where Fred has made a patch.

My summary: nothing should be done implicitly.  Whatever is
done must be explicitly specified by the packager.  However,
no one is sure exactly how to spell it yet.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-01 21:02

Message:
Logged In: YES 
user_id=31435

Note this was an active topic on distutils-sig last week.  
Assigned to Fred in hopes that he can summarize current 
thinking as a comment here.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-01 20:41

Message:
Logged In: YES 
user_id=14198

The obvious issue is that we can't change the semantics for
packages already out there.  Existing package maintainers
will not want this change made for them automatically, and
it is not clear that this is the desirable default behaviour
anyway.  Therefore, this isn't going to be considered a 'bug'.

I think what you are asking for is a new feature - a way to
give distutils the behaviour you desire, but leaving the
default semantics alone.  I suggest you close this bug as
"wont fix", and add a new feature request.  After that, try
and get some support for your idea from someone willing or
able to submit a patch.

----------------------------------------------------------------------

Comment By: Per Cederqvist (ceder)
Date: 2004-01-05 13:44

Message:
Logged In: YES 
user_id=129207

You have convinced me that the ".cmd" file was a bad idea,
so let's forget I ever mentioned it.

I still think that the extension should be removed on POSIX
platforms, however.  However, if you have "foo.py" and
"foo.sh" they would both end up as "foo"; this should
produce a diagnostic.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-05 11:25

Message:
Logged In: YES 
user_id=113328

Having a ".cmd" file isn't a good idea. For a start, it isn't 
Windows 9x compatible (and %~dp0 isn't available in 
command.com). Also, you need to include a way of passing 
any command line arguments on to the script. And 
finally, "start" probably isn't right. This will run the command 
in a new console window, rather than in the existing console.

A XXX.cmd file which just does @%~dp0\XXX.py %* is 
better, but I still don't think it's needed. Just adding ".py" to 
PATHEXT (which is something the user can do if they want, 
at the same time they add the Python scripts directory to 
their PATH) is enough, at least on NT/2000/XP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

From noreply at sourceforge.net  Thu Jul  1 23:30:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  1 23:30:08 2004
Subject: [ python-Bugs-870479 ] Scripts need platform-dependent handling
Message-ID: <E1BgEkU-000264-00@sc8-sf-web2.sourceforge.net>

Bugs item #870479, was opened at 2004-01-04 14:00
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Cederqvist (ceder)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Scripts need platform-dependent handling

Initial Comment:
When a  script is installed on Unix, it should be named
something like "mailman-discard", with no extension.
When it is installed on Windows, it should be named
"mailman-discard.py", so that it is associated with
Python.  I think that "scripts" should be smart enough
to handle this.

My suggestion is that "scripts" should be set to a list
of the scripts, including the extension, and that
distutils will remove the extension when it installs
programs on platforms where this is true:

    os.name == 'posix'

It is possible to override the install_scripts class to
get this behaviour, but if you want to make a binary
distribution you also have to override bdist_wininst,
et c, since the install_scripts class is used on the
host system while building a directory tree that will
later be installed on the target system. See this
example script:

http://cvs.lysator.liu.se/viewcvs/viewcvs.cgi/mailman-discard/setup.py?rev=1.2&cvsroot=mailman-discard&content-type=text/vnd.viewcvs-markup
 
Peter ?strand also suggests that on Windows, you should
create a command file named "mailman-discard.cmd" and
put it in the same directory as the
"mailman-discard.py" file.  It should contain a single
line:

start %~dp0\mailman-discard.py

That way, you will be able to start the script from a
dos shell, and not just by double-clicking it in a file
browser.  It would be nice if Distutils created this
file automatically when installing on the win32 platform.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-01 23:30

Message:
Logged In: YES 
user_id=3066

Here's an idea about how to spell this:

http://mail.python.org/pipermail/distutils-sig/2004-July/004073.html

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-01 21:58

Message:
Logged In: YES 
user_id=31435

Yup, I agree, Mark.  Fred too.  This has hit heated 
temperatures at times in the Zope world, where Windows 
users need .py extensions for sane script life under cmd.exe, 
but somewhat over half of Unixish geeks go on like they're 
being raped if an informative extension assults their prissy 
eyeballs <wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-01 21:52

Message:
Logged In: YES 
user_id=14198

Thanks Tim - I found the thread - interesting, and funnily
enough covers the same issues!  I also note
www.python.org/sf/976869 which is where Fred has made a patch.

My summary: nothing should be done implicitly.  Whatever is
done must be explicitly specified by the packager.  However,
no one is sure exactly how to spell it yet.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-01 21:02

Message:
Logged In: YES 
user_id=31435

Note this was an active topic on distutils-sig last week.  
Assigned to Fred in hopes that he can summarize current 
thinking as a comment here.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-01 20:41

Message:
Logged In: YES 
user_id=14198

The obvious issue is that we can't change the semantics for
packages already out there.  Existing package maintainers
will not want this change made for them automatically, and
it is not clear that this is the desirable default behaviour
anyway.  Therefore, this isn't going to be considered a 'bug'.

I think what you are asking for is a new feature - a way to
give distutils the behaviour you desire, but leaving the
default semantics alone.  I suggest you close this bug as
"wont fix", and add a new feature request.  After that, try
and get some support for your idea from someone willing or
able to submit a patch.

----------------------------------------------------------------------

Comment By: Per Cederqvist (ceder)
Date: 2004-01-05 13:44

Message:
Logged In: YES 
user_id=129207

You have convinced me that the ".cmd" file was a bad idea,
so let's forget I ever mentioned it.

I still think that the extension should be removed on POSIX
platforms, however.  However, if you have "foo.py" and
"foo.sh" they would both end up as "foo"; this should
produce a diagnostic.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-05 11:25

Message:
Logged In: YES 
user_id=113328

Having a ".cmd" file isn't a good idea. For a start, it isn't 
Windows 9x compatible (and %~dp0 isn't available in 
command.com). Also, you need to include a way of passing 
any command line arguments on to the script. And 
finally, "start" probably isn't right. This will run the command 
in a new console window, rather than in the existing console.

A XXX.cmd file which just does @%~dp0\XXX.py %* is 
better, but I still don't think it's needed. Just adding ".py" to 
PATHEXT (which is something the user can do if they want, 
at the same time they add the Python scripts directory to 
their PATH) is enough, at least on NT/2000/XP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870479&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 02:41:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 02:41:23 2004
Subject: [ python-Bugs-215126 ] Over restricted type checking on eval()
	function
Message-ID: <E1BgHjW-0007Dd-00@sc8-sf-web1.sourceforge.net>

Bugs item #215126, was opened at 2000-09-22 14:36
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
>Status: Closed
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Armin Rigo (arigo)
Summary: Over restricted type checking on eval() function

Initial Comment:
The built-in function eval() takes a string argument and a dictionary.  The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries.

The following example creates a type error:
  eval, argument 2: expected dictionary,   instance found

class SpreadSheet:
    _cells = {}
    def __setitem__( self, key, formula ):
        self._cells[key] = formula
    def __getitem__( self, key ):
        return eval( self._cells[key], self )

ss = SpreadSheet()
ss['a1'] = '5'
ss['a2'] = 'a1*5'
ss['a2']


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-02 01:41

Message:
Logged In: YES 
user_id=80475

Made the requested changes, tested, and applied.
Will tackle exec and execfile on another day.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 10:06

Message:
Logged In: YES 
user_id=4771

Patch reviewed:

As eval(expr, mapping) is not accepted but eval(expr, {},
mapping) is, we could have a helpful error message along the
line of
  if (!PyDict_Check(globals)) {
      PyErr_SetString(PyExc_TypeError,
          PyMapping_Check(globals) ? 
              "globals must be a real dict; try eval(expr,
{}, mapping)"
            : "globals must be a dict");
  }

LOAD_NAME: you are doing a speed hack here we will bypass a
user-defined __getitem__ on a subclass of dict if the key
actually exists in the dictionary.  In other words your test
with the subclass of dict would fail if the dict aditionally
had another real value for the key 'a'.  Better use
PyDict_CheckExact() in all cases and only call
PyDict_GetItem() if it is true, as this is really cheap. 
Also, no PyErr_Clear() masking arbitrary exceptions please!


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-29 15:38

Message:
Logged In: YES 
user_id=80475

Are you comfortable doing this in two steps.  Commit the
patch as-is so that eval() works properly and then craft a
separate patch 
to thoroughly implement, test, and document the same thing
for exec and execfile()?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-29 05:36

Message:
Logged In: YES 
user_id=4771

Doing the type check in exec and execfile() but not in
eval() is not something that seems particularly useful to
me.  Any program can be written as an expression in Python
if you are crazy enough to do that...  So it doesn't offer
any extra security to be more strict in exec than in eval().
 People who really want to do it would have to go through
incredible pain just to work around the type check.

For the implications, I believe it is sufficient (and
necessary) to carefully review all usages of f_locals
throughout the code, and document f_locals as no longer
necessary a dictionary for those extension writers that
would have used this fact.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-29 03:51

Message:
Logged In: YES 
user_id=80475

Okay, a new patch is ready for second review.

It is essentially, Armin's patch with the following changes:

* leaves the syntax for eval() intact with no automatic
globals=locals trick

* has the faster approach for LOAD_NAME, incorporating your
suggestion for PyDict_CheckExact

* omits the code to enable the same liberties for '.exec'. 
That is beyond the OP's request and well beyond something
whose implications I've thought through.  Am not opposed to
it, but would like it to be left for a separate patch with
thorough unittests.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 13:08

Message:
Logged In: YES 
user_id=80475

Nix, that last comment.  Have examples that call setitem().

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 12:36

Message:
Logged In: YES 
user_id=80475

Changed to PyDict_CheckExact().

Are you sure about having to change the sets and dels.  I've
tried several things at the interactive prompt and can't get
it to fail:

  >>> [locals() for i in (2,3)]

Do you have any examples (in part, so I can use them as test
cases)?


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-27 06:33

Message:
Logged In: YES 
user_id=4771

eval() can set items in the locals, e.g. by using list comprehension.  Moreover the ability to exec in custom dicts would be extremely useful too, e.g. to catch definitions while they appear.

If you really want to avoid any performance impact, using PyDict_CheckExact() in all critical parts looks good (do not use PyDict_Check(), it's both slower and not what we want because it prevents subclasses of dicts to override __xxxitem__).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 03:37

Message:
Logged In: YES 
user_id=80475

Okay, the patch is ready for second review.
Attaching the revision with unittests.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-27 02:50

Message:
Logged In: YES 
user_id=80475

Attaching my minimal version of the patch.  It runs the
attached demo without exception and does not measurably show
on any of my timings.

The approach is to restrict the generalization to eval()
instead of exec().  Since eval() can't set values in the
locals dict, no changes  are needed to the setitem and
delitem calls.  Instead of using PyObject_GetItem()
directly, I do a regular lookup and fallback to the
generalizaiton if necessary -- this is why the normal case
doesn't get slowed down (the cost is a PyDict_Check which
uses values already in cache, and a branch predicatable
comparison)..

While the demo script runs, and the test_suite passes, it is
slightly too simple and doesn't yet handle eval('dir()',
globals(), M()) where M is a non-dict mapping.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-23 11:59

Message:
Logged In: YES 
user_id=80475

The quick patch works fine.

Do change the PyArg_ParseTuple() into the faster
PyArg_UnpackTuple().

Does this patch show any changes to pystone or other key
metrics?  Would the PyDict_GetItem trick have better
performance?  My guess is that it would.

+1 on using PyMapping_Check() for checking the locals
argument to eval().  That is as good as you can get without
actually running it.



----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-22 16:07

Message:
Logged In: YES 
user_id=4771

Quick patch attached.  I didn't try to use the PyDict_GetItem trick described, but just systematically use PyObject_GetItem/SetItem/DelItem when working with f_locals.

This might confuse some extension modules that expect PyEval_GetLocals() to return a dict object.

The eval trick is now: eval(code, nondict) --> eval(code, globals(), nondict).

Besides eval() I removed the relevant typecheck from execfile() and the exec statement.  Any other place I am missing?

We might want to still somehow check the type of the locals, to avoid strange errors caused by e.g. eval("a", "b").  PyMapping_Check() is the obvious candidate, but it looks like a hack.

More testing is needed.  test_descrtut.py line 84 now succeeds, unexpectedly, which is interpreted as a test failure.

Needs some docs, too.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-12 02:27

Message:
Logged In: YES 
user_id=80475

Armin, can you whip-up a quick patch so that we can explore
the implications of your suggestion.  Ideally, I would like
to see something like this go in for Py2.4.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-22 11:53

Message:
Logged In: YES 
user_id=80475

+1

Amrin's idea provides most of the needed functionality with
zero performance impact.  

Also, using a local dictionary for the application variables
is likely to be just exactly what a programmer would want to do.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-05-19 13:21

Message:
Logged In: YES 
user_id=4771

With minimal work and performance impact, we could allow
frame->f_locals to be something else than a real dictionary.
 It looks like it would be easily possible as long as we
don't touch the time-critical frame->f_globals.  Code
compiled by eval() always uses LOAD_NAME and STORE_NAME,
which is anyway allowed to be a bit slower than LOAD_FAST or
LOAD_GLOBAL.

Note that PyDict_GetItem() & co., as called by
LOAD/STORE_NAME, do a PyDict_Check() anyway.  We could just
replace it with PyDict_CheckExact() and if it fails fall
back to calling the appropriate ob_type->tp_as_mapping
method.  This would turn some of the PyDict_Xxx() API into a
general mapping API, half-way between its current dict-only
usage and the fully abstract PyObject_Xxx() API.

This is maybe a bit strange from the user's point of view,
because eval("expr", mydict) still wouldn't work: only
eval("expr", {}, mydict) would.
which does which does 
Now, there is no way I can think of that code compiled by
eval() could contain LOAD_GLOBAL or STORE_GLOBAL.  The only
way to tell the difference between eval("expr", mydict) and
eval("expr", {}, mydict) appears to be by calling globals()
or somehow inspecting the frame directly.  Therefore it
might be acceptable to redefine the two-argument eval(expr,
dict) to be equivalent not to eval(expr, dict, dict) but
eval(expr, {}, dict).  This hack might be useful enough even
if it won't work with the exec statement.

----------------------------------------------------------------------

Comment By: Philippe Fremy (pfremy)
Date: 2004-03-03 04:40

Message:
Logged In: YES 
user_id=233844

I have exactly the same need as the original poster. The
only difference in my case is that I inhreted a dictionnary.

I want to use the eval() function as a simple expression
evaluator. I have the
follwing dictionnary:
d['a']='1'
d['b']='2'
d['c']='a+b'

I want the following results:
d[a] -> 1 
d[b] -> 2 
d[c] -> 3

To do that, I was planning to use the eval() function and
overloading the __getitem__ of the global or local dictionnary:

class MyDict( dict ) : 
	def __getitem__( self, key ):
		print "__getitem__", key
		val = dict.__getitem__( self, key )
		print "val = '%s'" % val
		return eval( val , self )

But it does not work:
d[a]:
__getitem__ a
val = '1'
-> 1

d[b]:
__getitem__ b
val = '2'
-> 2

d[c]:
__getitem__ c
val = 'e+1'
ERROR
Traceback (most recent call last):
  File "test_parse_jaycos_config.py", line 83, in testMyDict
    self.assertEquals( d['c'], 2 )
  File "parse_config_file.py", line 10, in __getitem__
    return eval( val , self )
  File "<string>", line 0, in ?
TypeError: cannot concatenate 'str' and 'int' objects

d['c'] did fetch the 'a+1' value, which was passed to eval.
However, eval()
tried to evaluate the expression using the content of the
dictionnary instead
of using __getitem__. So it fetched the string '1' for 'a'
instead of the value 1, so the result is not suitable for
the addition.



----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-01-12 17:01

Message:
Logged In: YES 
user_id=99874

Hmm... I like this!

Of course, I am wary of adding *yet another* special double-
underscore function to satisfy a single special purpose, but 
this would satisfy all of *my* needs, and without any 
performance impact for lookups that are FOUND. Lookups that 
are NOT found would have a slight performance degrade (I 
know better than to speculate about the size of the effect 
without measuring it). I'm not really sure what percentage of 
dict lookups succeed.

At any rate, what are these "other contexts" you mention in 
which a __keyerror__ would "also be useful"? Because if we 
can find other places where it is useful, that significantly 
improves the usefulness.

OTOH, if the tests can be done ONLY for eval (I don't really 
think that's possible), then I'm certain no one cares about the 
performance of eval.

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2004-01-12 14:38

Message:
Logged In: YES 
user_id=292741

This may be  a compromise solution, which could also be
useful in other contexts: What if the object passed
is derived from dict - presumably that doesn't help
because the point is to do low-level calls to the
actual dict's lookup functions.
 Now, suppose we modify the basic dict type, so
that before throwing
a KeyError, it checks to see if it is really a derived
object with a method __keyerror__, and if so, calls
that and returns its result (or lets it throw)?
Now you can make objects that look like dicts, and
act like them at the low level, but can automatically
populate themselves when non-existent keys are requested.
Of course, __keyerror__('x') does not have to make
an 'x' entry in the dict; it could make no change, or
add several entries, depending on the desired semantics
regarding future lookups. It could be set up so that
every lookup fails and is forwarded by __keyerror__ to
the __getitem__ of another object, for instance.

The cost of this to the 'normal' dict lookup is that
the need to do PyDict_CheckExact() each time
a lookup fails.


----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2003-12-16 10:37

Message:
Logged In: YES 
user_id=99874

I'll just add my voice as somebody who would find this to 
be &quot;darn handy&quot; if it could ever done without noticably 
impacting the speed of python code that DOESN'T use eval().

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-22 23:18

Message:
Added to PEP 42.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-22 14:42

Message:
Changed Group to Feature Request.  Should be added to PEP 42 (I'll do that if nobody beats me to it).

CPython requires a genuine dict now for speed.  I believe JPython allows any mapping object.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 03:03:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 03:03:43 2004
Subject: [ python-Bugs-658254 ] Accept None for time.ctime() and friends
Message-ID: <E1BgI5C-0004hk-00@sc8-sf-web4.sourceforge.net>

Bugs item #658254, was opened at 2002-12-24 11:58
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658254&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Accept None for time.ctime() and friends

Initial Comment:
Several functions in the time module can have the time
value they operate on omitted to indicate the current
time, but they do not accept None as equivalent to
omitting the value.  It should be equivalent.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-02 02:03

Message:
Logged In: YES 
user_id=80475

Assigning back to Fred.  I fully support the ipath on the
basis that it will make user code less complicated.  

Blunk's patch had some minor review comments, but is
basically ready to go.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-09-10 10:45

Message:
Logged In: YES 
user_id=3066

I generally expect that None should be accepted for an
omitted arg, but Guido has certainly never cared about that.
 Given that no existing code passes None, it's ok to reject.
 If the truth be told, though, the current situation
certainly complicates some existing code!

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-01-06 22:43

Message:
Logged In: YES 
user_id=531881

see patch 663482

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658254&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 04:04:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 04:05:12 2004
Subject: [ python-Bugs-982215 ] Next button not greyed out during file copy.
Message-ID: <E1BgJ2H-0001Yk-00@sc8-sf-web1.sourceforge.net>

Bugs item #982215, was opened at 2004-06-29 21:54
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982215&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Phil Rittenhouse (prittenh)
Assigned to: Thomas Heller (theller)
Summary:  Next button not greyed out during file copy.

Initial Comment:
I've noticed a problem with a couple of distutils based
installers (py2exe and pywin32) that I think may be a
problem in all distutils based windows installers.

When you click Next to start the file copy, the Next 
button is not greyed out or disabled.  If you click it 
again, it seems to start another file copy process 
running, because you then get an "Overwrite Existing 
Files?" dialog.  If you click Yes, the install may throw a 
Runtime Error with the message "The process cannot 
access the file because it is being used by another 
process..." and it may lock up.

I'm running Python 2.3.3 and have seen this in py2exe 
0.5.0 and pywin32 build 201.  I have tried a number of 
Windows OSs including 2000 and ME.


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-02 10:04

Message:
Logged In: YES 
user_id=11105

Committed as install.c rev 1.1.14.2 and rev 1.5.
Thanks for the patch.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-02 02:34

Message:
Logged In: YES 
user_id=14198

I see this too!  Attached is a patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982215&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 04:54:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 04:54:43 2004
Subject: [ python-Bugs-951851 ] Crash when reading "import table" of certain
	windows DLLs
Message-ID: <E1BgJoZ-00009M-00@sc8-sf-web4.sourceforge.net>

Bugs item #951851, was opened at 2004-05-11 13:02
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=951851&group_id=5470

Category: Windows
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Mark Hammond (mhammond)
>Assigned to: Thomas Heller (theller)
Summary: Crash when reading "import table" of certain windows DLLs

Initial Comment:
As diagnosed by Thomas Heller, via the python-win32 list.

On Windows 2000, if your sys.path includes the Windows
system32 directory, 'import wmi' will crash Python.  To
reproduce, change to the system32 directory, start
Python, and execute 'import wmi'.  Note that Windows XP
does not crash.

The problem is in GetPythonImport(), in code that tries
to walk the PE 'import table'.  AFAIK, this is code
that checks the correct Python version is used, but
I've never seen this code before.

I'm not sure why the code is actually crashing (ie,
what assumptions made about the import table are
wrong), but I have a patch that checks a the pointers
are valid before they are de-referenced.  After the
patch is applied, the result is the correct:
"ImportError: dynamic module does not define init
function (initwmi)"
exception.

Assigning to thomas for his review, then I'm happy to
check in.  I propose this as a 2.3 bugfix.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-02 10:54

Message:
Logged In: YES 
user_id=11105

Commited as dynload_win.c rev 2.12.14.1 and rev 2.13.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-01 02:07

Message:
Logged In: YES 
user_id=14198

Sorry about that - I thought my "IsBadReadPtr()" patch did
end up getting checked in :(  It is still sitting as a diff
in my 2.3 tree, which is a shame.  Sorry about that.

You patch works fine with the 2.4 branch, and does also stop
the crash, so please check it in.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-06-29 21:46

Message:
Logged In: YES 
user_id=11105

Sorry if I was confusing.
I simply want to know if this should be checked in or not. 
Maybe you can review the code, and/or try it out.  Thanks.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-06-29 01:20

Message:
Logged In: YES 
user_id=14198

I'm sorry, but I'm not sure what I don't listen to :)  You
are correct about being short of time though.  What would
you like me to do?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-06-28 23:28

Message:
Logged In: YES 
user_id=11105

It seems Mark doesn't listen (or don't have time).
I'd like to check this in for 2.4.  Any objections?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-06-01 20:35

Message:
Logged In: YES 
user_id=11105

This is not yet accepted.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-06-01 19:45

Message:
Logged In: YES 
user_id=11105

The reason the current code crashed when Python tries to
import Win2k's or XP's wmi.dll as extension is that the size
of the import table in this dll is zero.  The first patch
'dynload_win.c-1.patch' fixes this by returning NULL in that
case.

The code, however, doesn't do what is intended in a debug
build of Python.  It looks for imports of 'python23.dll',
when it should look for 'python23_d.dll' instead.  The
second patch 'dynload_win.c-2.patch' fixes this also (and
includes the first patch as well).

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-05-12 03:56

Message:
Logged In: YES 
user_id=14198

Seeing as it was the de-referencing of 'import_name' that
crashed, I think a better patch is to terminate the outer
while look as soon as we hit a bad string.  Otherwise, this
outer loop continues, 20 bytes at a time, until the outer
pointer ('import_data') also goes bad or happens to
reference \0.

Attaching a slightly different patch, with comments and
sizeof() change.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-05-12 01:00

Message:
Logged In: YES 
user_id=14198

OK - will change to 12+so(WORD)

And yes, I had seen this code - I meant "familiar with" :)

Tim: Note that the import failure is not due to a bad import
table (but the crash was).  This code is trying to determine
if a different version of Python is used.  We are
effectively skipping that check, and landing directly in the
"does it have an init function?", then faling normally - ie,
the code is now correctly *not* finding other Python
versions linked against it.  Thus, a different error message
doesn't make much sense to me.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-05-11 17:45

Message:
Logged In: YES 
user_id=11105

Oh, we have to give the /all option to dumpbin ;-)

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-05-11 17:42

Message:
Logged In: YES 
user_id=11105

Tim, I don't think the import table format has changed,
instead wmi.dll doesn't have an import table (for whatever
reason).  Maybe the  code isn't able to handle that correctly.

Since Python 2.3 as well at it's extensions are still built
with MSVC 6, I *think* we should be safe with this code.

I'll attach the output of running MSVC.NET 2003's
'dumpbin.exe \windows\system32\wmi.dll' on my WinXP Pro SP1
for the curious.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-05-11 17:20

Message:
Logged In: YES 
user_id=31435

Mark, while you may not have seen this code before, you 
checked it in <wink -- rev 2.7>.  IIRC, though, the person 
who *created* the patch was never heard from again.

I don't understand what the code thinks it's doing either, 
exactly.  The obvious concern:  if the import table format has 
changed, won't we also fail to import legit C extensions?  I 
haven't seen that happen yet, but I haven't yet built any 
extensions using VC 7.1 either.

In any case, I'd agree it's better to get a mysterious import 
failure than a crash.  Maybe the detail in the ImportError 
could be changed to indicate whan an import failure is due to 
a bad pointer.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-05-11 16:49

Message:
Logged In: YES 
user_id=11105

IMO, IsBadReadPointer(import_data, 12 + sizeof(DWORD))
should be enough.

Yes, please add a comment in the code.

This is a little bit hackish, but it fixes the problem.  And
the real problem can always be fixed later, if needed.

And, BTW, python 2.3.3 crashes on Windows XP as well.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-05-11 13:05

Message:
Logged In: YES 
user_id=14198

Actually, I guess a comment regarding the pointer checks and
referencing this bug would be nice :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=951851&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 08:13:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 08:13:25 2004
Subject: [ python-Bugs-984017 ] Buffer Protocol Prototypes Incorrect
Message-ID: <E1BgMuu-0002nH-00@sc8-sf-web2.sourceforge.net>

Bugs item #984017, was opened at 2004-07-02 14:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984017&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Timothy Stranex (perspex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Buffer Protocol Prototypes Incorrect

Initial Comment:
The PyObject_AsReadBuffer and PyObject_AsWriteBuffer
functions are documented incorrectly in the Python/C
API Reference Manual for both Python 2.3 and the
current development documentation.

Section 6.6 ("Buffer Protocol") state the following
prototypes:

    - int PyObject_AsReadBuffer(PyObject *obj, const
char **buffer, int *buffer_len)
    - int PyObject_AsWriteBuffer(PyObject *obj, char
**buffer, int *buffer_len)

while Include/abstract.h define them as follows:

    - int PyObject_AsReadBuffer(PyObject *obj, const
void **buffer, int *buffer_len)
    - int PyObject_AsWriteBuffer(PyObject *obj, void
**buffer, int *buffer_len);

In each case, "char **buffer" should be changed to
"void **buffer". I've included a patch against Python
2.3.3 in diff -u format that fixes this. It modifies
Doc/api/abstract.tex.

Thanks,
Timothy Stranex

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984017&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 09:56:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 09:56:23 2004
Subject: [ python-Bugs-953599 ] asyncore misses socket closes when poll is
	used
Message-ID: <E1BgOWT-0007ng-00@sc8-sf-web1.sourceforge.net>

Bugs item #953599, was opened at 2004-05-14 01:47
Message generated for change (Comment added) made by klimkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=953599&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Kerr (shane_kerr)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore misses socket closes when poll is used

Initial Comment:
Problem:

If the loop() function of asyncore is invoked with poll
rather than select, the function readwrite() is used
when I/O is available on a socket.  However, this
function does not check for hangup - provided by POLLHUP.

If a socket is attempting to write, then POLLOUT never
gets set, so the socket hangs.  

Because poll() is returning immediately, but the return
value is never used, asyncore busy-loops, consuming all
available CPU.


Possible solutions:

The easy solution is to check for POLLHUP in the
readwrite() function:

        if flags & (select.POLLOUT | select.POLLHUP):
            obj.handle_write_event()

This makes the poll work exactly like the select - the
application raises a socket.error set to EPIPE.

An alternate solution - possibly more graceful - is to
invoke the handle_close() method of the object:

        if flags & select.POLLHUP:
            obj.handle_close()
        else:
            if flags & select.POLLIN:
                obj.handle_read_event()
            if flags & select.pollout:
                obj.handle_write_event()

This is incompatible with the select model, but it
means that the read and write logic is now the same for
socket hangups - handle_close() is invoked.


----------------------------------------------------------------------

Comment By: Alexey Klimkin (klimkin)
Date: 2004-07-02 17:56

Message:
Logged In: YES 
user_id=410460

Perhaps, it would be better to raise exception:

def readwrite(obj, flags):
    try:
        if flags & (select.POLLIN | select.POLLPRI):
            obj.handle_read_event()
        if flags & select.POLLOUT:
            obj.handle_write_event()
        if flags & (select.POLLERR | select.POLLHUP |
select.POLLNVAL):
            obj.handle_expt_event()
    except ExitNow:
        raise
    except:
        obj.handle_error()

...

    def handle_expt_event(self):
        err = self.socket.getsockopt(socket.SOL_SOCKET,
socket.SO_ERROR)
        assert(err != 0)
        raise socket.error, (err, errorcode[err])

Since asyncore closes socket in handle_error, this solves
the problem too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=953599&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 12:25:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 12:25:23 2004
Subject: [ python-Bugs-935117 ] pkgutil doesn't understand case-senseless
	filesystems
Message-ID: <E1BgQqa-0006l6-00@sc8-sf-web3.sourceforge.net>

Bugs item #935117, was opened at 2004-04-14 14:35
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=935117&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pkgutil doesn't understand case-senseless filesystems

Initial Comment:
The pkgutil.extend_path() function doesn't understand
case-senseless filesystems the way Python's import
does, but it should.  On a case-insensitive filesystem,
a directory that matches the package name in spelling
but not case can be mistakenly added to a package by
extend_path(); this can cause differently-named
packages to be mistakenly merged and allow unrelated
code to shadow code in a secondary component of a
package (where secondary means something other than the
first directory found that matches the package).

Consider this tree in a filesystem:

d1/
    foo/
        __init__.py     # this calls pkgutil.extend_path()
        module.py      # imports module "foo.something"
d2/
    Foo/
        __init__.py     # an unrelated package
        something.py
d3/
    foo/
        __init__.py
        something.py

sys.path contains d1/, d2/, d3/, in that order.

After the call to extend_path() in d1/foo/__init__.py,
foo.__path__ will contain d1/foo/, d2/Foo/, d3/foo/ (in
that order), and foo/module.py will get
d2/Foo/something.py when it imports foo.something. 
What's intended is that it get d3/foo/something.py; on
a case-sensitive filesystem, that's what would have
happened.

pkgutil.extend_path() should exercise the same care and
check the same constraints as Python's import.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-02 12:25

Message:
Logged In: YES 
user_id=3066

Assigned to me since I intend to make this work in the end.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-19 17:26

Message:
Logged In: YES 
user_id=31435

Attaching a pure-Python case_ok() "building block" that 
should be adequate for doing the hard part of this.  It's 
trickier than first appears because Python's case-sensitive 
imports are not sensitive to the case of extensions 
(.py, .pyo, ...) on case-insensitive filesystems.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-04-14 14:38

Message:
Logged In: YES 
user_id=3066

Argh!  Here's the tree again, since comments don't get
screwed up the same way initial reports are:

d1/
    foo/
        __init__.py   # this calls pkgutil.extend_path()
        module.py     # imports module "foo.something"
d2/
    Foo/
        __init__.py   # an unrelated package
        something.py
d3/
    foo/
        __init__.py
        something.py


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=935117&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 13:53:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 13:53:56 2004
Subject: [ python-Bugs-984219 ] hotspot.stats.load is very slow
Message-ID: <E1BgSET-0000ya-00@sc8-sf-web2.sourceforge.net>

Bugs item #984219, was opened at 2004-07-02 19:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotspot.stats.load is very slow

Initial Comment:
hotspot.Profile generates a very large (10-70Mbytes) file for complex applications. hotspot.stats.load loads the profile file very slow.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 14:09:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 14:09:07 2004
Subject: [ python-Bugs-984219 ] hotspot.stats.load is very slow
Message-ID: <E1BgSTA-0001YE-00@sc8-sf-web2.sourceforge.net>

Bugs item #984219, was opened at 2004-07-02 19:53
Message generated for change (Comment added) made by complex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotspot.stats.load is very slow

Initial Comment:
hotspot.Profile generates a very large (10-70Mbytes) file for complex applications. hotspot.stats.load loads the profile file very slow.

----------------------------------------------------------------------

>Comment By: Viktor Ferenczi (complex)
Date: 2004-07-02 20:09

Message:
Logged In: YES 
user_id=142612

Python version: 2.3.4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 14:10:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 14:10:16 2004
Subject: [ python-Bugs-984219 ] hotspot.stats.load is very slow
Message-ID: <E1BgSUF-0005MO-00@sc8-sf-web4.sourceforge.net>

Bugs item #984219, was opened at 2004-07-02 19:53
Message generated for change (Comment added) made by complex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotspot.stats.load is very slow

Initial Comment:
hotspot.Profile generates a very large (10-70Mbytes) file for complex applications. hotspot.stats.load loads the profile file very slow.

----------------------------------------------------------------------

>Comment By: Viktor Ferenczi (complex)
Date: 2004-07-02 20:10

Message:
Logged In: YES 
user_id=142612

OS: WinXP Prof ENG SP1
CPU: Intel P4 Northwood 1.6G
MEM: 512Mbyte, 800MHz RDRAM

----------------------------------------------------------------------

Comment By: Viktor Ferenczi (complex)
Date: 2004-07-02 20:09

Message:
Logged In: YES 
user_id=142612

Python version: 2.3.4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984219&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 14:24:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 14:24:52 2004
Subject: [ python-Feature Requests-984242 ] Support "hybrid" framework/unix
	style
Message-ID: <E1BgSiP-0002Fj-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #984242, was opened at 2004-07-02 14:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=984242&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support "hybrid" framework/unix style

Initial Comment:
In the Darwin 8 prerelease sources, Apple decided to actually 
build Python to /usr/lib and have /System/Library/Frameworks/
Python.framework/Versions/2.3/Python be a symlink to that.  /usr/
include/python2.3/ is a symlink to inside the framework.

We should probably support this build style.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=984242&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 15:28:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 15:28:26 2004
Subject: [ python-Bugs-809846 ] distutils/bdistwin32 doesn't clean up RO
	files properly
Message-ID: <E1BgTht-0008KP-00@sc8-sf-web4.sourceforge.net>

Bugs item #809846, was opened at 2003-09-20 19:49
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809846&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils/bdistwin32 doesn't clean up RO files properly

Initial Comment:
Using Windows XP SP1, Python 2.3, Win32Extensions 
build 159:

I recently added some data_files to my setup script as 
so:

setup( ..., data_files = [ ( 'files', ['file.txt'] ) ] )

and when I ran my setup script with the build 
option 'bdist_wininst', I get the following error at the 
cleanup stage of the build:

removing 'build\bdist.win32\wininst' (and everything 
under it)
error removing build\bdist.win32\wininst: 
build\bdist.win32\wininst\DATA\file.txt: Permission denied

The error is followed by more errors attempting to 
remove the parent directories because they're not 
empty.

The reason permission is denied is because the file is 
marked as read-only (via file attributes, not file 
permissions).  The source file is marked as read-only in 
this case because it is being taken from a Visual 
SourceSafe project which uses the RO attribute to 
indicate check-out status.  If I check out the file or 
remove the RO flag, the script runs without errors.

Regardless of the reason for a file being marked RO, the 
temporary files in wininst\DATA should not be copied 
with their RO attribute or when cleaning up, the routine 
should delete the files regardless of RO status.

I'm not sure what is the best way to approach this 
problem, but I will be willing to provide input or even 
code patches.  I need input from the community, 
however, on how to best fix this issue.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-02 21:28

Message:
Logged In: YES 
user_id=11105

The sdist command, for example, has the same problem - so
it's not bdist_wininst specific.
py2exe's build_exe.py module has a force_remove_tree()
variant of distutils' dir_util.remove_tree() function which
could serve as a possible example how to force removal. 
(This function was contributed by a py2exe-user, but I don't
remember who it was.)

For distutils, the remove_tree() function could grow a
'force' parameter, and that could be used in the cleanup
phase - it should be safe to remove the temporary build tree
we have created, and that wouldn't change the read-only bit
in the installed file(s).

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-02 02:46

Message:
Logged In: YES 
user_id=14198

Do other distutils commands suffer the same problem cleaning
their temp files?  If so, the problem is a little more
delicate (special-casing these attributes on Linux, for
example, would be non-trivial), but if only bdist_win32 has
the problem we could be more brutal (there are very few
attributes we need to worry about!).

The other potential problem is that people may actually want
this r/o attribute to end up on the installed file - which
means the installer and uninstaller need to deal with it too.

So I too am unsure what the "correct" thing to do is.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809846&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 15:42:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 15:42:10 2004
Subject: [ python-Bugs-984290 ] Useless question in bdist_winst installers
Message-ID: <E1BgTvD-0005Ud-00@sc8-sf-web1.sourceforge.net>

Bugs item #984290, was opened at 2004-07-02 21:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984290&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Useless question in bdist_winst installers

Initial Comment:
Before a bdist_wininst created installer overwrites
files it asks the user whether files should be
overwritten or not.  This question is annoying and
doesn't seem very useful - it is too late to cancel the
installation (because some files might already have
been installed).

I suggest to remove this question (MessageBox), and
always overwrite files during the installation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984290&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 19:55:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 19:55:31 2004
Subject: [ python-Bugs-555810 ] removing extensions without admin rights
Message-ID: <E1BgXsL-0000GW-00@sc8-sf-web4.sourceforge.net>

Bugs item #555810, was opened at 2002-05-14 18:53
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555810&group_id=5470

Category: Windows
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: removing extensions without admin rights

Initial Comment:
It is possible for ordinary users to remove python
extensions installed from bdist_wininst by an admin.
bdist_wininst should check permissions before allowing
this.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-03 09:55

Message:
Logged In: YES 
user_id=14198

Fixed via http://www.python.org/sf/983775

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555810&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 19:55:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 19:55:46 2004
Subject: [ python-Bugs-555812 ] installing extension w/o admin rights
Message-ID: <E1BgXsc-0006NY-00@sc8-sf-web3.sourceforge.net>

Bugs item #555812, was opened at 2002-05-14 18:56
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555812&group_id=5470

Category: Windows
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: installing extension w/o admin rights

Initial Comment:
Users without admin rights can run bdist_wininst
installers, but they cannot set the registry entries
for uninstallation.
bdist_wininst should in this case write into the
HKEY_CURRENT_USER branch instead of HKEY_LOCAL_MACHINE.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-03 09:55

Message:
Logged In: YES 
user_id=14198

Fixed via http://www.python.org/sf/983775

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555812&group_id=5470

From noreply at sourceforge.net  Fri Jul  2 23:57:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  2 23:57:56 2004
Subject: [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E1Bgbeq-0002qN-00@sc8-sf-web1.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Brett Cannon (bcannon)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 426, in
__bootstrap
    self.__stop()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 435, in
__stop
    self.__block.notifyAll()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by &lt;bound method
ExitNotifyThread.__bootstrap of &lt;ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)&gt;&gt;
Traceback (most recent call last):
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 426, in
__bootstrap
    self.__stop()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 435, in
__stop
    self.__block.notifyAll()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by &lt;bound method
ExitNotifyThread.__bootstrap of &lt;ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)&gt;&gt;
Traceback (most recent call last):
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 426, in
__bootstrap
    self.__stop()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 435, in
__stop
    self.__block.notifyAll()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-02 20:57

Message:
Logged In: YES 
user_id=357491

Fixed in 2.4 thanks to rev. 1.42 to Lib/threading.  Don't know if this will 
be backported to 2.3 .  Possible, but need someone else to agree first.

----------------------------------------------------------------------

Comment By: k (carlosayam)
Date: 2004-06-02 23:05

Message:
Logged In: YES 
user_id=990060

I don't understand one thing: how can python shut down
itself and, at the same time, keep a python code running in
a daemonised thread? or is that thread running in a
different "threaded" python byte-code interpreter?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-02 22:25

Message:
Logged In: YES 
user_id=31435

Brett, FYI, a daemon thread differs from a non-daemon 
thread in only one respect:  Python shuts down when only 
daemon threads remain.  It waits for non-daemon threads to 
finish.  So a daemon thread can keep running after the 
interpreter has torn itself down completely.  For that reason, 
problems in daemon threads doing non-trivial things are 
almost guaranteed.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-02 22:08

Message:
Logged In: YES 
user_id=357491

Yep, that is how Python cleans up a module; sets everything in the 
module to None and then removes it from sys.modules .

As for your case, I don't know enough about daemonized threads.  My 
patch for this only tries to let the exception make it to the top without 
'threading' hiding the exception by causing its own exception from 
interpreter shutdown.  In other words I don't know if this is a related 
issue or not.

----------------------------------------------------------------------

Comment By: k (carlosayam)
Date: 2004-06-02 20:01

Message:
Logged In: YES 
user_id=990060

bcannon said on 2004-02-17
>> Does anyone know how to cause this error in isolation?

I'm getting the same error when I start a new thread,
daemonise it and the thread goes into a very slow database
operation (loading a large object); meanwhile the main
thread starts a GUI; then I close the window, exiting the
main loop and the python interpreter ends (or tries to end.)

In relation to bcannon comment on how to reproduce the error
(setting all variables to None in the module), my guess is
that while exiting, the python interpreter is somehow
freeing all variables in the module (cleaning the module or
something), but the module is still running and that raises
the error... is this possible?

Note: if the thread is not daemonised, the problem desapears
but the script (the python interpreter) takes a while to finish.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-05-16 21:36

Message:
Logged In: YES 
user_id=357491

How to reproduce the bug:

* Follow the instructions at http://mnetproject.org/repos/ on how to get a 
copy of the in-dev version of mnet (I used the instructions for using wget 
and it worked fine).

* Run ``python setup.py``.  Do realize that this app will download other 
Python code (crypto stuff mostly) to finish its install.  Takes up about 54 
MB on my machine after it is compiled.

* Run ``python setup.py test -a``.  This executes the testing suite.  The 
bug manifests itself after the testing suite finishes execution.

This will consistently cause the bug every time.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-05-16 11:45

Message:
Logged In: YES 
user_id=357491

Discovered this is not fixed after all (previous fix didn't go far enough; 
still needed, though).  Patch 954922 is the second attempt to fix this.  
This time, though, I had code that could trigger the problem reliably and 
thus this should be the proper, and final, fix.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-08 14:36

Message:
Logged In: YES 
user_id=357491

OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just 
removed the two calls to currentThread in the _Condition class that were 
commented to be for their side-effect).

Just because I don't feel rock-solid on my fix to the point of it not 
changing some obscure semantics that I would be willing to put a gun to 
my head over it I am not going to backport this until I hear from 
someone who had this bug and reports that they have not had any issues 
for a long time.  Otherwise I will just leave the fix in 2.4 only.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-08 14:32

Message:
Logged In: YES 
user_id=357491

OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just 
removed the two calls to currentThread in the _Condition class that were 
commented to be for their side-effect).

Just because I don't feel rock-solid on my fix to the point of it not 
changing some obscure semantics that I would be willing to put a gun to 
my head over it I am not going to backport this until I hear from 
someone who had this bug and reports that they have not had any issues 
for a long time.  Otherwise I will just leave the fix in 2.4 only.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-02 20:29

Message:
Logged In: YES 
user_id=357491

To force this error I inserted code to set all attributes of the threading 
module to None and then throw and exception.  After commenting out 
the two calls to currentThread in _Condition the thrown exception to 
trigger the problem propogated to the top correctly.

I did have the clean-up function give out since I set *everything* to 
None, but it doesn't look like a normal issue as shown in the exception 
traceback in the OP.  I don't think it is an issue.

So it seems commenting the two calls to currentThread in _Condition 
solves the problem.  But since this is threading code and the comment 
explicitly states it is for the side-effect I am going to try to get a second 
opinion.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-02-16 20:59

Message:
Logged In: YES 
user_id=357491

Does anyone know how to cause this error in isolation?  I have tried a 
bunch of different ways but cannot cause an exception to be raised at the 
correct point in Threading.__bootstrap() to lead to self.__stop() to be 
called while the interpreter is tearing itself down.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-02-09 17:18

Message:
Logged In: YES 
user_id=357491

After staring at the code, I am not even sure if the calls for its side-
effect are needed.  If you call currentThread(), it either returns a value 
from _active which is a dict of running Thread instances indexed by 
thread idents, or a new _DummyThread instance that inserts itself into 
_active.  Now the two calls in the _Condition class are purely for this 
possible side-effect.

And yet at no point is anything from _active, through currentThread or 
direct access, even touched by a _Condition method.  The only chance 
this might be an issue is if a _Condition instance uses an RLock instance 
for its locking, which is the default behavior.

But this still makes the side-effect need useless.  RLocks will call 
currentThread on their own and since this is all in the same thread the 
result won't change.  And in this specific case of this bug, the _Condition 
instance is created with a Lock instance since that is what the Thread 
instance uses for constructing the _Condition instance it use, which is just 
thread.allocate_lock() which is obviously not an RLock.

In other words I can't find the point to the side-effect in _Condition.  I 
will try to come up with some testing code that reproduces the error and 
then see if just removing the calls in _Condition remove the error and 
still pass the regression tests.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-06-16 06:26

Message:
Logged In: YES 
user_id=491567

I can confirm that this behavior is not present in Python 2.2 in 
the same version that I am using to test against Python 2.3. 
 
I will be on vacation for most of this and next week.  I'll try to 
get to the logging script before I leave, but I might not get to it 
until I return. 
 
FYI, you can also obtain OfflineIMAP at 
http://quux.org/devel/offlineimap. 
 
 

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said &quot;when my application exits&quot;.  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

From noreply at sourceforge.net  Sat Jul  3 14:32:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul  3 14:32:20 2004
Subject: [ python-Bugs-984691 ] Tiny suggestion to improve optparse doc
Message-ID: <E1BgpJA-0000oo-00@sc8-sf-web3.sourceforge.net>

Bugs item #984691, was opened at 2004-07-03 20:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984691&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tiny suggestion to improve optparse doc

Initial Comment:
In section 6.20.2.7 Putting it all together
 the usage string is given as 
usage = "usage: \%prog [-f] [-v] [-q] firstarg secondarg"

but then later you get to
if len(args) != 1:
        parser.error("incorrect number of arguments")

... should be 2, no, to correspond to the usage ....

Laura


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984691&group_id=5470

From noreply at sourceforge.net  Sat Jul  3 15:39:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul  3 15:39:25 2004
Subject: [ python-Bugs-984714 ] unknown parsing error
Message-ID: <E1BgqM6-00023x-00@sc8-sf-web2.sourceforge.net>

Bugs item #984714, was opened at 2004-07-03 19:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984714&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Igor Sidorenkov (gazum)
Assigned to: Nobody/Anonymous (nobody)
Summary: unknown parsing error

Initial Comment:
I am getting "unknown parsing error" when trying to run 
a script with a following first line: 
#@+leo-encoding=cp1251.

If I add a couple of empty lines or 
# -*- coding: cp1251 -*-
then everything is ok.

I am using ActiveState python 2.3.3 on
Win2K server.

---------- Python ----------
error=22
  File "test.py", line 1
SyntaxError: unknown parsing error

Output completed (0 sec consumed) - Normal 
Termination
------------------------------
#@+leo-encoding=cp1251.
#@+node:0::@file test.py
#@+body
for i in range(5):
	print i
#@-body
#@-node:0::@file test.py
#@-leo


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984714&group_id=5470

From noreply at sourceforge.net  Sat Jul  3 16:01:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul  3 16:01:57 2004
Subject: [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E1Bgqhq-0003TR-00@sc8-sf-web1.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Brett Cannon (bcannon)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 426, in
__bootstrap
    self.__stop()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 435, in
__stop
    self.__block.notifyAll()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by &lt;bound method
ExitNotifyThread.__bootstrap of &lt;ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)&gt;&gt;
Traceback (most recent call last):
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 426, in
__bootstrap
    self.__stop()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 435, in
__stop
    self.__block.notifyAll()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by &lt;bound method
ExitNotifyThread.__bootstrap of &lt;ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)&gt;&gt;
Traceback (most recent call last):
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 426, in
__bootstrap
    self.__stop()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 435, in
__stop
    self.__block.notifyAll()
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File &quot;/usr/lib/python2.3/threading.py&quot;, line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-03 13:01

Message:
Logged In: YES 
user_id=357491

For 2.3, rev.1.38.6.1 has the required fixes (required also backporting 
rev. 1.41 from HEAD).

Thanks to everyone who tried to help with this nasty thing.  And a special 
thanks to the Mnet guys for giving me a way to reproduce this bug 
consistently.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-02 20:57

Message:
Logged In: YES 
user_id=357491

Fixed in 2.4 thanks to rev. 1.42 to Lib/threading.  Don't know if this will 
be backported to 2.3 .  Possible, but need someone else to agree first.

----------------------------------------------------------------------

Comment By: k (carlosayam)
Date: 2004-06-02 23:05

Message:
Logged In: YES 
user_id=990060

I don't understand one thing: how can python shut down
itself and, at the same time, keep a python code running in
a daemonised thread? or is that thread running in a
different "threaded" python byte-code interpreter?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-02 22:25

Message:
Logged In: YES 
user_id=31435

Brett, FYI, a daemon thread differs from a non-daemon 
thread in only one respect:  Python shuts down when only 
daemon threads remain.  It waits for non-daemon threads to 
finish.  So a daemon thread can keep running after the 
interpreter has torn itself down completely.  For that reason, 
problems in daemon threads doing non-trivial things are 
almost guaranteed.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-02 22:08

Message:
Logged In: YES 
user_id=357491

Yep, that is how Python cleans up a module; sets everything in the 
module to None and then removes it from sys.modules .

As for your case, I don't know enough about daemonized threads.  My 
patch for this only tries to let the exception make it to the top without 
'threading' hiding the exception by causing its own exception from 
interpreter shutdown.  In other words I don't know if this is a related 
issue or not.

----------------------------------------------------------------------

Comment By: k (carlosayam)
Date: 2004-06-02 20:01

Message:
Logged In: YES 
user_id=990060

bcannon said on 2004-02-17
>> Does anyone know how to cause this error in isolation?

I'm getting the same error when I start a new thread,
daemonise it and the thread goes into a very slow database
operation (loading a large object); meanwhile the main
thread starts a GUI; then I close the window, exiting the
main loop and the python interpreter ends (or tries to end.)

In relation to bcannon comment on how to reproduce the error
(setting all variables to None in the module), my guess is
that while exiting, the python interpreter is somehow
freeing all variables in the module (cleaning the module or
something), but the module is still running and that raises
the error... is this possible?

Note: if the thread is not daemonised, the problem desapears
but the script (the python interpreter) takes a while to finish.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-05-16 21:36

Message:
Logged In: YES 
user_id=357491

How to reproduce the bug:

* Follow the instructions at http://mnetproject.org/repos/ on how to get a 
copy of the in-dev version of mnet (I used the instructions for using wget 
and it worked fine).

* Run ``python setup.py``.  Do realize that this app will download other 
Python code (crypto stuff mostly) to finish its install.  Takes up about 54 
MB on my machine after it is compiled.

* Run ``python setup.py test -a``.  This executes the testing suite.  The 
bug manifests itself after the testing suite finishes execution.

This will consistently cause the bug every time.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-05-16 11:45

Message:
Logged In: YES 
user_id=357491

Discovered this is not fixed after all (previous fix didn't go far enough; 
still needed, though).  Patch 954922 is the second attempt to fix this.  
This time, though, I had code that could trigger the problem reliably and 
thus this should be the proper, and final, fix.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-08 14:36

Message:
Logged In: YES 
user_id=357491

OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just 
removed the two calls to currentThread in the _Condition class that were 
commented to be for their side-effect).

Just because I don't feel rock-solid on my fix to the point of it not 
changing some obscure semantics that I would be willing to put a gun to 
my head over it I am not going to backport this until I hear from 
someone who had this bug and reports that they have not had any issues 
for a long time.  Otherwise I will just leave the fix in 2.4 only.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-08 14:32

Message:
Logged In: YES 
user_id=357491

OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just 
removed the two calls to currentThread in the _Condition class that were 
commented to be for their side-effect).

Just because I don't feel rock-solid on my fix to the point of it not 
changing some obscure semantics that I would be willing to put a gun to 
my head over it I am not going to backport this until I hear from 
someone who had this bug and reports that they have not had any issues 
for a long time.  Otherwise I will just leave the fix in 2.4 only.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-02 20:29

Message:
Logged In: YES 
user_id=357491

To force this error I inserted code to set all attributes of the threading 
module to None and then throw and exception.  After commenting out 
the two calls to currentThread in _Condition the thrown exception to 
trigger the problem propogated to the top correctly.

I did have the clean-up function give out since I set *everything* to 
None, but it doesn't look like a normal issue as shown in the exception 
traceback in the OP.  I don't think it is an issue.

So it seems commenting the two calls to currentThread in _Condition 
solves the problem.  But since this is threading code and the comment 
explicitly states it is for the side-effect I am going to try to get a second 
opinion.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-02-16 20:59

Message:
Logged In: YES 
user_id=357491

Does anyone know how to cause this error in isolation?  I have tried a 
bunch of different ways but cannot cause an exception to be raised at the 
correct point in Threading.__bootstrap() to lead to self.__stop() to be 
called while the interpreter is tearing itself down.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-02-09 17:18

Message:
Logged In: YES 
user_id=357491

After staring at the code, I am not even sure if the calls for its side-
effect are needed.  If you call currentThread(), it either returns a value 
from _active which is a dict of running Thread instances indexed by 
thread idents, or a new _DummyThread instance that inserts itself into 
_active.  Now the two calls in the _Condition class are purely for this 
possible side-effect.

And yet at no point is anything from _active, through currentThread or 
direct access, even touched by a _Condition method.  The only chance 
this might be an issue is if a _Condition instance uses an RLock instance 
for its locking, which is the default behavior.

But this still makes the side-effect need useless.  RLocks will call 
currentThread on their own and since this is all in the same thread the 
result won't change.  And in this specific case of this bug, the _Condition 
instance is created with a Lock instance since that is what the Thread 
instance uses for constructing the _Condition instance it use, which is just 
thread.allocate_lock() which is obviously not an RLock.

In other words I can't find the point to the side-effect in _Condition.  I 
will try to come up with some testing code that reproduces the error and 
then see if just removing the calls in _Condition remove the error and 
still pass the regression tests.

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 2003-06-16 06:26

Message:
Logged In: YES 
user_id=491567

I can confirm that this behavior is not present in Python 2.2 in 
the same version that I am using to test against Python 2.3. 
 
I will be on vacation for most of this and next week.  I'll try to 
get to the logging script before I leave, but I might not get to it 
until I return. 
 
FYI, you can also obtain OfflineIMAP at 
http://quux.org/devel/offlineimap. 
 
 

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said &quot;when my application exits&quot;.  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

From noreply at sourceforge.net  Sat Jul  3 16:19:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul  3 16:19:29 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1Bgqys-0003ml-00@sc8-sf-web3.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 20:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (shredwheat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

From noreply at sourceforge.net  Sat Jul  3 21:23:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul  3 21:23:34 2004
Subject: [ python-Bugs-984290 ] Useless question in bdist_winst installers
Message-ID: <E1Bgvj6-0002xP-00@sc8-sf-web1.sourceforge.net>

Bugs item #984290, was opened at 2004-07-03 05:42
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984290&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Useless question in bdist_winst installers

Initial Comment:
Before a bdist_wininst created installer overwrites
files it asks the user whether files should be
overwritten or not.  This question is annoying and
doesn't seem very useful - it is too late to cancel the
installation (because some files might already have
been installed).

I suggest to remove this question (MessageBox), and
always overwrite files during the installation.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-04 11:23

Message:
Logged In: YES 
user_id=14198

+1 - just nuke it.  I can't think of *anything* that makes
sense to ask here, or even at the start (eg, checking if a
version is already installed and then asking the question
seems just as useless)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984290&group_id=5470

From noreply at sourceforge.net  Sun Jul  4 07:33:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul  4 07:33:21 2004
Subject: [ python-Bugs-984870 ] curses: getmaxyx() breaks when the window
	shrinks
Message-ID: <E1Bh5F3-0001XP-00@sc8-sf-web1.sourceforge.net>

Bugs item #984870, was opened at 2004-07-04 11:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984870&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses: getmaxyx() breaks when the window shrinks

Initial Comment:
[forwarded from http://bugs.debian.org/257472]

When derived windows of stdscr have been created,
shrinking the terminal produces a KEY_RESIZE event, but
getmaxyx() returns the previous terminal size. Only by
increasing the window size does it return the correct
terminal dimensions.

A minimal script to show this effect is included below.

#!/usr/bin/python
import curses, sys

def init_display(stdscr):
    stdscr.clear()
    stdscr.refresh()
    size = stdscr.getmaxyx()
    sys.stderr.write("Now %u x %u\n" % (size[1],size[0]))
    rootwin = stdscr.derwin(20, 50, 0, 0)
    return rootwin

def main(stdscr):
    rootwin = init_display(stdscr)
    while 1:
        input = rootwin.getch()
        if ( input == curses.KEY_RESIZE):
            init_display(stdscr)
        elif input == ord("q"):
            sys.exit()
        rootwin.refresh()

curses.wrapper(main)




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984870&group_id=5470

From noreply at sourceforge.net  Sun Jul  4 08:21:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul  4 08:21:41 2004
Subject: [ python-Bugs-924301 ] A leak case with cmd.py &amp; readline &amp;
	exception
Message-ID: <E1Bh5zo-0004A5-00@sc8-sf-web4.sourceforge.net>

Bugs item #924301, was opened at 2004-03-27 00:28
Message generated for change (Settings changed) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924301&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sverker Nilsson (svenil)
Assigned to: Michael Hudson (mwh)
Summary: A leak case with cmd.py &amp; readline &amp; exception

Initial Comment:
A leak to do with readline & cmd, in Python 2.3.

I found out what hold on to my interactive objects
too long ('for ever') in certain circumstances.  The
circumstance had to do with an exception being
raised in Cmd.cmdloop and handled (or not handled)
outside of Cmd.cmdloop.

In cmd.py, class Cmd, in cmdloop(), if an
exception is raised and propagated out from the
interior of cmdloop, the function postloop() is
not called. The default function of this, (in 2.3)
when the readline library is present, is to
restore the completer, via:

readline.set_completer(self.old_completer)

If this is not done, the newly (by preloop)
inserted completer will remain. Even if the loop
is called again and run without exception, the new
completer will remain, because then in postloop
the old completer will be set to our new
completer. When we exit, the completer will remain
the one we set. This will hold on to our object,
aka 'leak'. - In cmd.py in 2.2 no attempt was made
to restore the completer, so this was also a kind
of leak, but it was replaced the next time a Cmd
instance was initialized.  Now, however, the next
time we will not replace the old completer, but
both of them will remain in memory. The old one
will be stored as self.old_completer.  If we
terminate with an exception, bad luck... the
stored completer retains both of the instances. If
we terminate normally, the old one will be
retained.  In no case do we restore the space of
the first instance. The only way that would
happen, would be if the second instance first
exited the loop with an exception, and then
entered the loop again an exited normally. But
then, the second instance is retained instead! If
each instance happens to terminate with an
exception, it seems well possible that an ever
increasing chain of leaking instances will be
accumulated.

My fix is to always call the postloop, given the
preloop succeeded. This is done via a try:finally
clause.

    def cmdloop(self, intro=None):
	...

        self.preloop()
	try:
		...
	finally: # Make sure postloop called
	    self.postloop()

I am attaching my patched version of cmd.py.  It
was originally from the tarball of Python 2.3.3
downloaded from Python.org some month or so ago in
which cmd.py had this size & date:

14504 Feb 19 2003 cmd.py


Best regards,

Sverker Nilsson


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-01 15:52

Message:
Logged In: YES 
user_id=6656

Good.  Checked in as

Lib/cmd.py revision 1.38

If you want to fix any of the other issues, please file a separate 
patch...

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-06-30 17:20

Message:
Logged In: YES 
user_id=356603

I agree you should check it in. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-29 19:59

Message:
Logged In: YES 
user_id=6656

OK, so I was misreading (or reading an old version, or
something).

I agree with your comments about the bogosities, however
it's not my problem today :-)

Do you think I should check the attached patch in?  I do.

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-06-23 18:58

Message:
Logged In: YES 
user_id=356603

The constructor takes parameters stdin and stdout, and sets
self.stdin and self.stdout from them or from sys.
sys.std[in,out] are then not used directly except implicitly
by raw_input. This seems to have changed somewhere between
Python 2.2 and 2.3. Also, I remember an old version had the
cmdqueue list as a class variable which was not at all
thread safe - now it is an instance variable. I am
hoping/thinking it is thread safe now...

It seems  superfluos to have both the use_rawinput
flag and stdin parameter. At least raw_input should not
be used if stdin is some other file than the raw input.
But I don't have a simple suggestion to fix this, for one
thing, it wouldn't be sufficient to compare the stdin
parameter to sys.stdin since that file could have been
changed so it wasn't the raw stdin anymore. Perhaps the
module could store away the original sys.stdin as it was
imported... but that wouldn't quite work since there is no
guarantee sys.stdin hadn't already been changed. I guess if
it is worth the trouble, if someone has an idea, could be a
good thing to fix, anyway...


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-22 10:07

Message:
Logged In: YES 
user_id=6656

Um.  Unless I'm *hopelessly* misreading things, cmd.Cmd writes 
to sys.stdout unconditionally and either calls raw_input() or 
sys.stdin.readline().  So I'm not sure how one would "use a 
cmd.Cmd instance in a separate thread, talking eg via a socket 
file" without rewriting such huge amounts of the class that thread-
safety becomes your own problem.

Apologies if I'm being dumb... also, please note: I didn't write this 
module :-)

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-06-22 01:34

Message:
Logged In: YES 
user_id=356603

Your comment about threads worries me, I am not sure I
understand it. Would it be unsafe to use a cmd.Cmd instance
in a separate thread, talking eg via a socket file? The
instance is used only by that thread and not by others, but
there may be other threads using other instances. I
understand that it could be unsafe to have two threads share
the same instance, but how about different instances?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-21 11:35

Message:
Logged In: YES 
user_id=6656

Well, that would seem to be easy enough to fix (see attached).

If you're using cmd.Cmd instances from different threads at the 
same time, mind, I think you're screwed anyway.  You're certainly 
walking on thin ice...

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-06-18 20:13

Message:
Logged In: YES 
user_id=356603

I think it is OK.
Just noting that it changes the completer (just like my
version) even if use_rawinput is false. I guess one should
remember to pass a null completekey in that case, in case
some other thread was using raw_input. Perhaps a check for
use_rawinput could be added in cmd.py to avoid changing the
completer in that case, for less risk of future mistakes.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-11 13:29

Message:
Logged In: YES 
user_id=6656

yay, that appears to have worked.

let me know what you think.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-11 13:26

Message:
Logged In: YES 
user_id=6656

trying again...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-06-01 11:10

Message:
Logged In: YES 
user_id=6656

Bah.

I don't have the laptop with the patch with me, I'll try
uploading again in a couple of days.

----------------------------------------------------------------------

Comment By: Sverker Nilsson (svenil)
Date: 2004-05-29 08:43

Message:
Logged In: YES 
user_id=356603

I couldn't find a new attached file.
I acknowledge some problems with my original patch,
but have no other suggestion at the moment.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-05-26 17:36

Message:
Logged In: YES 
user_id=6656

What do you think of the attached?

This makes the documentation of pre & post loop more accurate 
again, which I think is nice.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-05-19 10:38

Message:
Logged In: YES 
user_id=6656

This is where I go "I wish I'd reviewed that patch more
carefully".

In particular, the documentation of {pre,post}loop is now
out of date.

I wonder setting/getting the completer in these functions
was a good idea.  Hmm.  This bug report confuses me :-) but
I can certainly see the intent of the patch...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-05-19 02:52

Message:
Logged In: YES 
user_id=80475

Michael, this touches some of your code.  Do you want to
handle this one?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924301&group_id=5470

From noreply at sourceforge.net  Sun Jul  4 11:45:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul  4 11:45:33 2004
Subject: [ python-Bugs-984952 ] PEP 307 pickle extensions not documented
Message-ID: <E1Bh9B0-00006r-00@sc8-sf-web1.sourceforge.net>

Bugs item #984952, was opened at 2004-07-04 07:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984952&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 307 pickle extensions not documented

Initial Comment:
>From a quick perusal of the developer documentation
(from www.python.org), it appears that PEP 307 has not
yet been integrated into the standard documentation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984952&group_id=5470

From noreply at sourceforge.net  Sun Jul  4 17:30:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul  4 17:31:17 2004
Subject: [ python-Bugs-985064 ] plistlib crashes too easily on bad files
Message-ID: <E1BhEZB-0001Mp-00@sc8-sf-web3.sourceforge.net>

Bugs item #985064, was opened at 2004-07-04 23:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985064&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: plistlib crashes too easily on bad files

Initial Comment:
Plistlib doesn't do much error checking, and it can crash on bad 
input. Moreover, it doesn't provide much help if it does crash (no 
linenumbers, etc).

The problem I ran into was a dangling <key>foo</key>. After this 
key the dict ended, but the next entry in the surrounding 
datastructure, an array, picked up the key from self.currentKey 
and crashed in addObject().

I was about to fix this when I noticed that there's lots of problems 
with <key> handling, duplicates or missing ones aren't detected 
either and can cause crashes too. It may be better to put a general 
try/except in parse() and print a line number or something in case 
of a failure.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985064&group_id=5470

From noreply at sourceforge.net  Sun Jul  4 19:21:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul  4 19:22:13 2004
Subject: [ python-Bugs-985094 ] getattr(object,name) accepts only strings
Message-ID: <E1BhGIt-0005SG-00@sc8-sf-web4.sourceforge.net>

Bugs item #985094, was opened at 2004-07-05 01:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985094&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: getattr(object,name) accepts only strings

Initial Comment:
getattr(object,name) function accepts only strings. This behavior prohibits some interesting usage of callables as names in database column and field references.

For example:

Someone references a database field:
value=record.field_name

Programmatically, when name is the name of the field:
value=getattr(record,field_name)

Calculated fields could be implemented by passing a callable as a field name:

def fn(record): return '%s (%s)'%(record.name,record.number)

value=getattr(record,fn)

The database backend checks if the name is callable and then call the name with the record.

But this cannot be implemented in the simple way if getattr checks if the name is a string or not. This is an unneccessary check in getattr, setattr and delattr, since prevents interesting solutions.

Temporary workaround:

value=record.__getattr__(fn)

There can be many unneccessary type checks and limitations in core and library functions. They should be removed to allow free usage.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985094&group_id=5470

From noreply at sourceforge.net  Sun Jul  4 22:38:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul  4 22:38:33 2004
Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4
	under cygwin
Message-ID: <E1BhJMm-0001Hx-00@sc8-sf-web4.sourceforge.net>

Bugs item #985154, was opened at 2004-07-04 22:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin

Initial Comment:
Building 2.3.4 from the tarball, 
#define HAVE_FDATASYNC 1
appears in the pyconfig.h file, and
the build of 'posixmodule' fails with
undefined symbol _fdatasync

Workaround is to delete the line
and proceed, of course, but I've
never seen this before when building
under cygwin.

There is no 'fdatasync' mentioned
in any /usr/include/*.h or /usr/local/include/*.h

The cygwin installation is kind of a mongrel
(4 or 5 upgrades since install, some selective)
This is the ID string from the built python:

Python 2.3.4 (#2, Jul  4 2004, 22:10:22)
[GCC 3.3.1 (cygming special)] on cygwin

Let me know of any details of the cygwin install
which might be useful.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470

From noreply at sourceforge.net  Sun Jul  4 23:46:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul  4 23:48:05 2004
Subject: [ python-Bugs-764447 ] cvs update warnings
Message-ID: <E1BhKRW-0002Mj-00@sc8-sf-web1.sourceforge.net>

Bugs item #764447, was opened at 2003-07-02 17:56
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Just van Rossum (jvr)
Summary: cvs update warnings

Initial Comment:
On Windows, when you do &quot;cvs update&quot; in the &quot;Mac/IDE
scripts&quot; directory, you get the following warnings
(example uses Cygwin, but it also happens with other
CVS clients):

$ cd &quot;Mac/IDE scripts&quot;; 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
$

This is due to the fact that Windows can't deal with
periods at the end of file names.  All files giving
warnings end in &quot;...&quot;.  These periods are removed when
the files get created, and so CVS sees the files
without periods and complains about them.

At one level the solution is simple: rename those
files.  At another level, I don't know what the
consequences are for the Mac, so assigning to Just
(Jack doesn't seem to want to deal with this :-)


----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-07-05 13:46

Message:
Logged In: YES 
user_id=1038590

The leading spaces on some filenames are causing Eclipse to
choke on the checkout, too (I'm guessing the spaces are
there to get the right sequencing of the filenames).

One possibility that would give a minimal change is to
prepend and append underscores to all of the filenames, then
modify the code that reads these files to remove the first
and last character before performing the same parsing it
does now.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-09-10 00:12

Message:
Logged In: YES 
user_id=43607

It's now past 2.3 final, so can you look into this again?

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2003-07-02 20:36

Message:
Logged In: YES 
user_id=43607

I've lived with this for years.  A few more weeks won't matter.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-07-02 19:33

Message:
Logged In: YES 
user_id=92689

Any objections to postponing this to after 2.3 final? The thing is, 
currently these file names map to menu items directly, and to fix 
this I have to build a way to specify the menu item from within 
the file. This will cause way more changes than I'm comfortable 
with, just before 2.3. Removing the spaces from folder names can 
be done at the same time.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470

From noreply at sourceforge.net  Mon Jul  5 08:06:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul  5 08:06:52 2004
Subject: [ python-Bugs-968245 ] Python Logging filename & file number 
Message-ID: <E1BhSFC-00012P-00@sc8-sf-web4.sourceforge.net>

Bugs item #968245, was opened at 2004-06-07 15:49
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

Category: Python Library
>Group: Python 2.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Ryan (superleo303)
Assigned to: Vinay Sajip (vsajip)
Summary: Python Logging filename & file number 

Initial Comment:
I use Freebsd and redhat 9.0 linus at work.

Using Python Logging filename & file number on freebsd
works fine.
When i print a log statement, and have my config
formatter section set like:
[formatter_default]
format=%(asctime)s <%(levelname)s>
<%(module)s:%(lineno)s> %(message)s
datefmt=

On bsd my logs look like:
<INFO> <propmancmd:95> stateOnly is: DE
<INFO> <propmancmd:105>  MEssages .........
<INFO> <propmancmd:107> collecting datasource: 1011
<INFO> <propman:98>   Collectors overwrite existing
pickle files: 0
<INFO> <propman:99>           Collectors run in
multiple threads: 4
<DEBUG> <propman:528> sql is:
...

See, the filename and file number get displayed with
each logging call,

Now, The same exact code run on the same exact version
of python on a linux machine yiedls the lines:

<INFO> <__init__:988> stateOnly is: DE
<INFO> <__init__:988>  MEssages
<INFO> <__init__:988> collecting datasource: 1011
<INFO> <__init__:988>   Collectors overwrite existing
pickle files: 0
<INFO> <__init__:988>           Collectors run in
multiple threads: 4
<DEBUG> <__init__:988> sql is: 
...

So i opened up ./python2.3/logging/__init__.py  line
988 and it seems to be where the problem is.

Can someone take a look at this asap?   I have to run
all my code on linux machines, so now i cant see which
file and which line is making the logging.

To reproduce, get a freebsd and linux machine,
then run a simple script that uses logging config files
and use the above example as your formatter in the
logging confrig file,

BSD should show the filenames and numbers, linux should
show __init__ 988 instead.


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-05 12:06

Message:
Logged In: YES 
user_id=308438

I'm not able to reproduce these problems under Linux - I only 
have access to Mandrake 10.0 (a Red Hat variant).

Can you upload a script or set of scripts which demonstrates 
the problem?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-06-10 17:18

Message:
Logged In: YES 
user_id=1058618

vsajip, i tested on both machines, both machines returned
the same results:

STACKWALKER RESULTS RUN ON LINUX RED HAT 9.0

[rsmith@marge]:~/ned$ cd bin/testing/stackwalk/
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw1.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw2.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw3.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw4.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python getcaller.py
/home/rsmith/ned/bin/testing/stackwalk/sw1.py(4)
/home/rsmith/ned/bin/testing/stackwalk/sw2.py(5)
/home/rsmith/ned/bin/testing/stackwalk/sw3.py(6)
/home/rsmith/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[rsmith@marge]:~/ned/bin/testing/stackwalk$


-------------------------------------------------------------------------

STACKWALKER RESULTS RUN ON FREEBSD 5.2.1-RELEASE-p8

[ryan@dev2]:~/ned$ cd bin/testing/stackwalk/
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw1.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw2.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw3.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw4.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python getcaller.py
/usr/home/ryan/ned/bin/testing/stackwalk/sw1.py(4)
/usr/home/ryan/ned/bin/testing/stackwalk/sw2.py(5)
/usr/home/ryan/ned/bin/testing/stackwalk/sw3.py(6)
/usr/home/ryan/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[ryan@dev2]:~/ned/bin/testing/stackwalk$

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 09:26

Message:
Logged In: YES 
user_id=308438

The problem appears to be related to some underlying 
problem with sys._getframe(). Can you please download the 
attached stackwalk.tar.gz and run it on both FreeBSD and 
Linux? Please post your findings here, thanks. Note that the 
stackwalk stuff contains no calls to the logging package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

From noreply at sourceforge.net  Mon Jul  5 09:40:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul  5 09:40:44 2004
Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4
	under cygwin
Message-ID: <E1BhTi2-00050u-00@sc8-sf-web2.sourceforge.net>

Bugs item #985154, was opened at 2004-07-05 03:38
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin

Initial Comment:
Building 2.3.4 from the tarball, 
#define HAVE_FDATASYNC 1
appears in the pyconfig.h file, and
the build of 'posixmodule' fails with
undefined symbol _fdatasync

Workaround is to delete the line
and proceed, of course, but I've
never seen this before when building
under cygwin.

There is no 'fdatasync' mentioned
in any /usr/include/*.h or /usr/local/include/*.h

The cygwin installation is kind of a mongrel
(4 or 5 upgrades since install, some selective)
This is the ID string from the built python:

Python 2.3.4 (#2, Jul  4 2004, 22:10:22)
[GCC 3.3.1 (cygming special)] on cygwin

Let me know of any details of the cygwin install
which might be useful.




----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-05 14:40

Message:
Logged In: YES 
user_id=6656

That's odd.  Why does configure think you have fdatasync?  Maybe 
config.log will help...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470

From noreply at sourceforge.net  Mon Jul  5 12:14:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul  5 12:15:00 2004
Subject: [ python-Bugs-985478 ] bdist_rpm license documented,
	but not accepted as valid
Message-ID: <E1BhW7N-0002UY-00@sc8-sf-web4.sourceforge.net>

Bugs item #985478, was opened at 2004-07-05 10:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985478&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles (melicertes)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_rpm license documented, but not accepted as valid

Initial Comment:
The distutils documentation at
http://docs.python.org/dist/postinstallation-script.html#SECTION000620000000000000000
states that the RPM copyright field can be set using
the distutils setup script option "licence", but it is
refused as invalid by distutils:

$ /usr/bin/python2.3 setup.py bdist_rpm --licence="GNU
GPL v.2"
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2
[cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --licence not recognized


It's also refused (same error message output, except
for spelling) with the spelling "license".  Both
spellings are also 
rejected as errors if placed in setup.cfg's [bdist_rpm]
section:

$ /usr/bin/python2.3 setup.py bdist_rpm
running bdist_rpm
error: error in setup.cfg: command 'bdist_rpm' has no
such option 'license'







----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985478&group_id=5470

From noreply at sourceforge.net  Mon Jul  5 12:43:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul  5 12:44:01 2004
Subject: [ python-Bugs-985478 ] bdist_rpm license documented,
	but not accepted as valid
Message-ID: <E1BhWZL-0003Zh-00@sc8-sf-web4.sourceforge.net>

Bugs item #985478, was opened at 2004-07-05 10:14
Message generated for change (Comment added) made by melicertes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985478&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles (melicertes)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_rpm license documented, but not accepted as valid

Initial Comment:
The distutils documentation at
http://docs.python.org/dist/postinstallation-script.html#SECTION000620000000000000000
states that the RPM copyright field can be set using
the distutils setup script option "licence", but it is
refused as invalid by distutils:

$ /usr/bin/python2.3 setup.py bdist_rpm --licence="GNU
GPL v.2"
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2
[cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --licence not recognized


It's also refused (same error message output, except
for spelling) with the spelling "license".  Both
spellings are also 
rejected as errors if placed in setup.cfg's [bdist_rpm]
section:

$ /usr/bin/python2.3 setup.py bdist_rpm
running bdist_rpm
error: error in setup.cfg: command 'bdist_rpm' has no
such option 'license'







----------------------------------------------------------------------

>Comment By: Charles (melicertes)
Date: 2004-07-05 10:43

Message:
Logged In: YES 
user_id=1064824

This was tested with Python 2.3.4 final, by the way.  The
behaviour was unchanged in earlier release candidates.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985478&group_id=5470

From noreply at sourceforge.net  Tue Jul  6 01:30:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul  6 04:45:51 2004
Subject: [ python-Bugs-985651 ] BaseHTTPServer to take host from cmdline?
Message-ID: <E1Bhcup-0008WG-00@sc8-sf-web3.sourceforge.net>

Bugs item #985651, was opened at 2004-07-05 23:29
Message generated for change (Settings changed) made by tlynn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985651&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
>Priority: 2
Submitted By: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: BaseHTTPServer to take host from cmdline?

Initial Comment:
BaseHTTPServer.py can be run from the command line, in
which case it takes its port from the command line but
it assumes the hostname is empty.  My grasp of these
things is poor, but  my understanding is that empty
hostname implies not externally visible.  Shouldn't it
be possible to supply the hostname on the command line
too (even if the above belief is incorrect)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985651&group_id=5470
From noreply at sourceforge.net  Tue Jul  6 03:58:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul  6 04:45:53 2004
Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4
	under cygwin
Message-ID: <E1BhfDe-0003jA-00@sc8-sf-web3.sourceforge.net>

Bugs item #985154, was opened at 2004-07-04 22:38
Message generated for change (Comment added) made by gregsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin

Initial Comment:
Building 2.3.4 from the tarball, 
#define HAVE_FDATASYNC 1
appears in the pyconfig.h file, and
the build of 'posixmodule' fails with
undefined symbol _fdatasync

Workaround is to delete the line
and proceed, of course, but I've
never seen this before when building
under cygwin.

There is no 'fdatasync' mentioned
in any /usr/include/*.h or /usr/local/include/*.h

The cygwin installation is kind of a mongrel
(4 or 5 upgrades since install, some selective)
This is the ID string from the built python:

Python 2.3.4 (#2, Jul  4 2004, 22:10:22)
[GCC 3.3.1 (cygming special)] on cygwin

Let me know of any details of the cygwin install
which might be useful.




----------------------------------------------------------------------

>Comment By: Gregory Smith (gregsmith)
Date: 2004-07-05 21:58

Message:
Logged In: YES 
user_id=292741

looked into config.log and 'configure' itself.. the compile
for fdatasync succeeded, but the script does not attempt
to link it.  gcc -E  led me to the following 
chunk of /usr/include/sys/unistd.h:

(not inside any #ifdefs, as far as I can tell)

int     _EXFUN(fdatasync, (int __fd));


So it's declared in the header, but it's not in the
library. This symbol is defined in libc.a on a RH8.0
system, I can't find it anywhere on the cygwin system.
 




----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-05 09:40

Message:
Logged In: YES 
user_id=6656

That's odd.  Why does configure think you have fdatasync?  Maybe 
config.log will help...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470
From noreply at sourceforge.net  Tue Jul  6 01:29:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul  6 04:45:54 2004
Subject: [ python-Bugs-985651 ] BaseHTTPServer to take host from cmdline?
Message-ID: <E1BhcuE-0008Uv-00@sc8-sf-web3.sourceforge.net>

Bugs item #985651, was opened at 2004-07-05 23:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985651&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: BaseHTTPServer to take host from cmdline?

Initial Comment:
BaseHTTPServer.py can be run from the command line, in
which case it takes its port from the command line but
it assumes the hostname is empty.  My grasp of these
things is poor, but  my understanding is that empty
hostname implies not externally visible.  Shouldn't it
be possible to supply the hostname on the command line
too (even if the above belief is incorrect)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985651&group_id=5470
From noreply at sourceforge.net  Tue Jul  6 06:11:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul  6 06:11:39 2004
Subject: [ python-Bugs-985708 ] valgrind/memcheck alert: Python 2.3.4
	Objects/obmalloc.c
Message-ID: <E1BhhIq-0005Ha-00@sc8-sf-web4.sourceforge.net>

Bugs item #985708, was opened at 2004-07-05 21:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: valgrind/memcheck alert: Python 2.3.4 Objects/obmalloc.c

Initial Comment:
While trying to debug a segmentation fault I 
discovered to my great
surpise that Python 2.3.4 is not valgrind/memcheck 
clean. I observed
the same problem with three different versions of 
valgrind under
three different Linux versions:

    Python 2.3.4 (#1, May 29 2004, 02:54:59) 
    [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-
113)] on linux2
    valgrind-1.9.5

    Python 2.3.4 (#1, Jul  5 2004, 19:51:02) 
    [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on 
linux2
    valgrind-2.0.0

    Python 2.3.4 (#7, Jul  5 2004, 20:34:14) 
    [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-20)] 
on linux2
    valgrind-2.1.1

In the following I'll report results obtained under 
Red Hat Linux 3.2.3
with valgrind-2.1.1. The valgrind source code is 
available at this
location:

    http://valgrind.kde.org/

In my experience valgrind is a very reliable tool.

A am using Python-2.3.4.tgz as downloaded today 
from python.org.
After a fresh ./configure --prefix=/var/tmp/py234 
and make
executing the command

  valgrind --tool=memcheck ./python

produces this output:

==32282== Memcheck, a memory error detector for 
x86-linux.
==32282== Copyright (C) 2002-2004, and GNU 
GPL'd, by Julian Seward.
==32282== Using valgrind-2.1.1, a program 
supervision framework for x86-linux.
==32282== Copyright (C) 2000-2004, and GNU 
GPL'd, by Julian Seward.
==32282== For more details, rerun with: -v
==32282==
==32282== Conditional jump or move depends on 
uninitialised value(s)
==32282==    at 0x807AE88: PyObject_Free 
(obmalloc.c:711)
==32282==    by 0x8074B81: dictresize 
(dictobject.c:477)
==32282==    by 0x8074D61: PyDict_SetItem 
(dictobject.c:550)
==32282==    by 0x8082E01: 
PyString_InternInPlace (stringobject.c:4140)
==32282==

Plus a few hundred lines more that are not shown. 
These are lines
710 and 711 of obmalloc.c:

        pool = POOL_ADDR(p);
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 
{

ADDRESS_IN_RANGE is a complicated macro. 
Therefore I've inserted
the following print statemnt:

        pool = POOL_ADDR(p);
        if (pool->arenaindex == 0) printf("HELLO\n");
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 
{

With this valgrind still points to line 711, i.e. 
apparently the
problem is that pool->arenaindex is not initialized. 
However, the
output shows a large number of HELLO, suggesting 
that the uninitialized
value is 0 by coincidence.

Is this something to worry about? Or is this a rare 
case of valgrind
being mistaken? (It would be the first such case for 
me.)

Thanks,
        Ralf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470
From noreply at sourceforge.net  Tue Jul  6 06:23:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul  6 06:23:25 2004
Subject: [ python-Bugs-985708 ] valgrind/memcheck alert: Python 2.3.4
	Objects/obmalloc.c
Message-ID: <E1BhhUG-0007QH-00@sc8-sf-web3.sourceforge.net>

Bugs item #985708, was opened at 2004-07-06 00:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: valgrind/memcheck alert: Python 2.3.4 Objects/obmalloc.c

Initial Comment:
While trying to debug a segmentation fault I 
discovered to my great
surpise that Python 2.3.4 is not valgrind/memcheck 
clean. I observed
the same problem with three different versions of 
valgrind under
three different Linux versions:

    Python 2.3.4 (#1, May 29 2004, 02:54:59) 
    [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-
113)] on linux2
    valgrind-1.9.5

    Python 2.3.4 (#1, Jul  5 2004, 19:51:02) 
    [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on 
linux2
    valgrind-2.0.0

    Python 2.3.4 (#7, Jul  5 2004, 20:34:14) 
    [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-20)] 
on linux2
    valgrind-2.1.1

In the following I'll report results obtained under 
Red Hat Linux 3.2.3
with valgrind-2.1.1. The valgrind source code is 
available at this
location:

    http://valgrind.kde.org/

In my experience valgrind is a very reliable tool.

A am using Python-2.3.4.tgz as downloaded today 
from python.org.
After a fresh ./configure --prefix=/var/tmp/py234 
and make
executing the command

  valgrind --tool=memcheck ./python

produces this output:

==32282== Memcheck, a memory error detector for 
x86-linux.
==32282== Copyright (C) 2002-2004, and GNU 
GPL'd, by Julian Seward.
==32282== Using valgrind-2.1.1, a program 
supervision framework for x86-linux.
==32282== Copyright (C) 2000-2004, and GNU 
GPL'd, by Julian Seward.
==32282== For more details, rerun with: -v
==32282==
==32282== Conditional jump or move depends on 
uninitialised value(s)
==32282==    at 0x807AE88: PyObject_Free 
(obmalloc.c:711)
==32282==    by 0x8074B81: dictresize 
(dictobject.c:477)
==32282==    by 0x8074D61: PyDict_SetItem 
(dictobject.c:550)
==32282==    by 0x8082E01: 
PyString_InternInPlace (stringobject.c:4140)
==32282==

Plus a few hundred lines more that are not shown. 
These are lines
710 and 711 of obmalloc.c:

        pool = POOL_ADDR(p);
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 
{

ADDRESS_IN_RANGE is a complicated macro. 
Therefore I've inserted
the following print statemnt:

        pool = POOL_ADDR(p);
        if (pool->arenaindex == 0) printf("HELLO\n");
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 
{

With this valgrind still points to line 711, i.e. 
apparently the
problem is that pool->arenaindex is not initialized. 
However, the
output shows a large number of HELLO, suggesting 
that the uninitialized
value is 0 by coincidence.

Is this something to worry about? Or is this a rare 
case of valgrind
being mistaken? (It would be the first such case for 
me.)

Thanks,
        Ralf


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-06 00:23

Message:
Logged In: YES 
user_id=31435

Neal, where did you document the 
Py_USING_MEMORY_DEBUGGER gimmick?  I didn't find 
anything about it NEWS, or in Misc/SpecialBuilds.txt.

Ralf, yes, ADDRESS_IN_RANGE reads uninitialized memory.  
This is an intentional extreme speed hack, and won't change.  
Neal checked things in to current CVS Python to support 
telling valgrind to shut up about it, but I don't know how to 
use that ... ah, OK, in current CVS Python, read 
Misc/README.valgrind.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470
From noreply at sourceforge.net  Tue Jul  6 08:42:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul  6 08:42:04 2004
Subject: [ python-Bugs-985753 ] weakref should have a WeakSet
Message-ID: <E1BhjeS-0002hV-00@sc8-sf-web4.sourceforge.net>

Bugs item #985753, was opened at 2004-07-06 03:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985753&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref should have a WeakSet

Initial Comment:
It'd be nice if weakref had a WeakSet. This way I
wouldn't need a WeakValueDictionary keyed by id(object)
when all I want is to iterate over the objects that are
still alive.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985753&group_id=5470
From noreply at sourceforge.net  Tue Jul  6 16:09:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul  6 16:09:47 2004
Subject: [ python-Bugs-985753 ] weakref should have a WeakSet
Message-ID: <E1Bhqdf-0004jH-00@sc8-sf-web4.sourceforge.net>

Bugs item #985753, was opened at 2004-07-06 01:42
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985753&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref should have a WeakSet

Initial Comment:
It'd be nice if weakref had a WeakSet. This way I
wouldn't need a WeakValueDictionary keyed by id(object)
when all I want is to iterate over the objects that are
still alive.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-06 09:09

Message:
Logged In: YES 
user_id=80475

Why not use a WeakKeyDictionary with the values set to True?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985753&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 09:32:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 09:32:32 2004
Subject: [ python-Bugs-984290 ] Useless question in bdist_winst installers
Message-ID: <E1Bi6up-00015S-00@sc8-sf-web1.sourceforge.net>

Bugs item #984290, was opened at 2004-07-02 21:42
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984290&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Useless question in bdist_winst installers

Initial Comment:
Before a bdist_wininst created installer overwrites
files it asks the user whether files should be
overwritten or not.  This question is annoying and
doesn't seem very useful - it is too late to cancel the
installation (because some files might already have
been installed).

I suggest to remove this question (MessageBox), and
always overwrite files during the installation.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-07 09:32

Message:
Logged In: YES 
user_id=11105

Removed the useless question.  Thanks for the comment.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-07-04 03:23

Message:
Logged In: YES 
user_id=14198

+1 - just nuke it.  I can't think of *anything* that makes
sense to ask here, or even at the start (eg, checking if a
version is already installed and then asking the question
seems just as useless)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984290&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 13:12:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 13:12:14 2004
Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4
	under cygwin
Message-ID: <E1BiALL-0005Ew-00@sc8-sf-web3.sourceforge.net>

Bugs item #985154, was opened at 2004-07-05 03:38
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin

Initial Comment:
Building 2.3.4 from the tarball, 
#define HAVE_FDATASYNC 1
appears in the pyconfig.h file, and
the build of 'posixmodule' fails with
undefined symbol _fdatasync

Workaround is to delete the line
and proceed, of course, but I've
never seen this before when building
under cygwin.

There is no 'fdatasync' mentioned
in any /usr/include/*.h or /usr/local/include/*.h

The cygwin installation is kind of a mongrel
(4 or 5 upgrades since install, some selective)
This is the ID string from the built python:

Python 2.3.4 (#2, Jul  4 2004, 22:10:22)
[GCC 3.3.1 (cygming special)] on cygwin

Let me know of any details of the cygwin install
which might be useful.




----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-07 12:12

Message:
Logged In: YES 
user_id=6656

Well, I guess that's an arguable bug in cygwin, but if you want to 
supply a patch that modifies configure to do the linking test too, 
I'll at least think about applying it :-)

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2004-07-06 02:58

Message:
Logged In: YES 
user_id=292741

looked into config.log and 'configure' itself.. the compile
for fdatasync succeeded, but the script does not attempt
to link it.  gcc -E  led me to the following 
chunk of /usr/include/sys/unistd.h:

(not inside any #ifdefs, as far as I can tell)

int     _EXFUN(fdatasync, (int __fd));


So it's declared in the header, but it's not in the
library. This symbol is defined in libc.a on a RH8.0
system, I can't find it anywhere on the cygwin system.
 




----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-05 14:40

Message:
Logged In: YES 
user_id=6656

That's odd.  Why does configure think you have fdatasync?  Maybe 
config.log will help...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 13:51:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 13:51:20 2004
Subject: [ python-Bugs-986528 ] bsddb/weakref error
Message-ID: <E1BiAxE-0002Cu-00@sc8-sf-web2.sourceforge.net>

Bugs item #986528, was opened at 2004-07-07 06:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb/weakref error

Initial Comment:
After a cvs up and reinstall of Python, Spambayes is giving 
me this traceback:

Traceback (most recent call last):
  File "/Users/skip/local/bin/sb_filter.py", line 257, in ?
    main()
  File "/Users/skip/local/bin/sb_filter.py", line 248, in main
    action(msg)
  File "/Users/skip/local/bin/sb_filter.py", line 192, in 
train_spam
    self.open('c')
  File "/Users/skip/local/bin/sb_filter.py", line 163, in open
    self.h = hammie.open(self.dbname, self.usedb, 
self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/hammie.py", line 275, in open
    return Hammie(storage.open_storage(filename, useDB, 
mode))
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 679, in open_storage
    return klass(data_source_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 164, in __init__
    self.load()
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 189, in load
    self.dbm = dbmstorage.open(self.db_name, self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 65, in open
    return f(db_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 19, in open_dbhash
    import bsddb
  File "/Users/skip/local/lib/python2.4/bsddb/__init__.py", 
line 68, in ?
    exec """
  File "<string>", line 3, in ?
  File "/Users/skip/local/lib/python2.4/weakref.py", line 152, 
in ?
    class KeyedRef(ref):
TypeError: cannot create 'builtin_function_or_method' 
instances

I don't know what it means, but it wasn't happening before 
the cvs up.  I suspect something changed in the bsddb3 
stuff, so I'm provisionally giving it to Greg.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 15:09:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 15:09:32 2004
Subject: [ python-Bugs-984017 ] Buffer Protocol Prototypes Incorrect
Message-ID: <E1BiCAo-00065Y-00@sc8-sf-web1.sourceforge.net>

Bugs item #984017, was opened at 2004-07-02 08:13
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984017&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Timothy Stranex (perspex)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Buffer Protocol Prototypes Incorrect

Initial Comment:
The PyObject_AsReadBuffer and PyObject_AsWriteBuffer
functions are documented incorrectly in the Python/C
API Reference Manual for both Python 2.3 and the
current development documentation.

Section 6.6 ("Buffer Protocol") state the following
prototypes:

    - int PyObject_AsReadBuffer(PyObject *obj, const
char **buffer, int *buffer_len)
    - int PyObject_AsWriteBuffer(PyObject *obj, char
**buffer, int *buffer_len)

while Include/abstract.h define them as follows:

    - int PyObject_AsReadBuffer(PyObject *obj, const
void **buffer, int *buffer_len)
    - int PyObject_AsWriteBuffer(PyObject *obj, void
**buffer, int *buffer_len);

In each case, "char **buffer" should be changed to
"void **buffer". I've included a patch against Python
2.3.3 in diff -u format that fixes this. It modifies
Doc/api/abstract.tex.

Thanks,
Timothy Stranex

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 09:09

Message:
Logged In: YES 
user_id=11375

Fixed in both CVS HEAD and the 2.3 maintenance branch.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984017&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 15:12:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 15:12:52 2004
Subject: [ python-Bugs-984870 ] curses: getmaxyx() breaks when the window
	shrinks
Message-ID: <E1BiCE6-0001mI-00@sc8-sf-web3.sourceforge.net>

Bugs item #984870, was opened at 2004-07-04 07:33
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984870&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: A.M. Kuchling (akuchling)
Summary: curses: getmaxyx() breaks when the window shrinks

Initial Comment:
[forwarded from http://bugs.debian.org/257472]

When derived windows of stdscr have been created,
shrinking the terminal produces a KEY_RESIZE event, but
getmaxyx() returns the previous terminal size. Only by
increasing the window size does it return the correct
terminal dimensions.

A minimal script to show this effect is included below.

#!/usr/bin/python
import curses, sys

def init_display(stdscr):
    stdscr.clear()
    stdscr.refresh()
    size = stdscr.getmaxyx()
    sys.stderr.write("Now %u x %u\n" % (size[1],size[0]))
    rootwin = stdscr.derwin(20, 50, 0, 0)
    return rootwin

def main(stdscr):
    rootwin = init_display(stdscr)
    while 1:
        input = rootwin.getch()
        if ( input == curses.KEY_RESIZE):
            init_display(stdscr)
        elif input == ord("q"):
            sys.exit()
        rootwin.refresh()

curses.wrapper(main)




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984870&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 15:19:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 15:19:48 2004
Subject: [ python-Bugs-984870 ] curses: getmaxyx() breaks when the window
	shrinks
Message-ID: <E1BiCKq-0003Ty-00@sc8-sf-web4.sourceforge.net>

Bugs item #984870, was opened at 2004-07-04 07:33
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984870&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Nobody/Anonymous (nobody)
Summary: curses: getmaxyx() breaks when the window shrinks

Initial Comment:
[forwarded from http://bugs.debian.org/257472]

When derived windows of stdscr have been created,
shrinking the terminal produces a KEY_RESIZE event, but
getmaxyx() returns the previous terminal size. Only by
increasing the window size does it return the correct
terminal dimensions.

A minimal script to show this effect is included below.

#!/usr/bin/python
import curses, sys

def init_display(stdscr):
    stdscr.clear()
    stdscr.refresh()
    size = stdscr.getmaxyx()
    sys.stderr.write("Now %u x %u\n" % (size[1],size[0]))
    rootwin = stdscr.derwin(20, 50, 0, 0)
    return rootwin

def main(stdscr):
    rootwin = init_display(stdscr)
    while 1:
        input = rootwin.getch()
        if ( input == curses.KEY_RESIZE):
            init_display(stdscr)
        elif input == ord("q"):
            sys.exit()
        rootwin.refresh()

curses.wrapper(main)




----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 09:19

Message:
Logged In: YES 
user_id=11375

Confirmed.  I suspect this is a problem in ncurses, and will
write a C equivalent of the test program to verify this. 
The ncurses man page for derwin says: "The  subwindow 
functions  (subwin,  derwin, ...) are flaky,   incompletely
implemented, and not well tested," so an ncurses bug seems
likely.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984870&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 15:54:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 15:54:37 2004
Subject: [ python-Bugs-913619 ] httplib: HTTPS does not close() connection
	properly
Message-ID: <E1BiCsb-00051l-00@sc8-sf-web4.sourceforge.net>

Bugs item #913619, was opened at 2004-03-10 12:00
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=913619&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: rick (sf_rick)
>Assigned to: A.M. Kuchling (akuchling)
Summary: httplib:  HTTPS does not close() connection properly

Initial Comment:
When looping through requests to an HTTP server close()
closes out the active connection.  An the second loop
through a new HTTP connection is created.

When looping through requests to an HTTPS server
close() does not close the connection.  It keeps it
active.  On the second pass through the loop
httplib.HTTPS uses the previously initiated connection.
 Shouldn't close() close out the connection as it does
for the HTTP connection?

sample code to illustrate:

def getdata(): 
    params = urllib.urlencode({'username': 'test',
'password': 'test'})
    h = httplib.HTTPS(host = "test.site.com", port =
443, key_file = "fake.pem", cert_file = "fake.pem")
    h.putrequest('POST', '/scripts/cgi.exe?')
    h.putheader('Content-length', '%d'%len(params))
    h.putheader('Accept', 'text/plain')
    h.putheader('Host', 'test.site.com')
    h.endheaders()
    h.send(params)
    reply, msg, hdrs = h.getreply()
    data = h.getfile().read()
    file('test.file', 'w').write(data)
    h.close()
    


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 09:54

Message:
Logged In: YES 
user_id=11375

Closing as suggested.


----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-06-05 13:39

Message:
Logged In: YES 
user_id=113328

I'm not sure there's a need to document the makefile/close
thing in the Python manual, as the sock attribute isn't
publicly documented.

Internally, the constraint must be adhered to, but I can't
see evidence of where it isn't.

Unless the OP can provide a reproducible test case, I think
this can be closed with no change.

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 13:17

Message:
Logged In: YES 
user_id=1057404

I've attempted to duplicate this with HEAD (05/Jun/04), and
I can't. 

HTTPSConnection uses a FakeSocket class which does reference
counting, meaning that the amount of sock.makefile() must
match sock.close() - this should be documented.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=913619&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 16:04:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 16:04:42 2004
Subject: [ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific
	addressing
Message-ID: <E1BiD2G-0005Pr-00@sc8-sf-web4.sourceforge.net>

Bugs item #764437, was opened at 2003-07-02 03:13
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Pergamenshchik (ppergame)
Assigned to: Nobody/Anonymous (nobody)
Summary: AF_UNIX sockets do not handle Linux-specific addressing

Initial Comment:
As described in unix(7) manpage, Linux allows for 
special &quot;kernel namespace&quot; AF_UNIX sockets defined. 
With such sockets, the first byte of the path is \x00, 
and the rest is the address. These sockets do not show 
up in the filesystem.
socketmodule.c:makesockaddr (as called by recvfrom) 
uses code like
PyString_FromString(a-&gt;sun_path)
to retrieve the address. This is incorrect -- on Linux, if 
the first byte of a-&gt;sun_path is null, the function should 
use PyString_FromStringAndSize to retrieve the full 108-
byte buffer.
I am not entirely sure that this is the only thing that 
needs to be fixed, but bind() and sendto() work with 
these sort of socket paths just fine.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 10:04

Message:
Logged In: YES 
user_id=11375

Should it use UNIX_PATH_MAX as the length of the string, or
1+ strlen(a->sun_path+1)?  (The leading null byte, plus the
following null-terminated string?)

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 15:16

Message:
Logged In: YES 
user_id=1057404

Also checks for "linux" to be defined, on Mondragon's
recommendation.

###
--- socketmodule.c      3 Jun 2004 09:24:42 -0000       1.291
+++ socketmodule.c      5 Jun 2004 18:17:51 -0000
@@ -942,6 +942,11 @@
        case AF_UNIX:
        {
                struct sockaddr_un *a = (struct sockaddr_un
*) addr;
+#if defined(UNIX_PATH_MAX) && defined(linux)
+               if (*a->sun_path == 0) {
+                       return
PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX);
+               }
+#endif /* UNIX_PATH_MAX && linux */
                return PyString_FromString(a->sun_path);
        }
 #endif /* AF_UNIX */
###

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 15:06

Message:
Logged In: YES 
user_id=1057404

The below patch adds the functionality if UNIX_PATH_MAX is
defined (in Linux it's in sys/un.h).

###
--- socketmodule.c      3 Jun 2004 09:24:42 -0000       1.291
+++ socketmodule.c      5 Jun 2004 18:08:47 -0000
@@ -942,6 +942,11 @@
        case AF_UNIX:
        {
                struct sockaddr_un *a = (struct sockaddr_un
*) addr;
+#if defined(UNIX_PATH_MAX)
+               if (*a->sun_path == 0) {
+                       return
PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX);
+               }
+#endif /* UNIX_PATH_MAX */
                return PyString_FromString(a->sun_path);
        }
 #endif /* AF_UNIX */
###

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-11-25 03:13

Message:
Logged In: YES 
user_id=29957

Eek. What a totally mental design decision on the part of
the Linux kernel developers. Is there a magic C preprocessor
symbol we can use to detect that this insanity is available? 

(FWIW, Perl also has problems with this:
http://www.alexhudson.com/code/abstract-sockets-and-perl
)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 16:09:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 16:10:12 2004
Subject: [ python-Bugs-925107 ] _Subfile.readline( ) in mailbox.py ignoring
	self.stop
Message-ID: <E1BiD7S-0005ZS-00@sc8-sf-web4.sourceforge.net>

Bugs item #925107, was opened at 2004-03-28 18:31
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925107&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sye van der Veen (syeberman)
>Assigned to: A.M. Kuchling (akuchling)
Summary: _Subfile.readline( ) in mailbox.py ignoring self.stop

Initial Comment:
I'm using Python 2.3.3 (on Windows, but that shouldn't 
matter) and I've noticed a problem with the internal 
_Subfile class in mailbox.py.  The readline method 
doesn't consider self.stop if the length argument is not 
None.  It has:
    if length is None:
        length = self.stop - self.pos
when really it should have something like:
    if length is None or length < 0:
        length = remaining
    elif length > remaining:
        length = remaining
which is what the read method does.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 10:09

Message:
Logged In: YES 
user_id=11375

Applied to CVS head; thanks, everyone!

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-06-05 11:43

Message:
Logged In: YES 
user_id=469548

This is correct. After fixing this bug the read() and
readline() methods are identical, except for one function
call, so my patch refactors their bodies into an internal
_read() method.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925107&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 16:22:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 16:22:44 2004
Subject: [ python-Bugs-982806 ] gdbm.open () fails with a single argument
Message-ID: <E1BiDJo-00066k-00@sc8-sf-web4.sourceforge.net>

Bugs item #982806, was opened at 2004-06-30 11:29
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982806&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Roy Smith (roysmith)
>Assigned to: A.M. Kuchling (akuchling)
Summary: gdbm.open () fails with a single argument

Initial Comment:
I am running:

Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin

Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc

release 1.8.3 of GNU dbm.

I've got a readable gdbm file:
-rw-r--r--  1 roy  roy  12288 30 Jun 09:52 status.gdbm

If I try to open it with no flag argument, it fails.  Explicitly 
specifying 'r' as a 2nd argument works.

>>> import gdbm
>>> gdbm.open ('status.gdbm')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
gdbm.error: Flag ' ' is not supported.
>>> gdbm.open ('status.gdbm', 'r')
<gdbm.gdbm object at 0x354050>

The on-line doc says the 2nd argument is optional:
http://www.python.org/doc/current/lib/module-gdbm.html

It's not clear if it's the code or the doc that wrong.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 10:22

Message:
Logged In: YES 
user_id=11375

The code is wrong.  The bug is fixed by patch #984672 by
James Lamanna, which has been applied to CVS and the 2.3 branch.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982806&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 16:37:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 16:37:36 2004
Subject: [ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific
	addressing
Message-ID: <E1BiDY7-00014F-00@sc8-sf-web2.sourceforge.net>

Bugs item #764437, was opened at 2003-07-02 00:13
Message generated for change (Comment added) made by ppergame
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Pergamenshchik (ppergame)
Assigned to: Nobody/Anonymous (nobody)
Summary: AF_UNIX sockets do not handle Linux-specific addressing

Initial Comment:
As described in unix(7) manpage, Linux allows for 
special &quot;kernel namespace&quot; AF_UNIX sockets defined. 
With such sockets, the first byte of the path is \x00, 
and the rest is the address. These sockets do not show 
up in the filesystem.
socketmodule.c:makesockaddr (as called by recvfrom) 
uses code like
PyString_FromString(a-&gt;sun_path)
to retrieve the address. This is incorrect -- on Linux, if 
the first byte of a-&gt;sun_path is null, the function should 
use PyString_FromStringAndSize to retrieve the full 108-
byte buffer.
I am not entirely sure that this is the only thing that 
needs to be fixed, but bind() and sendto() work with 
these sort of socket paths just fine.


----------------------------------------------------------------------

>Comment By: Pavel Pergamenshchik (ppergame)
Date: 2004-07-07 07:37

Message:
Logged In: YES 
user_id=595126

"""The socket?s address in this namespace is given by the
rest of the bytes in sun_path.  Note that names in the 
abstract namespace are not zero&#8208;terminated."""

The length would be UNIX_PATH_MAX in this case.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 07:04

Message:
Logged In: YES 
user_id=11375

Should it use UNIX_PATH_MAX as the length of the string, or
1+ strlen(a->sun_path+1)?  (The leading null byte, plus the
following null-terminated string?)

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 12:16

Message:
Logged In: YES 
user_id=1057404

Also checks for "linux" to be defined, on Mondragon's
recommendation.

###
--- socketmodule.c      3 Jun 2004 09:24:42 -0000       1.291
+++ socketmodule.c      5 Jun 2004 18:17:51 -0000
@@ -942,6 +942,11 @@
        case AF_UNIX:
        {
                struct sockaddr_un *a = (struct sockaddr_un
*) addr;
+#if defined(UNIX_PATH_MAX) && defined(linux)
+               if (*a->sun_path == 0) {
+                       return
PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX);
+               }
+#endif /* UNIX_PATH_MAX && linux */
                return PyString_FromString(a->sun_path);
        }
 #endif /* AF_UNIX */
###

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 12:06

Message:
Logged In: YES 
user_id=1057404

The below patch adds the functionality if UNIX_PATH_MAX is
defined (in Linux it's in sys/un.h).

###
--- socketmodule.c      3 Jun 2004 09:24:42 -0000       1.291
+++ socketmodule.c      5 Jun 2004 18:08:47 -0000
@@ -942,6 +942,11 @@
        case AF_UNIX:
        {
                struct sockaddr_un *a = (struct sockaddr_un
*) addr;
+#if defined(UNIX_PATH_MAX)
+               if (*a->sun_path == 0) {
+                       return
PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX);
+               }
+#endif /* UNIX_PATH_MAX */
                return PyString_FromString(a->sun_path);
        }
 #endif /* AF_UNIX */
###

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-11-25 00:13

Message:
Logged In: YES 
user_id=29957

Eek. What a totally mental design decision on the part of
the Linux kernel developers. Is there a magic C preprocessor
symbol we can use to detect that this insanity is available? 

(FWIW, Perl also has problems with this:
http://www.alexhudson.com/code/abstract-sockets-and-perl
)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 16:39:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 16:39:51 2004
Subject: [ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific
	addressing
Message-ID: <E1BiDaI-0005sP-00@sc8-sf-web3.sourceforge.net>

Bugs item #764437, was opened at 2003-07-02 07:13
Message generated for change (Comment added) made by insomnike
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Pergamenshchik (ppergame)
Assigned to: Nobody/Anonymous (nobody)
Summary: AF_UNIX sockets do not handle Linux-specific addressing

Initial Comment:
As described in unix(7) manpage, Linux allows for 
special &quot;kernel namespace&quot; AF_UNIX sockets defined. 
With such sockets, the first byte of the path is \x00, 
and the rest is the address. These sockets do not show 
up in the filesystem.
socketmodule.c:makesockaddr (as called by recvfrom) 
uses code like
PyString_FromString(a-&gt;sun_path)
to retrieve the address. This is incorrect -- on Linux, if 
the first byte of a-&gt;sun_path is null, the function should 
use PyString_FromStringAndSize to retrieve the full 108-
byte buffer.
I am not entirely sure that this is the only thing that 
needs to be fixed, but bind() and sendto() work with 
these sort of socket paths just fine.


----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-07-07 14:39

Message:
Logged In: YES 
user_id=1057404

It should use UNIX_PATH_MAX, but it should also check that
the length of the buffer supplied is correct, my bad.

----------------------------------------------------------------------

Comment By: Pavel Pergamenshchik (ppergame)
Date: 2004-07-07 14:37

Message:
Logged In: YES 
user_id=595126

"""The socket?s address in this namespace is given by the
rest of the bytes in sun_path.  Note that names in the 
abstract namespace are not zero&#8208;terminated."""

The length would be UNIX_PATH_MAX in this case.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-07 14:04

Message:
Logged In: YES 
user_id=11375

Should it use UNIX_PATH_MAX as the length of the string, or
1+ strlen(a->sun_path+1)?  (The leading null byte, plus the
following null-terminated string?)

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 19:16

Message:
Logged In: YES 
user_id=1057404

Also checks for "linux" to be defined, on Mondragon's
recommendation.

###
--- socketmodule.c      3 Jun 2004 09:24:42 -0000       1.291
+++ socketmodule.c      5 Jun 2004 18:17:51 -0000
@@ -942,6 +942,11 @@
        case AF_UNIX:
        {
                struct sockaddr_un *a = (struct sockaddr_un
*) addr;
+#if defined(UNIX_PATH_MAX) && defined(linux)
+               if (*a->sun_path == 0) {
+                       return
PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX);
+               }
+#endif /* UNIX_PATH_MAX && linux */
                return PyString_FromString(a->sun_path);
        }
 #endif /* AF_UNIX */
###

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 19:06

Message:
Logged In: YES 
user_id=1057404

The below patch adds the functionality if UNIX_PATH_MAX is
defined (in Linux it's in sys/un.h).

###
--- socketmodule.c      3 Jun 2004 09:24:42 -0000       1.291
+++ socketmodule.c      5 Jun 2004 18:08:47 -0000
@@ -942,6 +942,11 @@
        case AF_UNIX:
        {
                struct sockaddr_un *a = (struct sockaddr_un
*) addr;
+#if defined(UNIX_PATH_MAX)
+               if (*a->sun_path == 0) {
+                       return
PyString_FromStringAndSize(a->sun_path, UNIX_PATH_MAX);
+               }
+#endif /* UNIX_PATH_MAX */
                return PyString_FromString(a->sun_path);
        }
 #endif /* AF_UNIX */
###

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-11-25 08:13

Message:
Logged In: YES 
user_id=29957

Eek. What a totally mental design decision on the part of
the Linux kernel developers. Is there a magic C preprocessor
symbol we can use to detect that this insanity is available? 

(FWIW, Perl also has problems with this:
http://www.alexhudson.com/code/abstract-sockets-and-perl
)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 20:56:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 20:57:00 2004
Subject: [ python-Bugs-986795 ] New mandatory 2nd argument to
	site.addsitedir breaks compat
Message-ID: <E1BiHbE-0008RE-00@sc8-sf-web3.sourceforge.net>

Bugs item #986795, was opened at 2004-07-07 14:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: New mandatory 2nd argument to site.addsitedir breaks compat

Initial Comment:

  Old .pth files now raise a TypeError, which site.py
does not catch, which causes the import of site.py to fail.

  The new required parameter is also undocumented and,
on a cursory inspection, it is unclear to me what its
purpose is.

  This comes up because Debian allows for a version
neutral site-packages directory, /usr/lib/site-python/,
into which .pth files can be placed.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 23:10:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 23:10:47 2004
Subject: [ python-Bugs-986884 ] Configure bugs
Message-ID: <E1BiJgi-0005Nz-00@sc8-sf-web3.sourceforge.net>

Bugs item #986884, was opened at 2004-07-07 16:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986884&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dr. Tom (tomcortese)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure bugs

Initial Comment:
I encountered errors while trying to "configure" Python

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986884&group_id=5470
From noreply at sourceforge.net  Wed Jul  7 23:16:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul  7 23:16:16 2004
Subject: [ python-Bugs-986884 ] Configure bugs
Message-ID: <E1BiJm1-0005aT-00@sc8-sf-web3.sourceforge.net>

Bugs item #986884, was opened at 2004-07-07 16:10
Message generated for change (Comment added) made by tomcortese
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986884&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dr. Tom (tomcortese)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure bugs

Initial Comment:
I encountered errors while trying to "configure" Python

----------------------------------------------------------------------

>Comment By: Dr. Tom (tomcortese)
Date: 2004-07-07 16:16

Message:
Logged In: YES 
user_id=1079020

Forget it -- I can't attach the "config.log" file because
it's too big.  I don't really care, I was just trying to be
helpful and report a bug since a message saying "please
report this" showed up.  Have a nice day.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986884&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 02:29:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 02:29:42 2004
Subject: [ python-Bugs-986884 ] Configure bugs
Message-ID: <E1BiMnC-0008UM-00@sc8-sf-web2.sourceforge.net>

Bugs item #986884, was opened at 2004-07-07 14:10
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986884&group_id=5470

Category: Installation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Dr. Tom (tomcortese)
Assigned to: Nobody/Anonymous (nobody)
Summary: Configure bugs

Initial Comment:
I encountered errors while trying to "configure" Python

----------------------------------------------------------------------

Comment By: Dr. Tom (tomcortese)
Date: 2004-07-07 14:16

Message:
Logged In: YES 
user_id=1079020

Forget it -- I can't attach the "config.log" file because
it's too big.  I don't really care, I was just trying to be
helpful and report a bug since a message saying "please
report this" showed up.  Have a nice day.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986884&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 03:22:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 03:22:45 2004
Subject: [ python-Bugs-978308 ] Spurious errors taking bool of dead proxy
Message-ID: <E1BiNcW-0001Ts-00@sc8-sf-web2.sourceforge.net>

Bugs item #978308, was opened at 2004-06-23 11:48
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978308&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Chris King (colander_man)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Spurious errors taking bool of dead proxy

Initial Comment:
The following code will cause interesting errors:

from weakref import proxy
class a: pass
bool(proxy(a()))

Entered at a prompt, this will not cause a
ReferenceError until another statement is entered (and
will instead return True or 1) in both 2.3 and 2.2.

Run as a script, this will return True and cause a
fatal error in 2.3, but will return 1 and otherwise
exhibit no strange behaviour in 2.2 (even with
additional code accessing the return value).

The equivalent code written using ref rather than proxy
works as expected: bool(ref(a())()) returns False and
creates no errors.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:22

Message:
Logged In: YES 
user_id=33168

Checked in as: 
 * Objects/weakrefobject.c 1.18
 * Lib/test/test_weakref.py 1.42

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-25 22:46

Message:
Logged In: YES 
user_id=31435

Neal, FWIW, your fix is certainly correct.

----------------------------------------------------------------------

Comment By: Chris King (colander_man)
Date: 2004-06-25 09:47

Message:
Logged In: YES 
user_id=573252

The fix works (plus gave me an excuse to download the 2.4
snapshot). Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-06-24 22:57

Message:
Logged In: YES 
user_id=33168

attaching patch w/test

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-06-24 22:46

Message:
Logged In: YES 
user_id=33168

I believe the fix is in Objects/weakrefobject.c, line 358.
-1 should be returned, not 1 since an error occurred in
proxy_checkref().  I'll try to fix this.  If anyone wants to
steal it, feel free. :-)

Chris, if you could test the fix and report your results,
that would be great.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-23 16:13

Message:
Logged In: YES 
user_id=80475

Confirmed the script behavior in Py2.4.

The interactive prompt results are not consistent It
returned True the first time I ran it and raised a
ReferenceError in subsequent attempts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978308&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 03:29:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 03:29:20 2004
Subject: [ python-Bugs-985708 ] valgrind/memcheck alert: Python 2.3.4
	Objects/obmalloc.c
Message-ID: <E1BiNiv-0003Oc-00@sc8-sf-web1.sourceforge.net>

Bugs item #985708, was opened at 2004-07-06 00:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Neal Norwitz (nnorwitz)
Summary: valgrind/memcheck alert: Python 2.3.4 Objects/obmalloc.c

Initial Comment:
While trying to debug a segmentation fault I 
discovered to my great
surpise that Python 2.3.4 is not valgrind/memcheck 
clean. I observed
the same problem with three different versions of 
valgrind under
three different Linux versions:

    Python 2.3.4 (#1, May 29 2004, 02:54:59) 
    [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-
113)] on linux2
    valgrind-1.9.5

    Python 2.3.4 (#1, Jul  5 2004, 19:51:02) 
    [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on 
linux2
    valgrind-2.0.0

    Python 2.3.4 (#7, Jul  5 2004, 20:34:14) 
    [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-20)] 
on linux2
    valgrind-2.1.1

In the following I'll report results obtained under 
Red Hat Linux 3.2.3
with valgrind-2.1.1. The valgrind source code is 
available at this
location:

    http://valgrind.kde.org/

In my experience valgrind is a very reliable tool.

A am using Python-2.3.4.tgz as downloaded today 
from python.org.
After a fresh ./configure --prefix=/var/tmp/py234 
and make
executing the command

  valgrind --tool=memcheck ./python

produces this output:

==32282== Memcheck, a memory error detector for 
x86-linux.
==32282== Copyright (C) 2002-2004, and GNU 
GPL'd, by Julian Seward.
==32282== Using valgrind-2.1.1, a program 
supervision framework for x86-linux.
==32282== Copyright (C) 2000-2004, and GNU 
GPL'd, by Julian Seward.
==32282== For more details, rerun with: -v
==32282==
==32282== Conditional jump or move depends on 
uninitialised value(s)
==32282==    at 0x807AE88: PyObject_Free 
(obmalloc.c:711)
==32282==    by 0x8074B81: dictresize 
(dictobject.c:477)
==32282==    by 0x8074D61: PyDict_SetItem 
(dictobject.c:550)
==32282==    by 0x8082E01: 
PyString_InternInPlace (stringobject.c:4140)
==32282==

Plus a few hundred lines more that are not shown. 
These are lines
710 and 711 of obmalloc.c:

        pool = POOL_ADDR(p);
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 
{

ADDRESS_IN_RANGE is a complicated macro. 
Therefore I've inserted
the following print statemnt:

        pool = POOL_ADDR(p);
        if (pool->arenaindex == 0) printf("HELLO\n");
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 
{

With this valgrind still points to line 711, i.e. 
apparently the
problem is that pool->arenaindex is not initialized. 
However, the
output shows a large number of HELLO, suggesting 
that the uninitialized
value is 0 by coincidence.

Is this something to worry about? Or is this a rare 
case of valgrind
being mistaken? (It would be the first such case for 
me.)

Thanks,
        Ralf


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:29

Message:
Logged In: YES 
user_id=33168

Tim, was there anything else you wanted me to do for this? 
Thanks for proffredding the valgrind README.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-06 00:23

Message:
Logged In: YES 
user_id=31435

Neal, where did you document the 
Py_USING_MEMORY_DEBUGGER gimmick?  I didn't find 
anything about it NEWS, or in Misc/SpecialBuilds.txt.

Ralf, yes, ADDRESS_IN_RANGE reads uninitialized memory.  
This is an intentional extreme speed hack, and won't change.  
Neal checked things in to current CVS Python to support 
telling valgrind to shut up about it, but I don't know how to 
use that ... ah, OK, in current CVS Python, read 
Misc/README.valgrind.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 03:30:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 03:30:56 2004
Subject: [ python-Bugs-986795 ] New mandatory 2nd argument to
	site.addsitedir breaks compat
Message-ID: <E1BiNkS-0001g2-00@sc8-sf-web2.sourceforge.net>

Bugs item #986795, was opened at 2004-07-07 14:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
>Assigned to: Brett Cannon (bcannon)
Summary: New mandatory 2nd argument to site.addsitedir breaks compat

Initial Comment:

  Old .pth files now raise a TypeError, which site.py
does not catch, which causes the import of site.py to fail.

  The new required parameter is also undocumented and,
on a cursory inspection, it is unclear to me what its
purpose is.

  This comes up because Debian allows for a version
neutral site-packages directory, /usr/lib/site-python/,
into which .pth files can be placed.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:30

Message:
Logged In: YES 
user_id=33168

Brett, did this happen from your changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 03:32:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 03:32:56 2004
Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4
	under cygwin
Message-ID: <E1BiNmL-00066r-00@sc8-sf-web4.sourceforge.net>

Bugs item #985154, was opened at 2004-07-04 22:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
>Assigned to: Jason Tishler (jlt63)
Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin

Initial Comment:
Building 2.3.4 from the tarball, 
#define HAVE_FDATASYNC 1
appears in the pyconfig.h file, and
the build of 'posixmodule' fails with
undefined symbol _fdatasync

Workaround is to delete the line
and proceed, of course, but I've
never seen this before when building
under cygwin.

There is no 'fdatasync' mentioned
in any /usr/include/*.h or /usr/local/include/*.h

The cygwin installation is kind of a mongrel
(4 or 5 upgrades since install, some selective)
This is the ID string from the built python:

Python 2.3.4 (#2, Jul  4 2004, 22:10:22)
[GCC 3.3.1 (cygming special)] on cygwin

Let me know of any details of the cygwin install
which might be useful.




----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:32

Message:
Logged In: YES 
user_id=33168

Jason, do you know what the deal is with cygwin?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-07 07:12

Message:
Logged In: YES 
user_id=6656

Well, I guess that's an arguable bug in cygwin, but if you want to 
supply a patch that modifies configure to do the linking test too, 
I'll at least think about applying it :-)

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2004-07-05 21:58

Message:
Logged In: YES 
user_id=292741

looked into config.log and 'configure' itself.. the compile
for fdatasync succeeded, but the script does not attempt
to link it.  gcc -E  led me to the following 
chunk of /usr/include/sys/unistd.h:

(not inside any #ifdefs, as far as I can tell)

int     _EXFUN(fdatasync, (int __fd));


So it's declared in the header, but it's not in the
library. This symbol is defined in libc.a on a RH8.0
system, I can't find it anywhere on the cygwin system.
 




----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-05 09:40

Message:
Logged In: YES 
user_id=6656

That's odd.  Why does configure think you have fdatasync?  Maybe 
config.log will help...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 03:34:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 03:34:07 2004
Subject: [ python-Bugs-985708 ] valgrind/memcheck alert: Python 2.3.4
	Objects/obmalloc.c
Message-ID: <E1BiNnX-0005kq-00@sc8-sf-web3.sourceforge.net>

Bugs item #985708, was opened at 2004-07-06 00:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Neal Norwitz (nnorwitz)
Summary: valgrind/memcheck alert: Python 2.3.4 Objects/obmalloc.c

Initial Comment:
While trying to debug a segmentation fault I 
discovered to my great
surpise that Python 2.3.4 is not valgrind/memcheck 
clean. I observed
the same problem with three different versions of 
valgrind under
three different Linux versions:

    Python 2.3.4 (#1, May 29 2004, 02:54:59) 
    [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-
113)] on linux2
    valgrind-1.9.5

    Python 2.3.4 (#1, Jul  5 2004, 19:51:02) 
    [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on 
linux2
    valgrind-2.0.0

    Python 2.3.4 (#7, Jul  5 2004, 20:34:14) 
    [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-20)] 
on linux2
    valgrind-2.1.1

In the following I'll report results obtained under 
Red Hat Linux 3.2.3
with valgrind-2.1.1. The valgrind source code is 
available at this
location:

    http://valgrind.kde.org/

In my experience valgrind is a very reliable tool.

A am using Python-2.3.4.tgz as downloaded today 
from python.org.
After a fresh ./configure --prefix=/var/tmp/py234 
and make
executing the command

  valgrind --tool=memcheck ./python

produces this output:

==32282== Memcheck, a memory error detector for 
x86-linux.
==32282== Copyright (C) 2002-2004, and GNU 
GPL'd, by Julian Seward.
==32282== Using valgrind-2.1.1, a program 
supervision framework for x86-linux.
==32282== Copyright (C) 2000-2004, and GNU 
GPL'd, by Julian Seward.
==32282== For more details, rerun with: -v
==32282==
==32282== Conditional jump or move depends on 
uninitialised value(s)
==32282==    at 0x807AE88: PyObject_Free 
(obmalloc.c:711)
==32282==    by 0x8074B81: dictresize 
(dictobject.c:477)
==32282==    by 0x8074D61: PyDict_SetItem 
(dictobject.c:550)
==32282==    by 0x8082E01: 
PyString_InternInPlace (stringobject.c:4140)
==32282==

Plus a few hundred lines more that are not shown. 
These are lines
710 and 711 of obmalloc.c:

        pool = POOL_ADDR(p);
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 
{

ADDRESS_IN_RANGE is a complicated macro. 
Therefore I've inserted
the following print statemnt:

        pool = POOL_ADDR(p);
        if (pool->arenaindex == 0) printf("HELLO\n");
        if (ADDRESS_IN_RANGE(p, pool->arenaindex)) 
{

With this valgrind still points to line 711, i.e. 
apparently the
problem is that pool->arenaindex is not initialized. 
However, the
output shows a large number of HELLO, suggesting 
that the uninitialized
value is 0 by coincidence.

Is this something to worry about? Or is this a rare 
case of valgrind
being mistaken? (It would be the first such case for 
me.)

Thanks,
        Ralf


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-07 21:34

Message:
Logged In: YES 
user_id=31435

No, I meant to close it as Fixed -- and did that now.  I 
assume it wasn't backported to the 2.3 line (and that's fine 
by me).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:29

Message:
Logged In: YES 
user_id=33168

Tim, was there anything else you wanted me to do for this? 
Thanks for proffredding the valgrind README.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-06 00:23

Message:
Logged In: YES 
user_id=31435

Neal, where did you document the 
Py_USING_MEMORY_DEBUGGER gimmick?  I didn't find 
anything about it NEWS, or in Misc/SpecialBuilds.txt.

Ralf, yes, ADDRESS_IN_RANGE reads uninitialized memory.  
This is an intentional extreme speed hack, and won't change.  
Neal checked things in to current CVS Python to support 
telling valgrind to shut up about it, but I don't know how to 
use that ... ah, OK, in current CVS Python, read 
Misc/README.valgrind.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985708&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 03:38:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 03:38:27 2004
Subject: [ python-Bugs-982049 ] Relative Path causing crash in
	RotatingFileHandler
Message-ID: <E1BiNrh-0006HE-00@sc8-sf-web4.sourceforge.net>

Bugs item #982049, was opened at 2004-06-29 12:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982049&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David London (groodude)
>Assigned to: Vinay Sajip (vsajip)
Summary: Relative Path causing crash in RotatingFileHandler

Initial Comment:
When using the RotatingFileHandler class, if the
working directory is changed after the logging is setup
and a relative file name has been used to set up the
handler, python will crash when a rollover is attempted.
In my application, I set up the logger first (using a
config file) and then I start reading the config file
for the application. This is done so that I can log any
errors found within the application config file.
However, if a certain option is set, then the
application has to change the working directory. But
since the file name that I have included is relative,
when the logger attempts to rollover the file, it
crashes since the log file can no longer be found
within the current directory. 

Is this the desired behaviour (i.e. does the logger
expect to have absolute paths)? If so, this would be a
good thing to add to the documentation (along with an
example of a RotatingFileHandler configuration in
section 6.28.7.2).
It seems to make more sense that when a file name is
passed in, the absolute path be stored.

Even if this is the desired behaviour, I think that an
example of the RotatingFileConfig handler should be
included in the configuration section, complete with
values for the maxbytes and the number of back ups.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:38

Message:
Logged In: YES 
user_id=33168

Vinay, do you have any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982049&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 03:39:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 03:39:32 2004
Subject: [ python-Bugs-979252 ] Trap OSError when calling
	RotatingFileHandler.doRollover
Message-ID: <E1BiNsm-0003eK-00@sc8-sf-web1.sourceforge.net>

Bugs item #979252, was opened at 2004-06-24 16:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979252&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard T. Hewitt (hewittr)
>Assigned to: Vinay Sajip (vsajip)
Summary: Trap OSError when calling RotatingFileHandler.doRollover

Initial Comment:
I use the RotatingFileHandler in most of my scripts.  The 
script will crash if the RotatingFileHandler encounters a 
locked log file.

I would like to see something like:

    def emit(self, record):
        """
        Emit a record.

        Output the record to the file, catering for rollover 
as described
        in __init__().
        """
        if self.maxBytes > 0:                   # are we rolling 
over?
            msg = "%s\n" % self.format(record)
            self.stream.seek(0, 2)  #due to non-posix-
compliant Windows feature
            if self.stream.tell() + len(msg) >= self.maxBytes:
                try:
                    self.doRollover()
                except Exception:
                    logging.FileHandler.emit(self, 'Failed to 
doRollover.')
        logging.FileHandler.emit(self, record)

My version of Python (2.3.2) had the wrong docstring as 
well, referring to a non-existent setRollover.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:39

Message:
Logged In: YES 
user_id=33168

Vinay, any ideas?

----------------------------------------------------------------------

Comment By: David London (groodude)
Date: 2004-06-29 17:34

Message:
Logged In: YES 
user_id=975020

Richard,
I have also had the "joy" of encountering this bug (on a
windows 2000 machine), although I am still baffled at what
could be locking the file.

Our testing did not reveal this bug and now we have some
code in a production environment that is causing me grief,
so I had to come up with a solution quickly and I though
that I might share it with you (and others).

I don't believe that your solution will solve the problem.
In doRollover the stream is closed and then the files are
manipulated. Since this is where the errors will occur
simply calling the emit method again will only cause more
exceptions to be generated. Also, since the stream is never
opened again, you would never get any log messages until you
restarted.  Sorry, after looking a bit more it seems like
you will get tracebacks printed to the standard error (where
ever you have designated that to be).

What I am doing is replacing my version of doRollover with
this version;
    def doRollover(self):
        """
        Do a rollover, as described in __init__().
        """

        self.stream.close()
        openMode = "w"
        if self.backupCount > 0:
            try:
                for i in range(self.backupCount - 1, 0, -1):
                    sfn = "%s.%d" % (self.baseFilename, i)
                    dfn = "%s.%d" % (self.baseFilename, i + 1)
                    if os.path.exists(sfn):
                        #print "%s -> %s" % (sfn, dfn)
                        if os.path.exists(dfn):
                            os.remove(dfn)
                        os.rename(sfn, dfn)
                dfn = self.baseFilename + ".1"
                if os.path.exists(dfn):
                    os.remove(dfn)
                os.rename(self.baseFilename, dfn)
                #print "%s -> %s" % (self.baseFilename, dfn)
            except:
                ## There was some problem with the file
manipulationg above.
                ## If someone has some time, maybe they can
figure out what errors
                ## can occur and the best way to deal with
all of them.
                ## For my purposes, I'm just going to try
and re-open
                ## the original file.
                openMode = "a"
        try:
            self.stream = open(self.baseFilename, openMode)
        except:
            ## There was some problem opening the log file.
            ## Again, someone with more time can look into
all of the possible
            ## errors and figure out how best to handle them.
            ## I'm just going to try and open a 'problem'
log file.
            ## The idea is that this file will exist long
enough for the problems
            ## above to go away and the next time that we
attempt to rollover
            ## it will work as we expect.
            gotError = True
            count = 1
            while gotError:
                try:
                    problemFilename = self.baseFilename +
".pblm." + str(count)
                    self.stream = open(problemFilename,
openMode)
                    gotError = False
                except:
                    count += 1

If my logic works out, this should always open a file for
logging so the logging should never crash and no log
messages will be lost. 
Hopefully you will find this helpful.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979252&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 05:56:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 06:00:09 2004
Subject: [ python-Bugs-952737 ] Funny keywords in library index
Message-ID: <E1BiQ1n-0005jZ-00@sc8-sf-web2.sourceforge.net>

Bugs item #952737, was opened at 2004-05-12 14:01
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=952737&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Funny keywords in library index

Initial Comment:
The library index contains the keywords \UNIX and \POSIX.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-07 23:56

Message:
Logged In: YES 
user_id=3066

Fixed in a somewhat hackish way in Doc/tools/buildindex.py 1.15.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=952737&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 11:43:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 11:43:57 2004
Subject: [ python-Bugs-982049 ] Relative Path causing crash in
	RotatingFileHandler
Message-ID: <E1BiVRY-00053T-00@sc8-sf-web4.sourceforge.net>

Bugs item #982049, was opened at 2004-06-29 16:34
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982049&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David London (groodude)
Assigned to: Vinay Sajip (vsajip)
Summary: Relative Path causing crash in RotatingFileHandler

Initial Comment:
When using the RotatingFileHandler class, if the
working directory is changed after the logging is setup
and a relative file name has been used to set up the
handler, python will crash when a rollover is attempted.
In my application, I set up the logger first (using a
config file) and then I start reading the config file
for the application. This is done so that I can log any
errors found within the application config file.
However, if a certain option is set, then the
application has to change the working directory. But
since the file name that I have included is relative,
when the logger attempts to rollover the file, it
crashes since the log file can no longer be found
within the current directory. 

Is this the desired behaviour (i.e. does the logger
expect to have absolute paths)? If so, this would be a
good thing to add to the documentation (along with an
example of a RotatingFileHandler configuration in
section 6.28.7.2).
It seems to make more sense that when a file name is
passed in, the absolute path be stored.

Even if this is the desired behaviour, I think that an
example of the RotatingFileConfig handler should be
included in the configuration section, complete with
values for the maxbytes and the number of back ups.


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-08 09:43

Message:
Logged In: YES 
user_id=308438

No, it's not the desired behaviour. I will put a fix into CVS: in 
the package's __init__.py, change the line in 
FileHandler.__init__ to

        self.baseFilename = os.path.abspath(filename)

and the RotatingFileHandler will then use absolute paths for 
its log files.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-08 01:38

Message:
Logged In: YES 
user_id=33168

Vinay, do you have any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982049&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 12:00:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 12:00:34 2004
Subject: [ python-Bugs-979252 ] Trap OSError when calling
	RotatingFileHandler.doRollover
Message-ID: <E1BiVhc-0004l5-00@sc8-sf-web3.sourceforge.net>

Bugs item #979252, was opened at 2004-06-24 20:43
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979252&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard T. Hewitt (hewittr)
Assigned to: Vinay Sajip (vsajip)
Summary: Trap OSError when calling RotatingFileHandler.doRollover

Initial Comment:
I use the RotatingFileHandler in most of my scripts.  The 
script will crash if the RotatingFileHandler encounters a 
locked log file.

I would like to see something like:

    def emit(self, record):
        """
        Emit a record.

        Output the record to the file, catering for rollover 
as described
        in __init__().
        """
        if self.maxBytes > 0:                   # are we rolling 
over?
            msg = "%s\n" % self.format(record)
            self.stream.seek(0, 2)  #due to non-posix-
compliant Windows feature
            if self.stream.tell() + len(msg) >= self.maxBytes:
                try:
                    self.doRollover()
                except Exception:
                    logging.FileHandler.emit(self, 'Failed to 
doRollover.')
        logging.FileHandler.emit(self, record)

My version of Python (2.3.2) had the wrong docstring as 
well, referring to a non-existent setRollover.

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-08 10:00

Message:
Logged In: YES 
user_id=308438

Easy things first - the docstring has been corrected in a later 
release.

I believe that when an exception occurs during logging, one 
of two things should happen: if raiseExceptions is 0, then the 
exception should be swallowed silently (typically, for 
production environments). This is because logging-related 
errors should not be treated in the same way as application 
errors (it's a pseudo-philosophical point, and not everyone will 
agree). If raiseExceptions is 1 (development environments), 
the exception should be raised.

I think the solution given by David London (groodude) may be 
fine for specific applications, but not sufficiently general to 
be adopted as is. I will check in changes to CVS which will 
call handleError() when an exception occurs during emit(). It's 
best to derive from RotatingFileHandler and put any specific 
handling you want into an overridden handleError().

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-08 01:39

Message:
Logged In: YES 
user_id=33168

Vinay, any ideas?

----------------------------------------------------------------------

Comment By: David London (groodude)
Date: 2004-06-29 21:34

Message:
Logged In: YES 
user_id=975020

Richard,
I have also had the "joy" of encountering this bug (on a
windows 2000 machine), although I am still baffled at what
could be locking the file.

Our testing did not reveal this bug and now we have some
code in a production environment that is causing me grief,
so I had to come up with a solution quickly and I though
that I might share it with you (and others).

I don't believe that your solution will solve the problem.
In doRollover the stream is closed and then the files are
manipulated. Since this is where the errors will occur
simply calling the emit method again will only cause more
exceptions to be generated. Also, since the stream is never
opened again, you would never get any log messages until you
restarted.  Sorry, after looking a bit more it seems like
you will get tracebacks printed to the standard error (where
ever you have designated that to be).

What I am doing is replacing my version of doRollover with
this version;
    def doRollover(self):
        """
        Do a rollover, as described in __init__().
        """

        self.stream.close()
        openMode = "w"
        if self.backupCount > 0:
            try:
                for i in range(self.backupCount - 1, 0, -1):
                    sfn = "%s.%d" % (self.baseFilename, i)
                    dfn = "%s.%d" % (self.baseFilename, i + 1)
                    if os.path.exists(sfn):
                        #print "%s -> %s" % (sfn, dfn)
                        if os.path.exists(dfn):
                            os.remove(dfn)
                        os.rename(sfn, dfn)
                dfn = self.baseFilename + ".1"
                if os.path.exists(dfn):
                    os.remove(dfn)
                os.rename(self.baseFilename, dfn)
                #print "%s -> %s" % (self.baseFilename, dfn)
            except:
                ## There was some problem with the file
manipulationg above.
                ## If someone has some time, maybe they can
figure out what errors
                ## can occur and the best way to deal with
all of them.
                ## For my purposes, I'm just going to try
and re-open
                ## the original file.
                openMode = "a"
        try:
            self.stream = open(self.baseFilename, openMode)
        except:
            ## There was some problem opening the log file.
            ## Again, someone with more time can look into
all of the possible
            ## errors and figure out how best to handle them.
            ## I'm just going to try and open a 'problem'
log file.
            ## The idea is that this file will exist long
enough for the problems
            ## above to go away and the next time that we
attempt to rollover
            ## it will work as we expect.
            gotError = True
            count = 1
            while gotError:
                try:
                    problemFilename = self.baseFilename +
".pblm." + str(count)
                    self.stream = open(problemFilename,
openMode)
                    gotError = False
                except:
                    count += 1

If my logic works out, this should always open a file for
logging so the logging should never crash and no log
messages will be lost. 
Hopefully you will find this helpful.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979252&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 12:20:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 12:20:48 2004
Subject: [ python-Bugs-987166 ] TimedRotatingFileHandler problems
Message-ID: <E1BiW1F-0002Nj-00@sc8-sf-web2.sourceforge.net>

Bugs item #987166, was opened at 2004-07-08 12:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987166&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Nobody/Anonymous (nobody)
Summary: TimedRotatingFileHandler problems

Initial Comment:
2 problems in the new TimedRotatingFileHandler class:
- "print" statements that where used for debugging were
not removed.
- the code that "find the oldest log file and delete
it" assumes that glob.glob returns files in
alphabetical order. This is not true for all
filesystems (FAT and Novell at least don't sort their
directories), so the file deleted may be a recent one...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987166&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 13:10:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 13:10:57 2004
Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4
	under cygwin
Message-ID: <E1BiWne-00046k-00@sc8-sf-web2.sourceforge.net>

Bugs item #985154, was opened at 2004-07-04 18:38
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Jason Tishler (jlt63)
Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin

Initial Comment:
Building 2.3.4 from the tarball, 
#define HAVE_FDATASYNC 1
appears in the pyconfig.h file, and
the build of 'posixmodule' fails with
undefined symbol _fdatasync

Workaround is to delete the line
and proceed, of course, but I've
never seen this before when building
under cygwin.

There is no 'fdatasync' mentioned
in any /usr/include/*.h or /usr/local/include/*.h

The cygwin installation is kind of a mongrel
(4 or 5 upgrades since install, some selective)
This is the ID string from the built python:

Python 2.3.4 (#2, Jul  4 2004, 22:10:22)
[GCC 3.3.1 (cygming special)] on cygwin

Let me know of any details of the cygwin install
which might be useful.




----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2004-07-08 03:10

Message:
Logged In: YES 
user_id=86216

nnorwitz> Jason, do you know what the deal is with cygwin?

AFAICT, Greg's Cygwin setup seems suspect.  Actually, he
alluded to this fact in the following:

gregsmith> The cygwin installation is kind of a mongrel...

On my Cygwin setup (i.e., 1.5.10-3), I have the following:

/usr/include/sys/unistd.h:
    #ifndef __CYGWIN__
    int     _EXFUN(fdatasync, (int __fd));
    #endif

pyconfig.h:

    /* Define if you have the 'fdatasync' function. */
    /* #undef HAVE_FDATASYNC */

Additionally, the official Cygwin Python package built
cleanly.

Greg, what version of Cygwin are you using? If not 1.5.10-3,
then please upgrade and try again. If so, then your setup
seems to be corrupted. Try reinstalling. Does it work any
better now?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 17:32

Message:
Logged In: YES 
user_id=33168

Jason, do you know what the deal is with cygwin?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-07 03:12

Message:
Logged In: YES 
user_id=6656

Well, I guess that's an arguable bug in cygwin, but if you want to 
supply a patch that modifies configure to do the linking test too, 
I'll at least think about applying it :-)

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2004-07-05 17:58

Message:
Logged In: YES 
user_id=292741

looked into config.log and 'configure' itself.. the compile
for fdatasync succeeded, but the script does not attempt
to link it.  gcc -E  led me to the following 
chunk of /usr/include/sys/unistd.h:

(not inside any #ifdefs, as far as I can tell)

int     _EXFUN(fdatasync, (int __fd));


So it's declared in the header, but it's not in the
library. This symbol is defined in libc.a on a RH8.0
system, I can't find it anywhere on the cygwin system.
 




----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-05 05:40

Message:
Logged In: YES 
user_id=6656

That's odd.  Why does configure think you have fdatasync?  Maybe 
config.log will help...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 15:28:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 15:28:47 2004
Subject: [ python-Bugs-987287 ] Python 2.4a1,
	interpreter hanging on Keyboard Interrupt
Message-ID: <E1BiYx9-000169-00@sc8-sf-web2.sourceforge.net>

Bugs item #987287, was opened at 2004-07-08 15:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4a1, interpreter hanging on Keyboard Interrupt

Initial Comment:
This is how I hang the intepreter in 2.4a1:

python2.4
...
>>> import readline
>>> import rlcompleter
>>> import thread
>>> thread.start_new_thread((lambda: 1), ())
>>> ^C
(Python Interpreter hangs)

The ^C of course is the Keyboard interrupt. It doesn't
matter if I write something on the command line and
then press ^C, the interpreter still hangs.

This is new. The interpreter won't hang under Python
2.3.4; it won't hang under Python 2.4a0.

It specifically changed sometime thursday and friday
(Python 2.4a0 -> Python 2.4a1). This might indicate the
change logged as: "Non-main threads no longer have all
signals masked." or the change logged as: "A different
interface to readline is used." is to blame.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 15:29:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 15:29:21 2004
Subject: [ python-Bugs-987287 ] Python 2.4a1,
	interpreter hanging on Keyboard Interrupt
Message-ID: <E1BiYxc-0005Gf-00@sc8-sf-web4.sourceforge.net>

Bugs item #987287, was opened at 2004-07-08 15:28
Message generated for change (Settings changed) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
>Assigned to: Michael Hudson (mwh)
Summary: Python 2.4a1, interpreter hanging on Keyboard Interrupt

Initial Comment:
This is how I hang the intepreter in 2.4a1:

python2.4
...
>>> import readline
>>> import rlcompleter
>>> import thread
>>> thread.start_new_thread((lambda: 1), ())
>>> ^C
(Python Interpreter hangs)

The ^C of course is the Keyboard interrupt. It doesn't
matter if I write something on the command line and
then press ^C, the interpreter still hangs.

This is new. The interpreter won't hang under Python
2.3.4; it won't hang under Python 2.4a0.

It specifically changed sometime thursday and friday
(Python 2.4a0 -> Python 2.4a1). This might indicate the
change logged as: "Non-main threads no longer have all
signals masked." or the change logged as: "A different
interface to readline is used." is to blame.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 15:41:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 15:41:24 2004
Subject: [ python-Bugs-987287 ] Python 2.4a1,
	interpreter hanging on Keyboard Interrupt
Message-ID: <E1BiZ9F-0003Ey-00@sc8-sf-web1.sourceforge.net>

Bugs item #987287, was opened at 2004-07-08 15:28
Message generated for change (Comment added) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Michael Hudson (mwh)
Summary: Python 2.4a1, interpreter hanging on Keyboard Interrupt

Initial Comment:
This is how I hang the intepreter in 2.4a1:

python2.4
...
>>> import readline
>>> import rlcompleter
>>> import thread
>>> thread.start_new_thread((lambda: 1), ())
>>> ^C
(Python Interpreter hangs)

The ^C of course is the Keyboard interrupt. It doesn't
matter if I write something on the command line and
then press ^C, the interpreter still hangs.

This is new. The interpreter won't hang under Python
2.3.4; it won't hang under Python 2.4a0.

It specifically changed sometime thursday and friday
(Python 2.4a0 -> Python 2.4a1). This might indicate the
change logged as: "Non-main threads no longer have all
signals masked." or the change logged as: "A different
interface to readline is used." is to blame.

----------------------------------------------------------------------

>Comment By: Simon Percivall (percivall)
Date: 2004-07-08 15:41

Message:
Logged In: YES 
user_id=329382

I forgot to say: I'm using Mac OS X 10.3, fink project readline.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 15:51:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 15:51:27 2004
Subject: [ python-Bugs-987287 ] Python 2.4a1,
	interpreter hanging on Keyboard Interrupt
Message-ID: <E1BiZJ2-00068u-00@sc8-sf-web4.sourceforge.net>

Bugs item #987287, was opened at 2004-07-08 14:28
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Michael Hudson (mwh)
Summary: Python 2.4a1, interpreter hanging on Keyboard Interrupt

Initial Comment:
This is how I hang the intepreter in 2.4a1:

python2.4
...
>>> import readline
>>> import rlcompleter
>>> import thread
>>> thread.start_new_thread((lambda: 1), ())
>>> ^C
(Python Interpreter hangs)

The ^C of course is the Keyboard interrupt. It doesn't
matter if I write something on the command line and
then press ^C, the interpreter still hangs.

This is new. The interpreter won't hang under Python
2.3.4; it won't hang under Python 2.4a0.

It specifically changed sometime thursday and friday
(Python 2.4a0 -> Python 2.4a1). This might indicate the
change logged as: "Non-main threads no longer have all
signals masked." or the change logged as: "A different
interface to readline is used." is to blame.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-08 14:51

Message:
Logged In: YES 
user_id=6656

Confirmed on linux/x86.

Hmm, I see the problem (my lack of understanding of the
Python thread API).  I have a fix (just running make test)
but I don't know what the score is wrt 2.4a1...

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-07-08 14:41

Message:
Logged In: YES 
user_id=329382

I forgot to say: I'm using Mac OS X 10.3, fink project readline.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 15:59:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 16:00:10 2004
Subject: [ python-Bugs-987287 ] Python 2.4a1,
	interpreter hanging on Keyboard Interrupt
Message-ID: <E1BiZRN-00049n-00@sc8-sf-web1.sourceforge.net>

Bugs item #987287, was opened at 2004-07-08 23:28
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Michael Hudson (mwh)
Summary: Python 2.4a1, interpreter hanging on Keyboard Interrupt

Initial Comment:
This is how I hang the intepreter in 2.4a1:

python2.4
...
>>> import readline
>>> import rlcompleter
>>> import thread
>>> thread.start_new_thread((lambda: 1), ())
>>> ^C
(Python Interpreter hangs)

The ^C of course is the Keyboard interrupt. It doesn't
matter if I write something on the command line and
then press ^C, the interpreter still hangs.

This is new. The interpreter won't hang under Python
2.3.4; it won't hang under Python 2.4a0.

It specifically changed sometime thursday and friday
(Python 2.4a0 -> Python 2.4a1). This might indicate the
change logged as: "Non-main threads no longer have all
signals masked." or the change logged as: "A different
interface to readline is used." is to blame.

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-08 23:59

Message:
Logged In: YES 
user_id=29957

Well, 2.4a1 is already out the door (well, almost), so any
fix will have to go into 2.4a2. Feel free to post a patch
here as well, though, so we can point the hordes of testers
who discover this bug at this patch.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-08 23:51

Message:
Logged In: YES 
user_id=6656

Confirmed on linux/x86.

Hmm, I see the problem (my lack of understanding of the
Python thread API).  I have a fix (just running make test)
but I don't know what the score is wrt 2.4a1...

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-07-08 23:41

Message:
Logged In: YES 
user_id=329382

I forgot to say: I'm using Mac OS X 10.3, fink project readline.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 17:30:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 17:31:02 2004
Subject: [ python-Bugs-987287 ] Python 2.4a1,
	interpreter hanging on Keyboard Interrupt
Message-ID: <E1BiarH-0001ej-00@sc8-sf-web4.sourceforge.net>

Bugs item #987287, was opened at 2004-07-08 14:28
Message generated for change (Settings changed) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470

Category: Threads
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Michael Hudson (mwh)
Summary: Python 2.4a1, interpreter hanging on Keyboard Interrupt

Initial Comment:
This is how I hang the intepreter in 2.4a1:

python2.4
...
>>> import readline
>>> import rlcompleter
>>> import thread
>>> thread.start_new_thread((lambda: 1), ())
>>> ^C
(Python Interpreter hangs)

The ^C of course is the Keyboard interrupt. It doesn't
matter if I write something on the command line and
then press ^C, the interpreter still hangs.

This is new. The interpreter won't hang under Python
2.3.4; it won't hang under Python 2.4a0.

It specifically changed sometime thursday and friday
(Python 2.4a0 -> Python 2.4a1). This might indicate the
change logged as: "Non-main threads no longer have all
signals masked." or the change logged as: "A different
interface to readline is used." is to blame.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-08 16:30

Message:
Logged In: YES 
user_id=6656

Here's the patch that just got checked in as 

Modules/readline.c revision 2.72
Parser/myreadline.c revision 2.33

Should go onto /2.4/bugs.html when that exists...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-07-08 14:59

Message:
Logged In: YES 
user_id=29957

Well, 2.4a1 is already out the door (well, almost), so any
fix will have to go into 2.4a2. Feel free to post a patch
here as well, though, so we can point the hordes of testers
who discover this bug at this patch.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-08 14:51

Message:
Logged In: YES 
user_id=6656

Confirmed on linux/x86.

Hmm, I see the problem (my lack of understanding of the
Python thread API).  I have a fix (just running make test)
but I don't know what the score is wrt 2.4a1...

----------------------------------------------------------------------

Comment By: Simon Percivall (percivall)
Date: 2004-07-08 14:41

Message:
Logged In: YES 
user_id=329382

I forgot to say: I'm using Mac OS X 10.3, fink project readline.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987287&group_id=5470
From noreply at sourceforge.net  Thu Jul  8 20:52:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul  8 20:52:50 2004
Subject: [ python-Bugs-987486 ] Typo in cgi doc
Message-ID: <E1Bie0m-0000p0-00@sc8-sf-web4.sourceforge.net>

Bugs item #987486, was opened at 2004-07-08 11:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987486&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Cory Dodt (corydodt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in cgi doc

Initial Comment:
Referring to this doc page:

http://www.python.org/doc/current/lib/node404.html

"""
getfirst(  	name[, default])
    Thin method always returns only one value
associated with form field name. 
"""

"Thin" should be "This".

Submitted by Glyph Lefkowitz, who does not like to use
the sf bug tracker.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987486&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 11:37:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 11:37:52 2004
Subject: [ python-Bugs-987835 ] pep 311 functions missing documentation
Message-ID: <E1BirpE-0000By-00@sc8-sf-web2.sourceforge.net>

Bugs item #987835, was opened at 2004-07-09 12:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987835&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: pep 311 functions missing documentation

Initial Comment:
the c api functions from pep 311 is missing documentation

PyGILState_Ensure

PyGILState_Release

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987835&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 13:03:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 13:03:09 2004
Subject: [ python-Bugs-987870 ] Windows installer for 2.4a1 shows
	non-standard version
Message-ID: <E1Bit9k-0004Fz-00@sc8-sf-web4.sourceforge.net>

Bugs item #987870, was opened at 2004-07-09 12:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Thomas Heller (theller)
Summary: Windows installer for 2.4a1 shows non-standard version

Initial Comment:
The Windows installer (MSI) for Python 2.4a1 displays 
the Python version as 2.4.0.12607. This is not the 
standard version format, which should show as 2.4a0.

While this is mainly a cosmetic issue, it will make it 
difficult to verify that the version installed matches the 
latest released alpha/beta. (It's not clear whether the 
final number - the 12607 - will be dropped with the 
release, so this may not be an issue for 2.4 final).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 13:17:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 13:17:49 2004
Subject: [ python-Bugs-870382 ] Mingw needs to use the same MSVC runtime as
	Python
Message-ID: <E1BitNp-0007EI-00@sc8-sf-web3.sourceforge.net>

Bugs item #870382, was opened at 2004-01-04 14:55
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470

Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: Mingw needs to use the same MSVC runtime as Python

Initial Comment:
Python 2.4 is now built with MSVC 7.1, which uses a 
new MSVC runtime library.

Extension DLLs should be built to use the same runtime 
DLL as Python itself (although it has not been possible 
to find a real-world example where not doing so causes 
a problem...)

The attached patch adds the appropriate -l flag to the 
link, based on the MSVC version reported in sys.version. 
(This has only been tested with a Python built with 
MSVC 7.1, the version number used for MSVC 7.0 is 
based on verbal reports only).

----------------------------------------------------------------------

>Comment By: Paul Moore (pmoore)
Date: 2004-07-09 12:17

Message:
Logged In: YES 
user_id=113328

This is still an issue with 2.4a1. I'm not sure what the 
autodetection buys given that currently it's not possible to 
build extensions with 2.4a1 using mingw which are compatible 
with the stock python.org binary.

Can I suggest that this patch be applied, and issues around 
autodetection be deferred until there is a demonstrated need?

I've uploaded a revised patch for 2.4a1 (tested against the 
python.org supplied MSI).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-05 21:30

Message:
Logged In: YES 
user_id=21627

I'm primarily concerned about future
(unreleased-as-of-today) MSC versions; they likely have
version numbers like "1400"; linking msvcr71 to binaries
built with that compiler is likely wrong.

Not adding anything for gcc-built python versions is fine.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-04 23:01

Message:
Logged In: YES 
user_id=113328

What about Python built with mingw? I don't think that's 
possible right now, but I'd expect people to work on it. And 
I've no idea what sys.version for that would be.

The only real cases are likely to be MSVC 7.1 (Python 2.4, 
binary dist), MSVC 6 (Python <= 2.3, binary dist) and hand-
built Python versions. The patch does the right thing for all 
the binary distributions, which are the ones where the user 
can't be assumed to know how to hack things to make them 
work.

For hand-built versions, the user can do "python setup.py 
build_ext --compiler=mingw32 -l msvcr71" (or whatever) to 
manually specify the runtime to use. Leaving the default as 
msvcrt (the CRT that comes with the OS, and is default for 
mingw) seems right - and better than aborting (particularly as 
I'm not sure how to check whether there's an -l option for 
the CRT specified by the user).

The best I could do is effectively to force build_ext to fail 
unless Python was built with MSVC, which seems unhelpful...

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-04 15:03

Message:
Logged In: YES 
user_id=21627

Could you add some kind of assertion to detect the case that
an entirely different compiler version is used? It would be
best if it gets the case of using MSVC6 right, and gives up
if some other compiler version is detected (I can't
determine os.version for the VC6 case right now, but Python
2.3 is built with it).

Apart from that, the patch looks good.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 14:15:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 14:15:11 2004
Subject: [ python-Bugs-987870 ] Windows installer for 2.4a1 shows
	non-standard version
Message-ID: <E1BiuHR-0005pE-00@sc8-sf-web2.sourceforge.net>

Bugs item #987870, was opened at 2004-07-09 13:03
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
>Assigned to: Martin v. L?wis (loewis)
Summary: Windows installer for 2.4a1 shows non-standard version

Initial Comment:
The Windows installer (MSI) for Python 2.4a1 displays 
the Python version as 2.4.0.12607. This is not the 
standard version format, which should show as 2.4a0.

While this is mainly a cosmetic issue, it will make it 
difficult to verify that the version installed matches the 
latest released alpha/beta. (It's not clear whether the 
final number - the 12607 - will be dropped with the 
release, so this may not be an issue for 2.4 final).

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-09 14:15

Message:
Logged In: YES 
user_id=11105

Martin v. Loewis builds the MSI's.  Assigned to him.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 16:08:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 16:09:14 2004
Subject: [ python-Bugs-986528 ] bsddb/weakref error
Message-ID: <E1Biw3b-0005sx-00@sc8-sf-web3.sourceforge.net>

Bugs item #986528, was opened at 2004-07-07 06:51
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bsddb/weakref error

Initial Comment:
After a cvs up and reinstall of Python, Spambayes is giving 
me this traceback:

Traceback (most recent call last):
  File "/Users/skip/local/bin/sb_filter.py", line 257, in ?
    main()
  File "/Users/skip/local/bin/sb_filter.py", line 248, in main
    action(msg)
  File "/Users/skip/local/bin/sb_filter.py", line 192, in 
train_spam
    self.open('c')
  File "/Users/skip/local/bin/sb_filter.py", line 163, in open
    self.h = hammie.open(self.dbname, self.usedb, 
self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/hammie.py", line 275, in open
    return Hammie(storage.open_storage(filename, useDB, 
mode))
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 679, in open_storage
    return klass(data_source_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 164, in __init__
    self.load()
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 189, in load
    self.dbm = dbmstorage.open(self.db_name, self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 65, in open
    return f(db_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 19, in open_dbhash
    import bsddb
  File "/Users/skip/local/lib/python2.4/bsddb/__init__.py", 
line 68, in ?
    exec """
  File "<string>", line 3, in ?
  File "/Users/skip/local/lib/python2.4/weakref.py", line 152, 
in ?
    class KeyedRef(ref):
TypeError: cannot create 'builtin_function_or_method' 
instances

I don't know what it means, but it wasn't happening before 
the cvs up.  I suspect something changed in the bsddb3 
stuff, so I'm provisionally giving it to Greg.



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 09:08

Message:
Logged In: YES 
user_id=44345

Further inspection of recent python-checkins activity shows
a large change to the weakref stuff by Fred on July 2nd
(more recent than Greg's change to bsddb on June 28th), so
reassigning to him in case it's a weakref problem.
I've been so-far unable to back out the change in my
repository (subsequent changes to some of the files make
that difficult), so I can't verify the weakref changes are
the root of my problems, but they seem pretty wide-ranging,
so that's my guess.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 16:14:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 16:14:36 2004
Subject: [ python-Bugs-986528 ] bsddb/weakref error
Message-ID: <E1Biw8m-0003hq-00@sc8-sf-web4.sourceforge.net>

Bugs item #986528, was opened at 2004-07-07 12:51
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bsddb/weakref error

Initial Comment:
After a cvs up and reinstall of Python, Spambayes is giving 
me this traceback:

Traceback (most recent call last):
  File "/Users/skip/local/bin/sb_filter.py", line 257, in ?
    main()
  File "/Users/skip/local/bin/sb_filter.py", line 248, in main
    action(msg)
  File "/Users/skip/local/bin/sb_filter.py", line 192, in 
train_spam
    self.open('c')
  File "/Users/skip/local/bin/sb_filter.py", line 163, in open
    self.h = hammie.open(self.dbname, self.usedb, 
self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/hammie.py", line 275, in open
    return Hammie(storage.open_storage(filename, useDB, 
mode))
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 679, in open_storage
    return klass(data_source_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 164, in __init__
    self.load()
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 189, in load
    self.dbm = dbmstorage.open(self.db_name, self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 65, in open
    return f(db_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 19, in open_dbhash
    import bsddb
  File "/Users/skip/local/lib/python2.4/bsddb/__init__.py", 
line 68, in ?
    exec """
  File "<string>", line 3, in ?
  File "/Users/skip/local/lib/python2.4/weakref.py", line 152, 
in ?
    class KeyedRef(ref):
TypeError: cannot create 'builtin_function_or_method' 
instances

I don't know what it means, but it wasn't happening before 
the cvs up.  I suspect something changed in the bsddb3 
stuff, so I'm provisionally giving it to Greg.



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-09 15:14

Message:
Logged In: YES 
user_id=6656

Are you sure your build is completely up to date?  For
whatever reason, it looks like _weakref.ref in the traceback
above is a 'builtin_function_or_method', not a 'type' which
is what Fred's checkins turned it into.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 15:08

Message:
Logged In: YES 
user_id=44345

Further inspection of recent python-checkins activity shows
a large change to the weakref stuff by Fred on July 2nd
(more recent than Greg's change to bsddb on June 28th), so
reassigning to him in case it's a weakref problem.
I've been so-far unable to back out the change in my
repository (subsequent changes to some of the files make
that difficult), so I can't verify the weakref changes are
the root of my problems, but they seem pretty wide-ranging,
so that's my guess.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 16:31:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 16:31:24 2004
Subject: [ python-Bugs-986528 ] bsddb/weakref error
Message-ID: <E1BiwPH-0006qI-00@sc8-sf-web3.sourceforge.net>

Bugs item #986528, was opened at 2004-07-07 06:51
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bsddb/weakref error

Initial Comment:
After a cvs up and reinstall of Python, Spambayes is giving 
me this traceback:

Traceback (most recent call last):
  File "/Users/skip/local/bin/sb_filter.py", line 257, in ?
    main()
  File "/Users/skip/local/bin/sb_filter.py", line 248, in main
    action(msg)
  File "/Users/skip/local/bin/sb_filter.py", line 192, in 
train_spam
    self.open('c')
  File "/Users/skip/local/bin/sb_filter.py", line 163, in open
    self.h = hammie.open(self.dbname, self.usedb, 
self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/hammie.py", line 275, in open
    return Hammie(storage.open_storage(filename, useDB, 
mode))
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 679, in open_storage
    return klass(data_source_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 164, in __init__
    self.load()
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 189, in load
    self.dbm = dbmstorage.open(self.db_name, self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 65, in open
    return f(db_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 19, in open_dbhash
    import bsddb
  File "/Users/skip/local/lib/python2.4/bsddb/__init__.py", 
line 68, in ?
    exec """
  File "<string>", line 3, in ?
  File "/Users/skip/local/lib/python2.4/weakref.py", line 152, 
in ?
    class KeyedRef(ref):
TypeError: cannot create 'builtin_function_or_method' 
instances

I don't know what it means, but it wasn't happening before 
the cvs up.  I suspect something changed in the bsddb3 
stuff, so I'm provisionally giving it to Greg.



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 09:31

Message:
Logged In: YES 
user_id=44345

Yes.  My sandbox has no tags.  I generally just blindly do a
"cvs up ; configure ; make install" and start using the
result as my day-to-day Python interpreter.

I just reverted Fred's changes from July 2 to the relevant
.c, .py and .h files in my sandbox and confirmed that the
traceback disappeared.

Maybe there's nothing wrong with what Fred checked in, but
that it had an unintended effect on the bsddb package, and
that's where the problem needs to be resolved.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-09 09:14

Message:
Logged In: YES 
user_id=6656

Are you sure your build is completely up to date?  For
whatever reason, it looks like _weakref.ref in the traceback
above is a 'builtin_function_or_method', not a 'type' which
is what Fred's checkins turned it into.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 09:08

Message:
Logged In: YES 
user_id=44345

Further inspection of recent python-checkins activity shows
a large change to the weakref stuff by Fred on July 2nd
(more recent than Greg's change to bsddb on June 28th), so
reassigning to him in case it's a weakref problem.
I've been so-far unable to back out the change in my
repository (subsequent changes to some of the files make
that difficult), so I can't verify the weakref changes are
the root of my problems, but they seem pretty wide-ranging,
so that's my guess.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 16:47:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 16:48:06 2004
Subject: [ python-Bugs-985478 ] bdist_rpm license documented,
	but not accepted as valid
Message-ID: <E1BiwfO-0004sn-00@sc8-sf-web4.sourceforge.net>

Bugs item #985478, was opened at 2004-07-05 10:14
Message generated for change (Comment added) made by melicertes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985478&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles (melicertes)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_rpm license documented, but not accepted as valid

Initial Comment:
The distutils documentation at
http://docs.python.org/dist/postinstallation-script.html#SECTION000620000000000000000
states that the RPM copyright field can be set using
the distutils setup script option "licence", but it is
refused as invalid by distutils:

$ /usr/bin/python2.3 setup.py bdist_rpm --licence="GNU
GPL v.2"
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2
[cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --licence not recognized


It's also refused (same error message output, except
for spelling) with the spelling "license".  Both
spellings are also 
rejected as errors if placed in setup.cfg's [bdist_rpm]
section:

$ /usr/bin/python2.3 setup.py bdist_rpm
running bdist_rpm
error: error in setup.cfg: command 'bdist_rpm' has no
such option 'license'







----------------------------------------------------------------------

>Comment By: Charles (melicertes)
Date: 2004-07-09 08:47

Message:
Logged In: YES 
user_id=1064824

No response?

I can't use distutils to create RPMs if I can't specify the
license.  Normally I'd just write my own spec file and use
the --spec-file option, but the docs say this isn't
implemented yet.


----------------------------------------------------------------------

Comment By: Charles (melicertes)
Date: 2004-07-05 10:43

Message:
Logged In: YES 
user_id=1064824

This was tested with Python 2.3.4 final, by the way.  The
behaviour was unchanged in earlier release candidates.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985478&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 17:12:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 17:12:30 2004
Subject: [ python-Bugs-986528 ] bsddb/weakref error
Message-ID: <E1Bix33-000573-00@sc8-sf-web2.sourceforge.net>

Bugs item #986528, was opened at 2004-07-07 07:51
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bsddb/weakref error

Initial Comment:
After a cvs up and reinstall of Python, Spambayes is giving 
me this traceback:

Traceback (most recent call last):
  File "/Users/skip/local/bin/sb_filter.py", line 257, in ?
    main()
  File "/Users/skip/local/bin/sb_filter.py", line 248, in main
    action(msg)
  File "/Users/skip/local/bin/sb_filter.py", line 192, in 
train_spam
    self.open('c')
  File "/Users/skip/local/bin/sb_filter.py", line 163, in open
    self.h = hammie.open(self.dbname, self.usedb, 
self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/hammie.py", line 275, in open
    return Hammie(storage.open_storage(filename, useDB, 
mode))
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 679, in open_storage
    return klass(data_source_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 164, in __init__
    self.load()
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 189, in load
    self.dbm = dbmstorage.open(self.db_name, self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 65, in open
    return f(db_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 19, in open_dbhash
    import bsddb
  File "/Users/skip/local/lib/python2.4/bsddb/__init__.py", 
line 68, in ?
    exec """
  File "<string>", line 3, in ?
  File "/Users/skip/local/lib/python2.4/weakref.py", line 152, 
in ?
    class KeyedRef(ref):
TypeError: cannot create 'builtin_function_or_method' 
instances

I don't know what it means, but it wasn't happening before 
the cvs up.  I suspect something changed in the bsddb3 
stuff, so I'm provisionally giving it to Greg.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-09 11:12

Message:
Logged In: YES 
user_id=3066

What version of Spambayes are you using?

Is there a Spambayes test suite I can run with a given
Python, without screwing with my own Spambayes installation?
 I don't know anything about Spambayes development.

Is this running on Mac OS X of some flavor?  (Guessing from
the weird /Users directory.)

mwh's comment is right on target; something fishy is going
on here.  It looks like you're getting the CVS version of
weakref.py, but you _weakref.so is out of date.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 10:31

Message:
Logged In: YES 
user_id=44345

Yes.  My sandbox has no tags.  I generally just blindly do a
"cvs up ; configure ; make install" and start using the
result as my day-to-day Python interpreter.

I just reverted Fred's changes from July 2 to the relevant
.c, .py and .h files in my sandbox and confirmed that the
traceback disappeared.

Maybe there's nothing wrong with what Fred checked in, but
that it had an unintended effect on the bsddb package, and
that's where the problem needs to be resolved.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-09 10:14

Message:
Logged In: YES 
user_id=6656

Are you sure your build is completely up to date?  For
whatever reason, it looks like _weakref.ref in the traceback
above is a 'builtin_function_or_method', not a 'type' which
is what Fred's checkins turned it into.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 10:08

Message:
Logged In: YES 
user_id=44345

Further inspection of recent python-checkins activity shows
a large change to the weakref stuff by Fred on July 2nd
(more recent than Greg's change to bsddb on June 28th), so
reassigning to him in case it's a weakref problem.
I've been so-far unable to back out the change in my
repository (subsequent changes to some of the files make
that difficult), so I can't verify the weakref changes are
the root of my problems, but they seem pretty wide-ranging,
so that's my guess.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 17:17:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 17:17:31 2004
Subject: [ python-Bugs-988022 ] bdist_wininst improvements
Message-ID: <E1Bix7w-00062M-00@sc8-sf-web4.sourceforge.net>

Bugs item #988022, was opened at 2004-07-09 17:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988022&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: bdist_wininst improvements

Initial Comment:
bdist_wininst installed programs show a ridiculous size
in the Add/Remove programs list.  For example, py2exe
reports 126 MB, and pywin32 reports 113 MB.
This article explains why <http://tinyurl.com/38ko8>.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988022&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 19:37:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 19:37:09 2004
Subject: [ python-Bugs-988120 ] httplib.HTTPResponse.read() not updating the
	length correctl
Message-ID: <E1BizJ4-00039u-00@sc8-sf-web4.sourceforge.net>

Bugs item #988120, was opened at 2004-07-09 13:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988120&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib.HTTPResponse.read() not updating the length correctl

Initial Comment:
I believe there is a bug in HTTPResponse.read. This is
the last part:
                                                      
                         
                                                      
                         
                                                      
                         
        if self.length is not None:
            if amt > self.length:
                # clip the read to the "end of response"
                amt = self.length
            self.length -= amt
                                                      
                         
        # we do not use _safe_read() here because this
may be a .will_close
        # connection, and the user is reading more
bytes than will be provided
        # (for example, reading in 1k chunks)
        s = self.fp.read(amt)
                                                      
                         
        return s
                                                      
                         
                                                      
                         
self.length is the response's length as presented by
the Content-Length header.
                                                      
                         
If I am not mistaken, self.fp.read(amt) (for the case
where amt is not None) returns _up to_, not _exactly_
amt bytes.
                                                      
                         
So, if amt is originally 1024 bytes and self.fp.read
returns only 520 bytes (because, let's say, you are
reading from an SSL socket), then self.length is
decremented by 1024 and not by 520. So you end up
reading less than self.length
                                                      
                         
I am seeing this when plugging an SSL socket/file from
pyOpenSSL.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988120&group_id=5470
From noreply at sourceforge.net  Fri Jul  9 22:13:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul  9 22:13:59 2004
Subject: [ python-Bugs-987870 ] Windows installer for 2.4a1 shows
	non-standard version
Message-ID: <E1Bj1ko-0000iK-00@sc8-sf-web1.sourceforge.net>

Bugs item #987870, was opened at 2004-07-09 13:03
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: Windows installer for 2.4a1 shows non-standard version

Initial Comment:
The Windows installer (MSI) for Python 2.4a1 displays 
the Python version as 2.4.0.12607. This is not the 
standard version format, which should show as 2.4a0.

While this is mainly a cosmetic issue, it will make it 
difficult to verify that the version installed matches the 
latest released alpha/beta. (It's not clear whether the 
final number - the 12607 - will be dropped with the 
release, so this may not be an issue for 2.4 final).

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-09 22:13

Message:
Logged In: YES 
user_id=21627

It is no issue for the final release, which will drop this
number.

The version number must be a number, so it can't be 2.4a1.
The text displayed in the dialogs could be different, of
course - it just would be more work to make it so.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-09 14:15

Message:
Logged In: YES 
user_id=11105

Martin v. Loewis builds the MSI's.  Assigned to him.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 01:35:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 01:35:46 2004
Subject: [ python-Bugs-986795 ] New mandatory 2nd argument to
	site.addsitedir breaks compat
Message-ID: <E1Bj4u5-00078h-00@sc8-sf-web1.sourceforge.net>

Bugs item #986795, was opened at 2004-07-07 11:56
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Brett Cannon (bcannon)
Summary: New mandatory 2nd argument to site.addsitedir breaks compat

Initial Comment:

  Old .pth files now raise a TypeError, which site.py
does not catch, which causes the import of site.py to fail.

  The new required parameter is also undocumented and,
on a cursory inspection, it is unclear to me what its
purpose is.

  This comes up because Debian allows for a version
neutral site-packages directory, /usr/lib/site-python/,
into which .pth files can be placed.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-09 16:35

Message:
Logged In: YES 
user_id=357491

Yes, it is my change, but the one call to the function has the argument 
and the function is undocumented so I didn't worry about it.  As for its 
use, it allowed me to get rid of the nasty global variable that every 
function assumed was there for basic sys.path duplication checks.

I have gone ahead and made it optional.

As for the .pth errors, the test suite tests .pth files and the test passes.  
Do you have an example .pth file, JP, that I can test against?  How about 
the traceback of the exception?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 18:30

Message:
Logged In: YES 
user_id=33168

Brett, did this happen from your changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 01:53:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 01:53:25 2004
Subject: [ python-Bugs-988300 ] Compiler warnings for
	Modules/readline.c:flex_complete()
Message-ID: <E1Bj5B7-0000rU-00@sc8-sf-web3.sourceforge.net>

Bugs item #988300, was opened at 2004-07-09 16:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Michael Hudson (mwh)
Summary: Compiler warnings for Modules/readline.c:flex_complete()

Initial Comment:
When I compile on my OS X 10.3.4 with Fink's readline 4.3-25 I get 
the following two warnings:

/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: implicit declaration of function `completion_matches'
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: return makes pointer from integer without a cast

Now, although I have a version greater than 4.2, this only makes 
sense if HAVE_RL_COMPLETION_MATCHES is undefined and thus 
the completion_matches() macro is not being defined (although I 
checked and the headers have a prototype for 
rl_completion_matches() and my readline seems to compile and 
work well enough).

Would a #else statement that defines completion_matches() fit in 
there?  Problem would be the return type for flex_complete() 
might need to be covered as well unless a clever macro can be 
created that returns a char **.

Initially assigned to Michael since he seems to always deal with the 
readline stuff.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 05:31:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 05:31:16 2004
Subject: [ python-Bugs-988120 ] httplib.HTTPResponse.read() not updating the
	length correctl
Message-ID: <E1Bj8Zz-0002if-00@sc8-sf-web2.sourceforge.net>

Bugs item #988120, was opened at 2004-07-09 13:37
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988120&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib.HTTPResponse.read() not updating the length correctl

Initial Comment:
I believe there is a bug in HTTPResponse.read. This is
the last part:
                                                      
                         
                                                      
                         
                                                      
                         
        if self.length is not None:
            if amt > self.length:
                # clip the read to the "end of response"
                amt = self.length
            self.length -= amt
                                                      
                         
        # we do not use _safe_read() here because this
may be a .will_close
        # connection, and the user is reading more
bytes than will be provided
        # (for example, reading in 1k chunks)
        s = self.fp.read(amt)
                                                      
                         
        return s
                                                      
                         
                                                      
                         
self.length is the response's length as presented by
the Content-Length header.
                                                      
                         
If I am not mistaken, self.fp.read(amt) (for the case
where amt is not None) returns _up to_, not _exactly_
amt bytes.
                                                      
                         
So, if amt is originally 1024 bytes and self.fp.read
returns only 520 bytes (because, let's say, you are
reading from an SSL socket), then self.length is
decremented by 1024 and not by 520. So you end up
reading less than self.length
                                                      
                         
I am seeing this when plugging an SSL socket/file from
pyOpenSSL.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-09 23:31

Message:
Logged In: YES 
user_id=6380

Python's regular files always return the requested amount
except at EOF. But many file-like objects don't guarantee
this, so I agree that it's better to only adjust the
position by the number of bytes actually read.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988120&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 09:27:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 09:27:48 2004
Subject: [ python-Bugs-988387 ] non local link in local docs
Message-ID: <E1BjCGv-0007wO-00@sc8-sf-web4.sourceforge.net>

Bugs item #988387, was opened at 2004-07-10 03:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988387&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: brian vdb (brianvanden)
Assigned to: Nobody/Anonymous (nobody)
Summary: non local link in local docs

Initial Comment:
The Installing Python Modules section 4.1 Modifying
Python's Search Path has a line saying:

See site module" >the documentation for the site module
for more information. 

This link is to the online copy of the docs, even
within the local copy that came with Python.

I am using Python 2.3.4.

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988387&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 11:31:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 11:31:42 2004
Subject: [ python-Bugs-987870 ] Windows installer for 2.4a1 shows
	non-standard version
Message-ID: <E1BjECj-0005fx-00@sc8-sf-web3.sourceforge.net>

Bugs item #987870, was opened at 2004-07-09 12:03
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: Windows installer for 2.4a1 shows non-standard version

Initial Comment:
The Windows installer (MSI) for Python 2.4a1 displays 
the Python version as 2.4.0.12607. This is not the 
standard version format, which should show as 2.4a0.

While this is mainly a cosmetic issue, it will make it 
difficult to verify that the version installed matches the 
latest released alpha/beta. (It's not clear whether the 
final number - the 12607 - will be dropped with the 
release, so this may not be an issue for 2.4 final).

----------------------------------------------------------------------

>Comment By: Paul Moore (pmoore)
Date: 2004-07-10 10:31

Message:
Logged In: YES 
user_id=113328

Fair enough. So the final release will show 2.4 (or 2.4.0?).
That's the main thing, I guess.

I'm happy for this to be closed as something that the MSI
format doesn't support. (Can I do that myself...?)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-09 21:13

Message:
Logged In: YES 
user_id=21627

It is no issue for the final release, which will drop this
number.

The version number must be a number, so it can't be 2.4a1.
The text displayed in the dialogs could be different, of
course - it just would be more work to make it so.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-09 13:15

Message:
Logged In: YES 
user_id=11105

Martin v. Loewis builds the MSI's.  Assigned to him.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 13:13:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 13:13:49 2004
Subject: [ python-Bugs-988387 ] non local link in local docs
Message-ID: <E1BjFnd-0006W5-00@sc8-sf-web1.sourceforge.net>

Bugs item #988387, was opened at 2004-07-10 02:27
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988387&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: brian vdb (brianvanden)
Assigned to: Nobody/Anonymous (nobody)
Summary: non local link in local docs

Initial Comment:
The Installing Python Modules section 4.1 Modifying
Python's Search Path has a line saying:

See site module" >the documentation for the site module
for more information. 

This link is to the online copy of the docs, even
within the local copy that came with Python.

I am using Python 2.3.4.

Thanks

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-10 06:13

Message:
Logged In: YES 
user_id=80475

Fixed.
See Doc/inst/inst.tex 1.55

Thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988387&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 13:16:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 13:16:34 2004
Subject: [ python-Bugs-987486 ] Typo in cgi doc
Message-ID: <E1BjFqJ-0004mj-00@sc8-sf-web4.sourceforge.net>

Bugs item #987486, was opened at 2004-07-08 13:52
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987486&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Cory Dodt (corydodt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in cgi doc

Initial Comment:
Referring to this doc page:

http://www.python.org/doc/current/lib/node404.html

"""
getfirst(  	name[, default])
    Thin method always returns only one value
associated with form field name. 
"""

"Thin" should be "This".

Submitted by Glyph Lefkowitz, who does not like to use
the sf bug tracker.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-10 06:16

Message:
Logged In: YES 
user_id=80475

Fixed.
See Doc/lib/libcgi.tex 1.45

Thanks for the report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987486&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 13:18:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 13:18:34 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1BjFsB-0004pl-00@sc8-sf-web4.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 15:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (shredwheat)
>Assigned to: Michael Hudson (mwh)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 15:48:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 15:48:22 2004
Subject: [ python-Bugs-987835 ] pep 311 functions missing documentation
Message-ID: <E1BjID9-0000Ay-00@sc8-sf-web4.sourceforge.net>

Bugs item #987835, was opened at 2004-07-09 05:37
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987835&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
>Assigned to: A.M. Kuchling (akuchling)
Summary: pep 311 functions missing documentation

Initial Comment:
the c api functions from pep 311 is missing documentation

PyGILState_Ensure

PyGILState_Release

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 09:48

Message:
Logged In: YES 
user_id=11375

Now documented in the "Thread State" section of the API docs; thank you 
for pointing this out!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987835&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 17:28:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 17:28:44 2004
Subject: [ python-Bugs-818201 ] distutils: clean -b ignored;
	set_undefined_options doesn't
Message-ID: <E1BjJmJ-0002wc-00@sc8-sf-web4.sourceforge.net>

Bugs item #818201, was opened at 2003-10-05 13:37
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818201&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicholas Riley (nriley)
>Assigned to: Nobody/Anonymous (nobody)
Summary: distutils: clean -b ignored; set_undefined_options doesn't

Initial Comment:
I reported this on the distutils-sig list and didn't receive 
any response. I'd be happy to provide a patch, but I'm not 
sure which way to go.

&lt;http://mail.python.org/pipermail/distutils-sig/2003-
September/003414.html&gt;

Here's something that I think should work:

% python setup.py --help clean
[...]
Options for 'clean' command:
  --build-base (-b)  base build directory (default: 
'build.build-base')
% python setup.py clean -b ../builds
running clean

Nothing happens.  This works, however:

% python setup.py build -b ../builds clean
running build
running build_py
running build_ext
running config
gcc -E -I/Library/Frameworks/Python.framework/Versions/
2.3/include/python2.3 -o_configtest.i _configtest.c
removing: _configtest.c _configtest.i
running clean
removing '../builds/temp.darwin-6.8-Power_Macintosh-2.3' 
(and everything under it)

The logic to set build_temp from build_base (-b) is only 
present in the build command, not in the clean command.  
The code to set this option runs from 
clean.set_undefined_options.  But it's clean's build_base 
option which is set at the time, not build's, so it 
propagates an empty path.

The test command class I found posted to the distutils-sig 
mailing list has a workaround for the above problem, which 
looks like this:

    def finalize_options(self):
        build = self.distribution.get_command_obj('build')
        build_options = ('build_base', 'build_purelib', 
'build_platlib')
        for option in build_options:
            setattr(build, option, getattr(self, option))
        build.ensure_finalized()
        for option in build_options:
            setattr(self, option, getattr(build, option))

and doesn't call self.set_undefined_options at all, though 
the last three lines could be replaced by it.

There are several solutions I can think of:

- set_undefined_options should be changed to propagate 
set options to
  the source command object before calling 
src_cmd_obj.ensure_finalized.

- another method should be added to the cmd class, which 
does the above
  propagation then calls set_undefined_options.

- a workaround such as the one above should be placed in 
the
  distutils.command.clean.clean class.

Does this make sense?  Unless there's a huge compatibility 
issue, I'd favor the first option, but my experience with 
distutils is limited.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818201&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 17:29:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 17:29:24 2004
Subject: [ python-Bugs-828743 ] bdist_rpm failure when no setup.py
Message-ID: <E1BjJmw-0005P1-00@sc8-sf-web1.sourceforge.net>

Bugs item #828743, was opened at 2003-10-23 04:19
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828743&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Pearu Peterson (pearu)
>Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_rpm failure when no setup.py

Initial Comment:
Hi,

It appeas that setup.py is hardcoded into bdist_rpm.py
and this causes failure whenever using setup.py with
a different name. For example:
  python setup_xxx.py bdist_rpm
results in

&lt;snip&gt;
+ env 'CFLAGS=-O2 -march=i386 -mcpu=i686' python
setup.py build
python: can't open file 'setup.py'
error: Bad exit status from /var/tmp/rpm-tmp.14535 (%build)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.14535 (%build)
error: command 'rpmbuild' failed with exit status 1

Would it be possible for bdist_rpm.py to use the same
setup.py filename in def_build variable that called it?

Pearu

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828743&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 17:29:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 17:29:50 2004
Subject: [ python-Bugs-828450 ] sdist generates bad MANIFEST on Windows
Message-ID: <E1BjJnO-0005Q1-00@sc8-sf-web1.sourceforge.net>

Bugs item #828450, was opened at 2003-10-22 15:30
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828450&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
>Assigned to: Nobody/Anonymous (nobody)
Summary: sdist generates bad MANIFEST on Windows

Initial Comment:
The generated MANIFEST file has Windows slashes
separating path components.  If you use this MANIFEST
on Unix, it will bomb complaining the the files are not
&quot;regular files.&quot;  If you generate a MANIFEST on Unix,
it will work on Windows.

Presumably the solution is to replace \ with / on Windows.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828450&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 17:57:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 17:57:24 2004
Subject: [ python-Bugs-835145 ] [2.3.2] zipfile test failure on AIX 5.1
Message-ID: <E1BjKE3-0003lq-00@sc8-sf-web4.sourceforge.net>

Bugs item #835145, was opened at 2003-11-03 12:06
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470

>Category: Python Library
>Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: The Written Word (Albert Chin) (tww-china)
Assigned to: A.M. Kuchling (akuchling)
Summary: [2.3.2] zipfile test failure on AIX 5.1

Initial Comment:
$ cd /opt/build/Python-2.3.2
$ ./python -E -tt Lib/test/test_zipfile.py
Traceback (most recent call last):
  File &quot;Lib/test/test_zipfile.py&quot;, line 35, in ?
    zipTest(file, zipfile.ZIP_STORED, writtenData)
  File &quot;Lib/test/test_zipfile.py&quot;, line 13, in zipTest
    zip.close()
  File &quot;/opt/build/Python-2.3.2/Lib/zipfile.py&quot;, line
503, in close
    zinfo.header_offset)
OverflowError: long int too large to convert
Exception exceptions.OverflowError: 'long int too large
to convert' in &lt;bound method ZipFile.__del__ of
&lt;zipfile.ZipFile instance at 0x20308da0&gt;&gt; ignored

The test passes just fine on AIX 4.3.2.

This is against a Python built with the IBM v6 C
compiler and GCC 3.3.2.

I added some debugging print statements to
Lib/zipfile.py and it seems that zinfo.external_attr is
out of whack. On AIX 4.3.2, the value for this variable
is &quot;2176057344&quot; while on AIX 5.1 it is &quot;10765991936&quot;.

I tracked this back to the following line in the write
method of Lib/zipfile.py:
        zinfo.external_attr = st[0] &lt;&lt; 16L      # Unix
attributes
On AIX 4.3.2, st[0] is 33204 while on AIX 5.1 it is
164276. In python 2.2.x, it was '&lt;&lt; 16' which resulted
in a signed value on AIX 5.1. I really don't think you
can use the 16L as mode_t on AIX is unsigned int. Ditto
for other platforms. Why not just store st[0] unchanged?

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 11:57

Message:
Logged In: YES 
user_id=11375

I've committed the suggested change to both CVS HEAD and the 2.3 
branch.  Thanks for reporting the problem!

----------------------------------------------------------------------

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-11-30 19:47

Message:
Logged In: YES 
user_id=119770

Ok, your (st[0] &amp; 0xffff) change should be ok. AIX has
several file systems available, among them JFS and JFS2.
zipfile.py works fine on JFS and NFS file systems but not
JFS2. The 0xffff change throws away the extra bits but it
shouldn't matter.

I checked the zip source and they don't &amp; with 0xffff but
they have the same problem. However, because the shift by 16
is constrained by the maxint(unsigned short), we don't run
into the same problem with the zip source as with Python
which promotes the int to a long.

----------------------------------------------------------------------

Comment By: The Written Word (Albert Chin) (tww-china)
Date: 2003-11-13 14:51

Message:
Logged In: YES 
user_id=119770

The suggestion works. I want to look through the zip-2.3
source though. I'll do so this weekend.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-11-13 14:11

Message:
Logged In: YES 
user_id=6380

So Albert, any luck with my suggestion?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-11-10 11:43

Message:
Logged In: YES 
user_id=6380

It looks like what is happening is that the mode returned by
stat() has a bit beyond the 16th set. I'm guessing that
those extra bits should be ignored -- there is no room for
them in the header it seems.

Could you try replacing st[0] with (st[0] &amp; 0xffff) in that
expression and then try again?

(Hm, I wonder why the Unix mode is left-shifted 16 bits.
Maybe the real definition of &quot;external attributes&quot; is a bit
different? What is supposed to be stored in those lower 16
bits that always appear to be zero? I don't have time to
research this.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 19:15:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 19:15:58 2004
Subject: [ python-Bugs-629097 ] Race condition in asyncore poll
Message-ID: <E1BjLS5-0005uE-00@sc8-sf-web4.sourceforge.net>

Bugs item #629097, was opened at 2002-10-26 10:48
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629097&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: A.M. Kuchling (akuchling)
Summary: Race condition in asyncore poll

Initial Comment:
In the following post to the Zope 3 developers' list, I
describe a race condition in the poll method of asyncore.

http://lists.zope.org/pipermail/zope3-dev/2002-October/003091.html

The problem is this:

There is a global dict socket_map. In the poll method,
socket_map is processed into appropriate arguments for
a select.select call. However, if a socket that is
represented socket_map is closed during the time
between the processing of socket_map and the
select.select call, that call will fail with a Bad File
Descriptor (EBADF) error.

One solution is to patch asyncore to catch EBADF errors
raised by select.select, and at that point see if the
file descriptors in the current version of socket_map 
are the same as in the processed data used for the
select.select call. If they are the same, re-raise the
error, otherwise, ignore the error.

In another email to the Zope 3 developers' list, Jeremy
Hylton queries whether there are any other similar
problems in asyncore.

http://lists.zope.org/pipermail/zope3-dev/2002-October/003093.html


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 13:15

Message:
Logged In: YES 
user_id=11375

Closing this bug.

----------------------------------------------------------------------

Comment By: Alexey Klimkin (klimkin)
Date: 2004-02-24 07:03

Message:
Logged In: YES 
user_id=410460

Yup, closing file in separate thread is program's (not
asyncore) error.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-05 17:49

Message:
Logged In: YES 
user_id=6380

According to Jeremy, this is more a matter of &quot;don't do that&quot;.

The right solution is to make sure that sockets are only
closed by the main thread (the thread running asyncore.loop()).

I wonder if we should just close this bug report?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629097&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 19:17:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 19:17:04 2004
Subject: [ python-Bugs-949832 ] Problem w/6.27.2.2 GNUTranslations
	ungettext() example code
Message-ID: <E1BjLTA-00008G-00@sc8-sf-web1.sourceforge.net>

Bugs item #949832, was opened at 2004-05-07 08:44
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=949832&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin Miller (mrmiller)
Assigned to: A.M. Kuchling (akuchling)
Summary: Problem w/6.27.2.2 GNUTranslations ungettext() example code

Initial Comment:
> Here is an example: 
> 
> n = len(os.listdir('.'))
> cat = GNUTranslations(somefile)
> message = cat.ungettext(
>     'There is %(num)d file in this directory',
>     'There are %(num)d files in this directory',
>     n) % {'n': n}

The last line of code in the example should be:

>     n) % {'num': n}

Also, I don't think the example illustrates a realistic
usage of the ungettext() method, as it is unlikely that
the message catalog is going to have different message
id's for all the possible variations of the string each
with a different number of files in them -- exactly the
problem that ungettext() is suppose to address.

A better example would just use ungettext() to pick
either the word "file" or "files" based on the value of
n. It would be more realistic and the example code
would probably be simpler.





----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 13:17

Message:
Logged In: YES 
user_id=11375

Example fixed in CVS and in 2.3 branch; thanks!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=949832&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 20:25:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 20:25:31 2004
Subject: [ python-Bugs-947571 ] urllib.urlopen() fails to raise exception
Message-ID: <E1BjMXM-0000ti-00@sc8-sf-web2.sourceforge.net>

Bugs item #947571, was opened at 2004-05-04 02:57
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen() fails to raise exception

Initial Comment:
I've come across a strange problem: even though
the docs say that urllib.urlopen() should raise an IOError
for server errors (e.g. 404s), all versions of Python that
I've tested (1.5.2 - 2.3) fail to do so.

Example:
>>> import urllib
>>> f =
urllib.urlopen('http://www.example.net/this-url-does-not-exist/')
>>> print f.read()
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /this-url-does-not-exist/ was not
found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.27 Server at www.example.com Port
80</ADDRESS>
</BODY></HTML>

Either the docs are wrong or the implementation has a
really long standing bug or I am missing something.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 11:25

Message:
Logged In: YES 
user_id=371366

In urllib.FancyURLopener, which is the class used by 
urllib.urlopen(), there is this override of URLopener's 
http_error_default:

    def http_error_default(self, url, fp, errcode, errmsg, 
headers):
        """Default error handling -- don't raise an exception."""
        return addinfourl(fp, headers, "http:" + url)

I don't see how this is really all that desirable, but 
nevertheless it appears to be quite deliberate.

It looks like the intent in urlopen is that if you want to use 
some other opener besides an instance of FancyURLopener, 
you can set urllib._urlopener. This seems to work:

>>> import urllib
>>> class MyUrlOpener(urllib.FancyURLopener):
...     def http_error_default(*args, **kwargs):
...         return urllib.URLopener.http_error_default(*args, 
**kwargs)
... 
>>> urllib._urlopener = MyUrlOpener()
>>> urllib.urlopen('http://www.example.com/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib.py", line 76, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.3/urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.3/urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.3/urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File "<stdin>", line 3, in http_error_default
  File "/usr/local/lib/python2.3/urllib.py", line 329, in 
http_error_default
    raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 404, 'Not Found', <httplib.HTTPMessage 
instance at 0x836298c>)

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 11:29

Message:
Logged In: YES 
user_id=89016

This seems to work with urllib2:
>>> import urllib2
>>> f = urllib2.urlopen('http://www.example.net/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib2.py", line 129, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.3/urllib2.py", line 326, in open
    '_open', req)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 901, in 
http_open
    return self.do_open(httplib.HTTP, req)
  File "/usr/local/lib/python2.3/urllib2.py", line 895, in do_open
    return self.parent.error('http', req, fp, code, msg, hdrs)
  File "/usr/local/lib/python2.3/urllib2.py", line 352, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 412, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 404: Not Found

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 20:23:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 20:26:58 2004
Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur
Message-ID: <E1BjMVm-0000q1-00@sc8-sf-web2.sourceforge.net>

Bugs item #570300, was opened at 2002-06-17 18:24
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Out of Date
>Priority: 3
Submitted By: Amit Aronovitch (amitar)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getmodule symlink-related failur

Initial Comment:
news:ae3e29$pib$1@news.netvision.net.il

Description:
--------------

  On a unix python2.2.1 installation I noticed that the 
documentations
generated for modules by pydoc (in any mode - even 
the help command) did NOT
contain any docs for functions.
  After some digging, I found out the reason for that, 
and now I believe it
indicates a deeper problem with the &quot;inspect&quot; module, 
concerning file
identification in the presence of symbolic or hard links, 
which I'll explain
below, and also suggest solutions.

Analysis:
-----------

  The reason the functions were dropped from the doc 
was pydoc's attempt to
remove functions which were imported from other 
modules. This is done by
something like &quot;inspect.getmodule(my_func) is 
my_module&quot;. I found out that
inspect.getmodule() returned &quot;None&quot; for these 
functions!

  Now, inspect.getmodule works by getting the 
function's filename, and then
searching it in a dictionary containing the filenames for 
all the modules
that were loaded (&quot;modulesbyfile&quot;). Unfortunately, the 
filename that
getabsfile() returns for the function is not the same 
STRING as the one it
returns for the module, but rather an equivalent unix 
path pointing to the
same FILE
(the reason for this fact is that the filename for a 
function is extracted
from the code-object, which holds the path the module 
was referred to at the
time it was COMPILED to .pyc, whereas the one for 
the module is taken from
it's __file__, which holds the path it was referred to 
when it was
IMPORTED - these two might differ even if it's the 
same file).

 So, the function's file is not found on the dictionary, 
and getmodule()
returns None...

Discussion:
--------------

  We see that the root cause of the problem is 
that &quot;inspect&quot; uses the
&quot;absolute path&quot; (os.path.abspath()) for representing 
the file's identity.
In unix systems, this might cause a problem, since 
this string is NOT unique
(it is a unique path, but different paths may refer to 
the same file).
If we only considered symbolic links, this could be 
resolved by scanning the
path elements and &quot;unfolding&quot; any symlinks, but we 
must recall that unix can
also has &quot;hard links&quot; which are equivalent references to 
the same inode, and
can't be discriminated.

  So, if we want to resolve the problem in a portable 
way, we need an
immutable (platform-dependant) object that will be 
unique to a FILE. This
object could then be used for comparing files and as 
keys for dictionaries.
 A reasonable way to get it would be by means of a 
new function in the os
module. e.g. :

 id = os.get_fileid(filename)
def samefile(f1,f2): return os.get_fileid(f1) is 
os.get_fileid(f2)

 This function could be implemented by the inode 
number (os.stat(f).st_ino)
on unix systems, and by the absolute path 
(os.path.abspath) on systems which
do not support links (such as windows), or by 
anything else, as long as it
would be immutable and unique for each file.


  Please let me know your opinion about this 
suggestion,

       Amit Aronovitch



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 11:23

Message:
Logged In: YES 
user_id=357491

Well, looks like this problem has gone away, at least in 2.4.  Closing out 
outdated.

----------------------------------------------------------------------

Comment By: Amit Aronovitch (amitar)
Date: 2003-05-18 13:10

Message:
Logged In: YES 
user_id=564711

Sorry - seems like I forgot most basic step in prob-
reporting - the &quot;howtorepeat&quot; :-) - so here it comes:

How to repeat:
----------------------
(as I said - you need unix &amp; symlinks to see this happening):

~&gt; mkdir test
~&gt; setenv PYTHONPATH ~/test
~&gt; cat &gt;test/test_mod.py
&quot;module doc&quot;
def blah():
   &quot;hello&quot;
   pass
^D
~&gt; python
&gt;&gt; import test_mod
&gt;&gt; help(test_mod)
&gt;&gt; ^D
[ Prints help - so far so good - no problem - but see now]

~&gt; ln -s test test2
~&gt; setenv PYTHONPATH test2
~&gt; python
&gt;&gt; import test_mod
&gt;&gt; help(test_mod)
[ Now the help shows up without the help of the blah 
function]

Relating the example to my explanations above:
------------------------------------------------------------------------
The help of the blah() function is filtered out, 
because &quot;inspect&quot; takes &quot;~/test/test_mod.pyc&quot; as it's 
filename, and &quot;~/test1/test_mod.pyc&quot; as the module's 
filename. It can't tell that these are the same file (see 
details in my &quot;Analysis&quot; section above).

  True, this messing up with symlinks and PYTHONPATH is 
a bit ugly, but this is just to demonstrate the problem. The 
system where I noticed it is quite complex, with disks 
shared (automounted) across several platforms, and it 
needs a few symlinks to make things easyer to maintain.
  As I explained, I think that few little changes in modules 
such as &quot;inspect&quot; and &quot;os&quot; can make them identify files 
better in the presence of links.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-16 19:34

Message:
Logged In: YES 
user_id=357491

Just tested under 2.2.2 and 2.3b1 using a module containing just::

 def blah():
    &quot;&quot;&quot;Hello&quot;&quot;&quot;&quot;
    pass

Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the 
name of the function and its docstring.  Am I missing something here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 20:35:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 20:35:06 2004
Subject: [ python-Bugs-982049 ] Relative Path causing crash in
	RotatingFileHandler
Message-ID: <E1BjMgg-0002GQ-00@sc8-sf-web1.sourceforge.net>

Bugs item #982049, was opened at 2004-06-29 17:34
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982049&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David London (groodude)
Assigned to: Vinay Sajip (vsajip)
Summary: Relative Path causing crash in RotatingFileHandler

Initial Comment:
When using the RotatingFileHandler class, if the
working directory is changed after the logging is setup
and a relative file name has been used to set up the
handler, python will crash when a rollover is attempted.
In my application, I set up the logger first (using a
config file) and then I start reading the config file
for the application. This is done so that I can log any
errors found within the application config file.
However, if a certain option is set, then the
application has to change the working directory. But
since the file name that I have included is relative,
when the logger attempts to rollover the file, it
crashes since the log file can no longer be found
within the current directory. 

Is this the desired behaviour (i.e. does the logger
expect to have absolute paths)? If so, this would be a
good thing to add to the documentation (along with an
example of a RotatingFileHandler configuration in
section 6.28.7.2).
It seems to make more sense that when a file name is
passed in, the absolute path be stored.

Even if this is the desired behaviour, I think that an
example of the RotatingFileConfig handler should be
included in the configuration section, complete with
values for the maxbytes and the number of back ups.


----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-10 19:35

Message:
Logged In: YES 
user_id=113328

I've just checked, and this has now been applied in CVS -
should the bug be closed?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-08 10:43

Message:
Logged In: YES 
user_id=308438

No, it's not the desired behaviour. I will put a fix into CVS: in 
the package's __init__.py, change the line in 
FileHandler.__init__ to

        self.baseFilename = os.path.abspath(filename)

and the RotatingFileHandler will then use absolute paths for 
its log files.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-08 02:38

Message:
Logged In: YES 
user_id=33168

Vinay, do you have any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982049&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 20:39:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 20:39:18 2004
Subject: [ python-Bugs-947571 ] urllib.urlopen() fails to raise exception
Message-ID: <E1BjMki-0003qV-00@sc8-sf-web3.sourceforge.net>

Bugs item #947571, was opened at 2004-05-04 02:57
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen() fails to raise exception

Initial Comment:
I've come across a strange problem: even though
the docs say that urllib.urlopen() should raise an IOError
for server errors (e.g. 404s), all versions of Python that
I've tested (1.5.2 - 2.3) fail to do so.

Example:
>>> import urllib
>>> f =
urllib.urlopen('http://www.example.net/this-url-does-not-exist/')
>>> print f.read()
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /this-url-does-not-exist/ was not
found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.27 Server at www.example.com Port
80</ADDRESS>
</BODY></HTML>

Either the docs are wrong or the implementation has a
really long standing bug or I am missing something.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 11:39

Message:
Logged In: YES 
user_id=371366

I suppose I could've made that example a little simpler:

class ErrorRecognizingURLopener(urllib.FancyURLopener):
    http_error_default = urllib.URLopener.http_error_default

urllib._urlopener = ErrorRecognizingURLopener()


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 11:25

Message:
Logged In: YES 
user_id=371366

In urllib.FancyURLopener, which is the class used by 
urllib.urlopen(), there is this override of URLopener's 
http_error_default:

    def http_error_default(self, url, fp, errcode, errmsg, 
headers):
        """Default error handling -- don't raise an exception."""
        return addinfourl(fp, headers, "http:" + url)

I don't see how this is really all that desirable, but 
nevertheless it appears to be quite deliberate.

It looks like the intent in urlopen is that if you want to use 
some other opener besides an instance of FancyURLopener, 
you can set urllib._urlopener. This seems to work:

>>> import urllib
>>> class MyUrlOpener(urllib.FancyURLopener):
...     def http_error_default(*args, **kwargs):
...         return urllib.URLopener.http_error_default(*args, 
**kwargs)
... 
>>> urllib._urlopener = MyUrlOpener()
>>> urllib.urlopen('http://www.example.com/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib.py", line 76, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.3/urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.3/urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.3/urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File "<stdin>", line 3, in http_error_default
  File "/usr/local/lib/python2.3/urllib.py", line 329, in 
http_error_default
    raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 404, 'Not Found', <httplib.HTTPMessage 
instance at 0x836298c>)

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 11:29

Message:
Logged In: YES 
user_id=89016

This seems to work with urllib2:
>>> import urllib2
>>> f = urllib2.urlopen('http://www.example.net/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib2.py", line 129, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.3/urllib2.py", line 326, in open
    '_open', req)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 901, in 
http_open
    return self.do_open(httplib.HTTP, req)
  File "/usr/local/lib/python2.3/urllib2.py", line 895, in do_open
    return self.parent.error('http', req, fp, code, msg, hdrs)
  File "/usr/local/lib/python2.3/urllib2.py", line 352, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 412, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 404: Not Found

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 20:41:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 20:41:49 2004
Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX
Message-ID: <E1BjMmY-0001PN-00@sc8-sf-web2.sourceforge.net>

Bugs item #728330, was opened at 2003-04-27 09:21
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470

Category: Installation
Group: Python 2.3
Status: Closed
Resolution: Remind
Priority: 9
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Don't define _SGAPI on IRIX

Initial Comment:
Python release:
  2.3b1
Platform:
  IRIX 6.5
  MIPSpro Compilers: Version 7.3.1.2m
Commands used:
  ./configure --prefix=/usr/local_cci/Python-2.3b1t
  make

The socket module fails to compile. The output from 
the compiler is attached.


----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2004-07-10 18:41

Message:
Logged In: YES 
user_id=22785

This seems to break the building of CVS HEAD sources on
windows with VC++ 6 because addrinfo.h is not included and
HAVE_GETADDRINFO is not defined in my build.  It also may
break on other platforms where HAVE_GETADDRINFO is not
defined.  Maybe addrinfo.h should be included if not on sgi.

I know that VC++ 6 isn't the primary compiler for Python
2.4, but it works otherwise and it presumably will be the
primary compiler for 2.3.5.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-05-27 10:28

Message:
Logged In: YES 
user_id=6656

Closing!

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-05-27 07:17

Message:
Logged In: YES 
user_id=29957

There's a note on the 2.3.4 bugs page pointing at this bug.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-05-27 05:41

Message:
Logged In: YES 
user_id=29957

If the patch is good, I'll make sure it's included in the
2.3.4 'bugs' page.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-05-27 04:14

Message:
Logged In: YES 
user_id=71407

> Can you try gmake?

Yes, it works with gmake. I've verified that the socket 
module on the CVS head builds and runs correctly on the 
three platforms mentioned in my message from 2004-05-
22 01:23. There are not even warnings.

> Is IRIX make particularly braindead?

I don't think so. It works with most auto-configured 
packages incl. all earlier versions of Python. But I'll save 
this for another day when the first 2.4 beta release is 
out.

Thank you for your help! I think this tracker issue should 
be closed.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-05-26 18:19

Message:
Logged In: YES 
user_id=6656

Uh, that's odd.  Is IRIX make particularly braindead?

Can you try gmake?  Maybe we've let something non-portable slip 
in.  At any rate, I think this should be done in a separate report...

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-05-26 18:14

Message:
Logged In: YES 
user_id=71407

I checked out the python cvs head from scratch and ran 
configure in the usual way, with the usual result. 
However, make doesn't work:

% make
don't know how to make Parser/printgrammar.o (bu42).


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-05-26 17:07

Message:
Logged In: YES 
user_id=6656

OK, so I've commited revision 1.289 of Modules/socketmodule.c.

Can you check if CVS HEAD works for you now?

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-05-26 16:59

Message:
Logged In: YES 
user_id=71407

> Is there any chance of the Right Thing actually 
happening?

The experience of the last 13 months suggests "No." 
SGI's freeware team has not responded to my report for 
more than a year. I am absolutely not a SGI or socket 
expert. I only worked on the patch because I was 
desperate enough and because Maik had already done 
the groundwork.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-05-26 16:27

Message:
Logged In: YES 
user_id=6656

Is this really The Right Thing?  I still see

  /* XXX Using _SGIAPI is the wrong thing, 
     but I don't know what the right thing is. */

Is there any chance of the Right Thing actually happening?  If not, 
I'll check this into HEAD, and if that seems to work, move it to 
release23-maint in time for 2.3.5.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2004-05-22 08:23

Message:
Logged In: YES 
user_id=71407

Based on Maik's posting from 2004-03-08 08:53 I've 
worked out a small
bug-fix patch relative to Python-2.3.4c1 that leads to 
successful
creation of _socket.so under three different versions of 
IRIX:

    6.5.10 with MIPSpro 7.3.1.2
    6.5.21 with MIPSpro 7.41
    6.5.23 with MIPRpro 7.3.1.3

I've consistently used

    #if defined(__sgi) && _COMPILER_VERSION>700 

to restrict the changes to IRIX. However, to be sure I've 
also verified
that the Python installation is still OK under Redhat 8 
and Tru64 Unix
5.1.

I will upload the patch. It is also available here:

    
http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod
ule_patch

For completeness I've also posted these files:

    
http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod
ule_patched_c
    
http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod
ule_original_c

I've made an effort to keep the patch minimally 
intrusive, but it is
certainly not "clean." However, the status quo is so bad 
that it can
only get better. We have not been able to switch to 
Python 2.3 because
of the problems with the socket module. It would be 
fantastic if
the bug-fix patch could be included in the 2.3.4 final 
distribution.


----------------------------------------------------------------------

Comment By: Maik Hertha (mhertha)
Date: 2004-03-08 16:53

Message:
Logged In: YES 
user_id=768223

I got Python 2.3.3 compiled with MipsPro Compilers: Version
7.3.1.3m. The following changes were made to satisfy all needs.
Line 206 in Modules/socketmodule.c
#define _SGIAPI 1

NEW: #undef _XOPEN_SOURCE
NEW: #define HAVE_GETADDRINFO 1
NEW: #define HAVE_GETNAMEINFO 1

#define HAVE_INET_PTON
NEW: #include <sys/types.h>
NEW: #include <sys/socket.h>
NEW: #include <netinet/in.h>
#include <netdb.h>

Line 269:
/* #include "addrinfo.h" */

In addition to this I extend the CFLAGS with -D_BSD_TYPES to
satisfy the u_short and friends definition.
--maik./

----------------------------------------------------------------------

Comment By: Bill Baxter (billbaxter26)
Date: 2004-03-03 16:20

Message:
Logged In: YES 
user_id=892601

Got it down to one error:
% > ./python Lib/test/test_socket.py
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 6, in ?
    import socket
  File "/usr/local/spider/lib/python2.3/socket.py", line 44,
in ?
    import _socket
ImportError: 210454:./python: rld: Fatal Error: unresolvable
symbol in
/usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so:
_xpg5_accept

xpg5_accept does appear in any library on our SGI's that are
only 1-2 years old. It does appear in libc in very recent
revisions of Irix (> 6.5.19?)

Does anyone know how to get Python 2.3 to avoid the use of
xpg5_accept?

Thanks


----------------------------------------------------------------------

Comment By: Bill Baxter (billbaxter26)
Date: 2004-01-12 18:59

Message:
Logged In: YES 
user_id=892601

Has anyone encountered problems with different versions of
IRIX 6.5? I finally got sockets to work in Python2.3.3, but
only on the most up-to-date version of IRIX (uname -v =
01100304). On any other machine with a lower version
(archetecture doesn't seem to matter), I get messages which
all seem to be related to sockets:

152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_vsnprintf
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_recv
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_connect
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_bind
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_getsockopt
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_sendto
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_setsockopt
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_accept
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_recvfrom
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_socket
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_getsockname

Upgrading all of our SGIs is not something I have control
over.


----------------------------------------------------------------------

Comment By: Maik Hertha (mhertha)
Date: 2003-12-22 18:52

Message:
Logged In: YES 
user_id=768223

Sorry if there is something unclear.
Redefine means: Set a value which is required to satisfy
ifdef-statements in the header files. As you see in the
definitions, given in the comment, the value for _NO_XOPEN4
is set as a result of some dependencies automatically
defined. A redefinition of _SGIAPI in the socketmodule.c is
not sufficient alone. Therefore to satisfy all requirements
in the header files, you should set the values for
_NO_XOPEN4 and _NO_XOPEN5 also manually.
Howto do in socketmodule.c?
...
#define _SGIAPI 1
#define _NO_XOPEN4 1
#define _NO_XOPEN5 1
...
If you are familiar with regular expressions, then you will
know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4,
_NO_XOPEN5.

Sorry if there was something wrong in my comment.

----------------------------------------------------------------------

Comment By: Bill Baxter (billbaxter26)
Date: 2003-12-22 15:49

Message:
Logged In: YES 
user_id=892601

Can someone please clarify mherta's comment from 2003-12-16?

How should we &quot;redefine _NO_XOPEN[45] in the socketmodule.c
at the same position like the _SGIAPI redefinition&quot;?

Should those lines of code be added to socketmodule.c, or
are they the source of the problem?

Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5]
or are they all different?

Thanks.

----------------------------------------------------------------------

Comment By: Maik Hertha (mhertha)
Date: 2003-12-16 17:27

Message:
Logged In: YES 
user_id=768223

I've tested the latest Python 2.3.3c1 to compile. The
problem reported is still present. To avoid the error
messages, about the incompatible types of several
netdb-functions (like inet_pton), you should redefine
_NO_XOPEN[45] in the socketmodule.c at the same position
like the _SGIAPI redefinition. If there are error messages
that types like u_short and u_char are not defined, please
add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay).
If anybody don't need a executable compiled with MipsPro,
gcc from the freeware.sgi.com could be a choice.
The problem for this seems in /usr/include/standards.h:
#define _NO_XOPEN4	(!defined(_XOPEN_SOURCE) || 				(defined(_XOPEN_SOURCE) &amp;&amp; 				(_XOPEN_SOURCE+0 &gt;= 500)))
#define _NO_XOPEN5	(!defined(_XOPEN_SOURCE) || 				(defined(_XOPEN_SOURCE) &amp;&amp; 				(_XOPEN_SOURCE+0 &lt; 500)))
As the first option is true (_XOPEN_SOURCE is set to 600 in
pyconfig.h) the second option will be false. The constant
#define NI_NUMERICHOST  0x00000002  /* return numeric form
of hostname */
is enveloped in a clause #ifdef _NO_XOPEN4 &amp;&amp; _NO_XOPEN5
(/usr/include/netdb.h) which is always false.
In the manual pages there is a example which uses the
constant NI_NUMERICHOST and compiles without error message.
I'm not sure to cut off the file pyconfig.h from compiling
the socketmodule.c?

Any comments?

----------------------------------------------------------------------

Comment By: Hans Nowak (zephyrfalcon)
Date: 2003-10-31 03:04

Message:
Logged In: YES 
user_id=173607

My $0.02...

Yesterday I successfully compiled Python 2.3.2, with socket
module. I'm using an O2 running IRIX 6.5.11f.

I didn't encounter any of the problems described before, and
had no problems with _SGIAPI or anything. The reason it
didn't compile was that u_long and u_char were not defined
in some places; /usr/include/netinet/tcp.h to be precise,
and a Python file (getaddrinfo.c).

I'm using gcc 3.3 (the one downloaded from freeware.sgi.com).

If anyone is interested, drop me a mail at hans at
zephyrfalcon.org and I'll put the binary online somewhere.

----------------------------------------------------------------------

Comment By: Bill Baxter (billbaxter26)
Date: 2003-10-24 19:59

Message:
Logged In: YES 
user_id=892601

Here's the output from 'gmake', using MIPSpro Compiler 7.30
on IRIX 6.5

Sorry, I don't know how to attach something using the &quot;Add a
Comment&quot; box. Is there another way to post?

The patch at
www.python.org/2.3.2/patches/sgi-socketmodule.patch was
edited into socketmodule.c :
#include &lt;netdb.h&gt;
#endif

/* GCC 3.2 on Irix 6.5 fails to define this variable at all.
Based on 
   the above code, I'd say that the SGI headers are just
horked. */
#if defined(__sgi) &amp;&amp; !defined(INET_ADDRSTRLEN)
#define INET_ADDRSTRLEN 16
#endif

/* Generic includes */
#include &lt;sys/types.h&gt;
#include &lt;signal.h&gt;


---------------------------------------------------------------------------

cc -OPT:Olimit=0 -DNDEBUG  -n32 -O -I. -I./Include 
-DPy_BUILD_CORE  -c ./Modules/socketmodule.c -o
Modules/socketmodule.o
cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line =
195
  Macro &quot;_SGIAPI&quot; (declared at line 210 of
&quot;/usr/include/standards.h&quot;) has an
          incompatible redefinition.

  #define _SGIAPI 1
          ^

cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198
  The identifier &quot;socklen_t&quot; is undefined.

  extern int iruserok_sa(const void *, socklen_t, int, const
char *,
                                       ^

cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145
  Macro &quot;_SS_ALIGNSIZE&quot; (declared at line 246 of
&quot;/usr/include/sys/socket.h&quot;)
          has an incompatible redefinition.

  #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG))
          ^

cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line =
822
  The identifier &quot;NI_NUMERICHOST&quot; is undefined.

                NI_NUMERICHOST);
                ^

cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line =
3054
  A value of type &quot;int&quot; cannot be assigned to an entity of
type &quot;const char *&quot;.

        retval = inet_ntop(af, packed, ip, sizeof(ip));
               ^

3 errors detected in the compilation of
&quot;./Modules/socketmodule.c&quot;.
gmake: *** [Modules/socketmodule.o] Error 2


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-10-23 10:25

Message:
Logged In: YES 
user_id=6656

Just to be clear,  please &quot;attach&quot; the build rather than
pasting it inline.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-23 02:19

Message:
Logged In: YES 
user_id=29957

Did you try 2.3.2 with the patch from the 2.3.2 build bugs page?

If it failed, please post the build log of the failing bit
to this bug.
 

----------------------------------------------------------------------

Comment By: Bill Baxter (billbaxter26)
Date: 2003-10-22 18:26

Message:
Logged In: YES 
user_id=892601

Has there been any progress since August on getting
Python-2.3 to compile on IRIX 6.5? I really need to have
sockets working to use python.

----------------------------------------------------------------------

Comment By: Maik Hertha (mhertha)
Date: 2003-08-14 11:37

Message:
Logged In: YES 
user_id=768223

I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m
on a FUEL 600Mhz.
The situation seems a little bit strange on this system. But
I have luck and get it compiled. As the current
implementation is not clean, my resolution also. Which
should be changed to get it work.
The manpage for gethostbyaddr_r says:
#include &lt;sys/types&gt;
#include &lt;sys/socket&gt;
#include &lt;netinet/in.h&gt;
#include &lt;netdb.h&gt;
So I included this in the __sgi-clause in socketmodule.c.
Looking in the header-files shows, that some variables are
defined if 
#define _NO_XOPEN4 1
#define _NO_XOPEN5 1
are set, before the includes. This defines some more
variables, so that pyconfig.h should be changed.
#define HAVE_ADDRINFO 1
#define HAVE_SOCKADDR_STORAGE 1
Sure there are warnings about the redefinition of the
_(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests
don't fail. Also my applications run without exception or
coredump on FUEL, Octane, Octane 2.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-01 12:10

Message:
Logged In: YES 
user_id=33168

Ralf, I will try to work on this, but it won't be for a week
or two probably.  Can you tell me which machines (by name)
work and doesn't work.  The only IRIX machine I seem to know
about it rattler.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-08-01 07:34

Message:
Logged In: YES 
user_id=71407

For the records:
The Python2.3 (final) socket module still does not 
compile under IRIX 6.5.20. It only compiles under 6.5.10.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 18:07

Message:
Logged In: YES 
user_id=31392

I applied a slight variant of Neal's patch and that seemed
to fix things.  It still seems wrong that we define _SGIAPI,
but that will have to wait for 2.3.1.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 13:54

Message:
Logged In: YES 
user_id=31392

I learned a little about inet_ntop() in the last few
minutes.  It looks like the size_t argument is an older
spelling, and the current POSIX says it should be socklen_t.
 Regardless, it looks like we're using the new definition
when IRIX is actually providing the older definition.

Neal attached a patch that looks like it should clean up the
problem.  Have you tried it?  I think a better solution
would be to teach configure how to find inet_ntop() via
netdb.h, but that's probably too hard to get done in the new
couple of hours.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 13:42

Message:
Logged In: YES 
user_id=31392

There seem to be two causes of worry.  The actual compiler
error in your build log and the use of _SGIAPI that
Casavanti warns again.

It looks like the compiler problems is because our
inet_ntop() prototype is wrong.  That is Python says the
last argument is a socklen_t, but IRIX and Linux man pages
both say size_t.  Perhaps size_t and socklen_t are different
sizes on IRIX, but not on Linux.  What happens if you change
it to size_t?

The problematic code would appear to be these lines from
socketmodule.c:

#if defined(__sgi)&amp;&amp;_COMPILER_VERSION&gt;700 &amp;&amp; !_SGIAPI
/* make sure that the reentrant (gethostbyaddr_r etc)
   functions are declared correctly if compiling with
   MIPSPro 7.x in ANSI C mode (default) */
#define _SGIAPI 1
#include &quot;netdb.h&quot;
#endif

It's the only use the _SGIAPI symbol that Casavant says we
shouldn't use.  What happens if you remove the use _SGIAPI,
i.e. just make it

#if defined(__sgi) &amp;&amp; _COMPILER_VERSION &gt; 700 
/* make sure that the reentrant (gethostbyaddr_r etc)
   functions are declared correctly if compiling with
   MIPSPro 7.x in ANSI C mode (default) */
#include &quot;netdb.h&quot;
#endif


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-17 00:27

Message:
Logged In: YES 
user_id=71407

We have confirmed that the socket module in Python 2.3b1 
and 2.3b2 fails to compile under these versions of IRIX:

6.5.10, MIPSpro 7.3.1.2m
6.5.19, MIPSpro 7.3.1.3m
6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge)

If Python 2.3 goes out without a working socket module it 
will be useless for many people in science where IRIX is still 
found quite frequently. Maybe even worse, we will also no 
longer be able to advertise Python as a language that &quot;runs 
everywhere.&quot;


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-15 22:37

Message:
Logged In: YES 
user_id=71407

Date: Tue, 15 Jul 2003 15:06:25 -0500
From: &quot;Brent Casavant&quot; &lt;bcasavan@sgi.com&gt;
To: &quot;Ralf W. Grosse-Kunstleve&quot; &lt;rwgk@yahoo.com&gt; 
Subject: Re: IRIX &amp; Python 

Ralf,

I read through the sourceforge report.  I don't have a 
sourceforge
account so I didn't add there, but feel free to distribute my
ramblings.

First, they should be very careful about what version of the
operating system they are using.  Real IPv6 support was only
added a few releases ago (6.5.20 I believe, though my 
memory
is hazy).  Some of the functions/macros corresponding to 
IPv6
were introduced prior to that point, but implementation may
not have been complete.  If they have to play tricks with
#define values to get a symbol recongnized it most likely
means that SGI didn't intend for that symbol to be used yet.

I suspect the problems they are seeing are because they are
using some version of IRIX 6.5.x that includes inet_ntoa()
definitions under _SGIAPI, but for which real support was
not yet complete.  The namespace of symbols that begin 
with a
single underscore and a capital letter is reserved for the OS
vendors, and the fact that someone is trying to manually 
insert
a definition of _SGIAPI into the source should be a big red
warning flag.

That said, there is a correct method to deal with the new
capabilities of IRIX 6.5.x over time.  This comes in two
parts.  A better explanation is in /usr/include/optional_sym.h

First, when a new symbol is added to IRIX, the corresponding
header file will always have the following line in it:

	#pragma optional some_new_symbol

The presence of this #pragma will cause the linker to not
complain if the symbol is missing when the executable is
linked.  If SGI neglects to do so it is a bug that should
be reported to us.

The second part is that calls to these &quot;optional&quot; symbols
should be protected by a run-time check to see if the symbol
is actually present.  Just like this:

	#include &lt;optional_sym.h&gt;
	#include &lt;header_file_for_some_new_symbol.h&gt;

	. . .

	if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) {
		/* New function is present, use it */
		qux = some_new_symbol(foo, bar, baz);
	} else {
		/* New function isn't present, do 
something else */
		qux = builtin_some_new_symbol(foo, bar, 
baz);
	}

This ensures that a single executable will be able to function
properly (or at least degrade gracefully) on all version of
IRIX 6.5.x.  In other words you can compile on 6.5.20 and 
run
on 6.5.8, or vice versa.

In particular, this means that compile-time detection of 
features
such as inet_ntoa() is incorrect for IRIX 6.5.x -- these 
decisions
should be made at run-time instead.  If the decision is made 
at
compile time the executable may well not execute on an older
version of IRIX 6.5.x.  Unfortunately GNU configure is not 
equipped
to utilize such advanced binary-compatability mechanisms, 
so there's
no &quot;easy&quot; way to get GNU configure'd software to run across 
all
IRIX 6.5.x releases, short of compiling only on the original
non-upgraded version of IRIX 6.5.

Hope that helps,
Brent Casavant

On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote:

&gt; We are developing a Python-based (www.python.org) 
application for
&gt; IRIX. Until now the Python IRIX port was fully supported, 
but the last
&gt; two beta releases of Python (2.3b1 and 2.3b2) make me 
increasingly
&gt; worried because the crucial socket module (TCP/IP 
sockets) fails to
&gt; build. A while ago I've filed a bug report, but the Python 
developers
&gt; appear to be stuck:
&gt;
&gt; 
https://sourceforge.net/tracker/?
func=detail&amp;aid=728330&amp;group_id=5470&amp;atid=105470
&gt;
&gt; Is there a way to bring this to the attention of developers 
at SGI to
&gt; hopefully get some help?
&gt;
&gt; Thank you in advance!
&gt;       Ralf
&gt;

-- 
Brent Casavant      Silicon Graphics, Inc.  Where am I?  And 
what am I
IRIX O.S. Engineer  http://www.sgi.com/     doing in this 
handbasket?
bcasavan@sgi.com    44.8562N 93.1355W 860F      -- 
Unknown


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-06-30 14:21

Message:
Logged In: YES 
user_id=71407

The socket module still fails to compile with Python 
2.3b2, in addition to two other extensions. The full make 
log is attached.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-22 06:47

Message:
Logged In: YES 
user_id=21627

I think it would be best if detect presence of
inet_aton/inet_pton. Is IPv6 support possible on this
system? Then it would be best if that was detected, as well.

If it is not possible to detect aton/pton/ipv6, what is the
problem with not using them?

I'd like to have a look at the relevant headers (in
particular to understand the duplicate definition of
_SGIAPI), indeed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-21 23:35

Message:
Logged In: YES 
user_id=33168

Argh!!!  This is a nightmare.  The attached hack ^h^h^h
patch fixes the problem, but ...

_SGIAPI needs to be defined (~192 in socketmodule.c) in
order to get the prototypes for inet_aton, inet_pton.  But
_SGIAPI can't be defined in the standard header files
because XOPEN_SOURCE is defined.

Martin, do you have any other suggestions?  I don't see how
to do this right within configure.  If you want I can send
you the header file(s).

----------------------------------------------------------------------

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 17:41

Message:
Logged In: YES 
user_id=150999

I had the same problem compiling socket on Irix.
We did find that on our system ENABLE_IPV6 is not define and
all the error are cause by that.
  
System that do not enable IPV6 are not well supported with
the socketmodule.c code.
We were able to compile socket after making few change in
the code: 
I am not sure if I did it right but it compile.
I will post my patch but I do not see any place to attach my
file
example: See line 2794,2800

+ #ifdef ENABLE_IPV6
        char packed[MAX(sizeof(struct in_addr),
sizeof(struct in6_addr))];
+ #else
+       char packed[sizeof(struct in_addr)];
+ #endif

I am not sure how to post the patch or file.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-05-05 18:44

Message:
Logged In: YES 
user_id=71407

This is not in my area of expertise, but I've tried a couple of 
(probably stupid) things:

#include &lt;standards.h&gt; in socketmodule.c instead of #define 
_SGIAPI.
This resulted in even more errors.

./configure --disable-ipv6
Same errors as before.

I am lost here. Sorry. But you still have ssh access to 
rattler.lbl.gov if that helps. Accounts for other Python developers 
are a possibility.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-04 12:39

Message:
Logged In: YES 
user_id=21627

Can you analyse these compiler errors in more detail,
please? What, in your opinion, is causing these problems,
and how would you correct them?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 20:47:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 20:47:43 2004
Subject: [ python-Bugs-982049 ] Relative Path causing crash in
	RotatingFileHandler
Message-ID: <E1BjMsr-00043o-00@sc8-sf-web3.sourceforge.net>

Bugs item #982049, was opened at 2004-06-29 09:34
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982049&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David London (groodude)
Assigned to: Vinay Sajip (vsajip)
Summary: Relative Path causing crash in RotatingFileHandler

Initial Comment:
When using the RotatingFileHandler class, if the
working directory is changed after the logging is setup
and a relative file name has been used to set up the
handler, python will crash when a rollover is attempted.
In my application, I set up the logger first (using a
config file) and then I start reading the config file
for the application. This is done so that I can log any
errors found within the application config file.
However, if a certain option is set, then the
application has to change the working directory. But
since the file name that I have included is relative,
when the logger attempts to rollover the file, it
crashes since the log file can no longer be found
within the current directory. 

Is this the desired behaviour (i.e. does the logger
expect to have absolute paths)? If so, this would be a
good thing to add to the documentation (along with an
example of a RotatingFileHandler configuration in
section 6.28.7.2).
It seems to make more sense that when a file name is
passed in, the absolute path be stored.

Even if this is the desired behaviour, I think that an
example of the RotatingFileConfig handler should be
included in the configuration section, complete with
values for the maxbytes and the number of back ups.


----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-10 11:35

Message:
Logged In: YES 
user_id=113328

I've just checked, and this has now been applied in CVS -
should the bug be closed?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-08 02:43

Message:
Logged In: YES 
user_id=308438

No, it's not the desired behaviour. I will put a fix into CVS: in 
the package's __init__.py, change the line in 
FileHandler.__init__ to

        self.baseFilename = os.path.abspath(filename)

and the RotatingFileHandler will then use absolute paths for 
its log files.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 18:38

Message:
Logged In: YES 
user_id=33168

Vinay, do you have any comments?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982049&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 20:55:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 20:55:25 2004
Subject: [ python-Bugs-450803 ] smtpd.py needs documentation
Message-ID: <E1BjN0L-0004Hc-00@sc8-sf-web3.sourceforge.net>

Bugs item #450803, was opened at 2001-08-14 10:18
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Barry A. Warsaw (bwarsaw)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: smtpd.py needs documentation

Initial Comment:
smtpd.py needs documentation for the standard library

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 14:55

Message:
Logged In: YES 
user_id=99874

I think moshez's text may be minimal but it's way better
than having NO docs. So I propose we accept it as-is: we can
always improve things later. With that in mind, I am
re-assigning this to Fred, and I've also revised moshez's
attachment slightly. Add this file as smptd.tex in
python/dist/src/Doc/lib and it should work. (I've made it
pass texcheck.py, there could still be some higher-level tex
errors.)

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2002-06-11 05:48

Message:
Logged In: YES 
user_id=11645

Here's something you can use as a start, Barry.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 21:08:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 21:08:19 2004
Subject: [ python-Bugs-947571 ] urllib.urlopen() fails to raise exception
Message-ID: <E1BjNCn-0002Gl-00@sc8-sf-web2.sourceforge.net>

Bugs item #947571, was opened at 2004-05-04 10:57
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen() fails to raise exception

Initial Comment:
I've come across a strange problem: even though
the docs say that urllib.urlopen() should raise an IOError
for server errors (e.g. 404s), all versions of Python that
I've tested (1.5.2 - 2.3) fail to do so.

Example:
>>> import urllib
>>> f =
urllib.urlopen('http://www.example.net/this-url-does-not-exist/')
>>> print f.read()
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /this-url-does-not-exist/ was not
found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.27 Server at www.example.com Port
80</ADDRESS>
</BODY></HTML>

Either the docs are wrong or the implementation has a
really long standing bug or I am missing something.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-10 20:08

Message:
Logged In: YES 
user_id=261020

Seems a mistake to change this now.  The current behaviour
should be documented, though, of course.


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 19:39

Message:
Logged In: YES 
user_id=371366

I suppose I could've made that example a little simpler:

class ErrorRecognizingURLopener(urllib.FancyURLopener):
    http_error_default = urllib.URLopener.http_error_default

urllib._urlopener = ErrorRecognizingURLopener()


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 19:25

Message:
Logged In: YES 
user_id=371366

In urllib.FancyURLopener, which is the class used by 
urllib.urlopen(), there is this override of URLopener's 
http_error_default:

    def http_error_default(self, url, fp, errcode, errmsg, 
headers):
        """Default error handling -- don't raise an exception."""
        return addinfourl(fp, headers, "http:" + url)

I don't see how this is really all that desirable, but 
nevertheless it appears to be quite deliberate.

It looks like the intent in urlopen is that if you want to use 
some other opener besides an instance of FancyURLopener, 
you can set urllib._urlopener. This seems to work:

>>> import urllib
>>> class MyUrlOpener(urllib.FancyURLopener):
...     def http_error_default(*args, **kwargs):
...         return urllib.URLopener.http_error_default(*args, 
**kwargs)
... 
>>> urllib._urlopener = MyUrlOpener()
>>> urllib.urlopen('http://www.example.com/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib.py", line 76, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.3/urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.3/urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.3/urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File "<stdin>", line 3, in http_error_default
  File "/usr/local/lib/python2.3/urllib.py", line 329, in 
http_error_default
    raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 404, 'Not Found', <httplib.HTTPMessage 
instance at 0x836298c>)

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 19:29

Message:
Logged In: YES 
user_id=89016

This seems to work with urllib2:
>>> import urllib2
>>> f = urllib2.urlopen('http://www.example.net/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib2.py", line 129, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.3/urllib2.py", line 326, in open
    '_open', req)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 901, in 
http_open
    return self.do_open(httplib.HTTP, req)
  File "/usr/local/lib/python2.3/urllib2.py", line 895, in do_open
    return self.parent.error('http', req, fp, code, msg, hdrs)
  File "/usr/local/lib/python2.3/urllib2.py", line 352, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 412, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 404: Not Found

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 21:20:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 21:20:19 2004
Subject: [ python-Bugs-679953 ] zipfile.py - pack filesize as unsigned
	allows files &gt; 2 gig
Message-ID: <E1BjNOQ-0004uh-00@sc8-sf-web3.sourceforge.net>

Bugs item #679953, was opened at 2003-02-03 17:54
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=679953&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jimmy Burgett (laurelboa)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile.py - pack filesize as unsigned allows files &gt; 2 gig

Initial Comment:
Python 2.2.2 
Windows XP (all serice packs installed)
Windows 2000 (all service packs installed)

The filesize and compressed file size numbers in the zip 
header need to &quot;struct.packed&quot; as unsigned ints, not 
signed ints. This allows zipfile.py to compress files 
greater than 2 gigabytes in size. Currently, an attempt 
to compress such a large file gives you this error:

Traceback (most recent call last):
  File &quot;&lt;interactive input&gt;&quot;, line 1, in ?
  File &quot;C:\Python22\lib\zipfile.py&quot;, line 426, in write
    zinfo.file_size))
OverflowError: long int too large to convert to int

where the line in question is:
self.fp.write(struct.pack(&quot;&lt;lll&quot;, zinfo.CRC, 
zinfo.compress_size,
     zinfo.file_size))

I believe that the four changes below are all that is 
needed. This is from version 2.2.2, but zipfile.py in 2.3a1 
still had the file size packed/unpacked as a signed 
integer.

I have not tested whether the ziplib routines can seek 
past the 2 gig boundary in order to extract a file whose 
beginning is past the 2 gig boundary. My application 
requires compressing very large files one at a time and 
zipfile.py lets me use either WinZip or the built-in 
Windows &quot;unzip&quot; function for extraction.
These changes allow that use.

-------------- Change Line #28

# Here are some struct module formats for reading 
headers
structEndArchive = &quot;&lt;4s4H2lH&quot;     # 9 items, end of 
archive, 22 bytes
stringEndArchive = &quot;PK\005\006&quot;   # magic number for 
end of archive record
structCentralDir = &quot;&lt;4s4B4H3l5H2l&quot;# 19 items, central 
directory, 46 bytes

to

structCentralDir = &quot;&lt;4s4B4HlLL5H2L&quot;# 19 items, central 
directory, 46 bytes

--------------- change line #306

    def printdir(self):
        &quot;&quot;&quot;Print a table of contents for the zip file.&quot;&quot;&quot;
        print &quot;%-46s %19s %12s&quot; % (&quot;File 
Name&quot;, &quot;Modified    &quot;, &quot;Size&quot;)
        for zinfo in self.filelist:
            date = &quot;%d-%02d-%02d %02d:%02d:%02d&quot; % 
zinfo.date_time
            print &quot;%-46s %s %12d&quot; % (zinfo.filename, date, 
zinfo.file_size)
to 
            print &quot;%-46s %s %12u&quot; % (zinfo.filename, date, 
zinfo.file_size)


---------------- change line #425

        # Seek backwards and write CRC and file sizes
        position = self.fp.tell()       # Preserve current 
position in file
        self.fp.seek(zinfo.header_offset + 14, 0)
        self.fp.write(struct.pack(&quot;&lt;lll&quot;, zinfo.CRC, 
zinfo.compress_size,
              zinfo.file_size))
to
        self.fp.write(struct.pack(&quot;&lt;lLL&quot;, zinfo.CRC, 
zinfo.compress_size,
              zinfo.file_size))

---------------- change line #450
        if zinfo.flag_bits &amp; 0x08:
            # Write CRC and file sizes after the file data
            self.fp.write(struct.pack(&quot;&lt;lll&quot;, zinfo.CRC, 
zinfo.compress_size,
                  zinfo.file_size))

to
            self.fp.write(struct.pack(&quot;&lt;lLL&quot;, zinfo.CRC, 
zinfo.compress_size,
                  zinfo.file_size))


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 12:20

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 1.33 for Python 2.4.a2 and rev. 1.31.8.1 for Python 2.3.5 .  
Thanks, Jimmy.  Just added to your fixes but they did help.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=679953&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 21:20:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 21:20:22 2004
Subject: [ python-Bugs-947571 ] urllib.urlopen() fails to raise exception
Message-ID: <E1BjNOQ-0004ul-00@sc8-sf-web3.sourceforge.net>

Bugs item #947571, was opened at 2004-05-04 02:57
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen() fails to raise exception

Initial Comment:
I've come across a strange problem: even though
the docs say that urllib.urlopen() should raise an IOError
for server errors (e.g. 404s), all versions of Python that
I've tested (1.5.2 - 2.3) fail to do so.

Example:
>>> import urllib
>>> f =
urllib.urlopen('http://www.example.net/this-url-does-not-exist/')
>>> print f.read()
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /this-url-does-not-exist/ was not
found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.27 Server at www.example.com Port
80</ADDRESS>
</BODY></HTML>

Either the docs are wrong or the implementation has a
really long standing bug or I am missing something.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 12:20

Message:
Logged In: YES 
user_id=371366

I suggest closing as Won't Fix or Not A Bug, but change the 
documentation for urllib.urlopen() to read:

    """urlopen(url [, data]) -> open file-like object
    using urllib._urlopener, which will be an instance of
    FancyURLopener if not already set."""

The onus is still on the user to notice in the docs that 
FancyURLopener will ignore HTTP error responses for which it 
does not have an explicit handler, but at least this way they'll 
at least be pointed in the right direction.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-10 12:08

Message:
Logged In: YES 
user_id=261020

Seems a mistake to change this now.  The current behaviour
should be documented, though, of course.


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 11:39

Message:
Logged In: YES 
user_id=371366

I suppose I could've made that example a little simpler:

class ErrorRecognizingURLopener(urllib.FancyURLopener):
    http_error_default = urllib.URLopener.http_error_default

urllib._urlopener = ErrorRecognizingURLopener()


----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-07-10 11:25

Message:
Logged In: YES 
user_id=371366

In urllib.FancyURLopener, which is the class used by 
urllib.urlopen(), there is this override of URLopener's 
http_error_default:

    def http_error_default(self, url, fp, errcode, errmsg, 
headers):
        """Default error handling -- don't raise an exception."""
        return addinfourl(fp, headers, "http:" + url)

I don't see how this is really all that desirable, but 
nevertheless it appears to be quite deliberate.

It looks like the intent in urlopen is that if you want to use 
some other opener besides an instance of FancyURLopener, 
you can set urllib._urlopener. This seems to work:

>>> import urllib
>>> class MyUrlOpener(urllib.FancyURLopener):
...     def http_error_default(*args, **kwargs):
...         return urllib.URLopener.http_error_default(*args, 
**kwargs)
... 
>>> urllib._urlopener = MyUrlOpener()
>>> urllib.urlopen('http://www.example.com/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib.py", line 76, in urlopen
    return opener.open(url)
  File "/usr/local/lib/python2.3/urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.3/urllib.py", line 306, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers)
  File "/usr/local/lib/python2.3/urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File "<stdin>", line 3, in http_error_default
  File "/usr/local/lib/python2.3/urllib.py", line 329, in 
http_error_default
    raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 404, 'Not Found', <httplib.HTTPMessage 
instance at 0x836298c>)

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 11:29

Message:
Logged In: YES 
user_id=89016

This seems to work with urllib2:
>>> import urllib2
>>> f = urllib2.urlopen('http://www.example.net/this-url-does-
not-exist/')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/urllib2.py", line 129, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.3/urllib2.py", line 326, in open
    '_open', req)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 901, in 
http_open
    return self.do_open(httplib.HTTP, req)
  File "/usr/local/lib/python2.3/urllib2.py", line 895, in do_open
    return self.parent.error('http', req, fp, code, msg, hdrs)
  File "/usr/local/lib/python2.3/urllib2.py", line 352, in error
    return self._call_chain(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 306, in 
_call_chain
    result = func(*args)
  File "/usr/local/lib/python2.3/urllib2.py", line 412, in 
http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 404: Not Found

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947571&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 21:20:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 21:20:52 2004
Subject: [ python-Bugs-988602 ] Move urllib2 functional tests into test suite
Message-ID: <E1BjNOv-0002dx-00@sc8-sf-web2.sourceforge.net>

Bugs item #988602, was opened at 2004-07-10 20:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988602&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Move urllib2 functional tests into test suite

Initial Comment:
People keep forgetting to run the tests that live in
the if __name__ == "__main__" block of urllib2, so this
patch moves them into the main test suite.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988602&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 21:23:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 21:23:07 2004
Subject: [ python-Bugs-664715 ] Demo/dbm.py - Rewrite using anydbm?
Message-ID: <E1BjNR7-000109-00@sc8-sf-web4.sourceforge.net>

Bugs item #664715, was opened at 2003-01-08 14:14
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664715&group_id=5470

Category: Demos and Tools
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Demo/dbm.py - Rewrite using anydbm?

Initial Comment:
It may be a good idea to rewrite Demo/Dbm.py to use anydbm, which is available on all platforms.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 12:23

Message:
Logged In: YES 
user_id=357491

The file doesn't exist anymore.  Closing as out of date.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664715&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 21:40:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 21:40:25 2004
Subject: [ python-Bugs-980327 ] ntpath normpath
Message-ID: <E1BjNhr-0001Nx-00@sc8-sf-web4.sourceforge.net>

Bugs item #980327, was opened at 2004-06-26 17:29
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980327&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyphrene (keyphrene)
Assigned to: Nobody/Anonymous (nobody)
Summary: ntpath normpath

Initial Comment:
on windows

print os.path.normpath("c:\blah\\blah.exe")
>>> c:\blah\blah.exe # correct syntax

print os.path.normpath("c:\\blah\\blah.exe")
>>> c:\\blah\blah.exe # wrong syntax

this trouble gets an os error with the rename command
(OSError: [Errno 2] No such file or directory)

an solution:
path.replace("\\","\")

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-10 20:40

Message:
Logged In: YES 
user_id=113328

I've just submitted patch 988607 which fixes this issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980327&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 21:47:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 21:47:07 2004
Subject: [ python-Bugs-988602 ] Move urllib2 functional tests into test suite
Message-ID: <E1BjNoM-0004Cr-00@sc8-sf-web1.sourceforge.net>

Bugs item #988602, was opened at 2004-07-10 15:20
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988602&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: John J Lee (jjlee)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Move urllib2 functional tests into test suite

Initial Comment:
People keep forgetting to run the tests that live in
the if __name__ == "__main__" block of urllib2, so this
patch moves them into the main test suite.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-10 15:47

Message:
Logged In: YES 
user_id=11375

Applied; thanks!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988602&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 22:03:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 22:03:36 2004
Subject: [ python-Bugs-988613 ] compiler.transformer and tuple unpacking
Message-ID: <E1BjO4L-0006B5-00@sc8-sf-web3.sourceforge.net>

Bugs item #988613, was opened at 2004-07-10 22:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988613&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Felix Wiemann (felixwiemann)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler.transformer and tuple unpacking

Initial Comment:
compiler.transformer.parse chokes on tuple unpacking
when parentheses are present.

To reproduce, try:

import compiler.transformer
compiler.transformer.parse('(a, b) = 1, 2')

... in Python 2.3 and Python 2.4.  It works in Python
2.3. In Python 2.4, it causes a SyntaxError "bad
assignment".

It works in both Python versions when omitting the
parentheses, i.e. using 'a, b = 1, 2' instead.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988613&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 22:24:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 22:24:03 2004
Subject: [ python-Bugs-635453 ] urllib.urlretrieve() with ftp error 
Message-ID: <E1BjOO8-0002Uu-00@sc8-sf-web4.sourceforge.net>

Bugs item #635453, was opened at 2002-11-08 03:39
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635453&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
>Assigned to: Brett Cannon (bcannon)
Summary: urllib.urlretrieve() with ftp error 

Initial Comment:
When using urllib.urlretrieve() to obtain a file
through ftp and the file is not readable the directory
listing of the file is returned.  The expected behavior
is that a &quot;permission denied&quot; error is generated.
The current behavior makes it impossible to detect
downloading a file failed.

To reproduce:

from urllib import urlretrieve
fname = &quot;/pub/vim/unstable/testfile&quot;
url = &quot;ftp://ftp.vim.org&quot;
resfile, h = urlretrieve(url + fname)
print &quot;file contents: '%s'&quot; % open(resfile).read()
print &quot;header stuff: &quot;, h

The result:
file contents: '-rw-------   1 506      450           
25 Nov  8 11:50 testfile
'

Using ftplib.FTP() does result in the expected error:

from ftplib import FTP
def list(s):
	print s
f = FTP(&quot;ftp.vim.org&quot;)
f.login()
f.retrbinary(&quot;RETR &quot; + fname, list)
f.quit()

The last line of the resulting exception:
ftplib.error_perm: 550 /pub/vim/unstable/testfile:
Permission denied.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635453&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 22:27:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 22:27:18 2004
Subject: [ python-Bugs-635453 ] urllib.urlretrieve() with ftp error 
Message-ID: <E1BjORI-0004X8-00@sc8-sf-web2.sourceforge.net>

Bugs item #635453, was opened at 2002-11-08 11:39
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635453&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Brett Cannon (bcannon)
Summary: urllib.urlretrieve() with ftp error 

Initial Comment:
When using urllib.urlretrieve() to obtain a file
through ftp and the file is not readable the directory
listing of the file is returned.  The expected behavior
is that a &quot;permission denied&quot; error is generated.
The current behavior makes it impossible to detect
downloading a file failed.

To reproduce:

from urllib import urlretrieve
fname = &quot;/pub/vim/unstable/testfile&quot;
url = &quot;ftp://ftp.vim.org&quot;
resfile, h = urlretrieve(url + fname)
print &quot;file contents: '%s'&quot; % open(resfile).read()
print &quot;header stuff: &quot;, h

The result:
file contents: '-rw-------   1 506      450           
25 Nov  8 11:50 testfile
'

Using ftplib.FTP() does result in the expected error:

from ftplib import FTP
def list(s):
	print s
f = FTP(&quot;ftp.vim.org&quot;)
f.login()
f.retrbinary(&quot;RETR &quot; + fname, list)
f.quit()

The last line of the resulting exception:
ftplib.error_perm: 550 /pub/vim/unstable/testfile:
Permission denied.


----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2004-07-10 20:27

Message:
Logged In: YES 
user_id=22785

This is evidently the intended behavior when a url for an
unreadable file is opened, but I think it would make more
sense to raise an exception.  To change the behavior so it
raises an exception, simply remove the test for an exception
reason starting with 550 from ftpwrapper.retrfile() in
urllib.py.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635453&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 22:49:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 22:50:10 2004
Subject: [ python-Bugs-980327 ] ntpath normpath
Message-ID: <E1BjOnH-0003Ah-00@sc8-sf-web4.sourceforge.net>

Bugs item #980327, was opened at 2004-06-26 09:29
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980327&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Keyphrene (keyphrene)
Assigned to: Nobody/Anonymous (nobody)
Summary: ntpath normpath

Initial Comment:
on windows

print os.path.normpath("c:\blah\\blah.exe")
>>> c:\blah\blah.exe # correct syntax

print os.path.normpath("c:\\blah\\blah.exe")
>>> c:\\blah\blah.exe # wrong syntax

this trouble gets an os error with the rename command
(OSError: [Errno 2] No such file or directory)

an solution:
path.replace("\\","\")

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 13:49

Message:
Logged In: YES 
user_id=357491

Paul's patch #988607 has been applied and fixed the bug.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-10 12:40

Message:
Logged In: YES 
user_id=113328

I've just submitted patch 988607 which fixes this issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980327&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 22:55:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 22:55:46 2004
Subject: [ python-Bugs-987166 ] TimedRotatingFileHandler problems
Message-ID: <E1BjOsl-0003IY-00@sc8-sf-web4.sourceforge.net>

Bugs item #987166, was opened at 2004-07-08 06:20
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987166&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Amaury Forgeot d'Arc (amauryf)
>Assigned to: Vinay Sajip (vsajip)
Summary: TimedRotatingFileHandler problems

Initial Comment:
2 problems in the new TimedRotatingFileHandler class:
- "print" statements that where used for debugging were
not removed.
- the code that "find the oldest log file and delete
it" assumes that glob.glob returns files in
alphabetical order. This is not true for all
filesystems (FAT and Novell at least don't sort their
directories), so the file deleted may be a recent one...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987166&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 23:29:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 23:29:38 2004
Subject: [ python-Bugs-977680 ] IMAP4_SSL() class incompatible with
	socket.timeout
Message-ID: <E1BjPPX-0006tY-00@sc8-sf-web1.sourceforge.net>

Bugs item #977680, was opened at 2004-06-22 11:13
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977680&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Charles (melicertes)
Assigned to: Nobody/Anonymous (nobody)
Summary: IMAP4_SSL() class incompatible with socket.timeout

Initial Comment:
If you do socket.setdefaulttimeout(X) before trying to
instantiate imaplib.IMAP4_SSL(), the connection hangs
partway through the SSL negotiation.

The cause is that socket.ssl() is actually incompatible
with timeouts (not sure why) and IMAP4_SSL() doesn't do
anything to guard against it.  It should do
.setblocking(1) on the socket.socket object before
passing it to socket.ssl().

The documentation should also clarify timeouts not
working with socket.ssl.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 14:29

Message:
Logged In: YES 
user_id=357491

Patch #945642 seems to fix this.  Closing as fixed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=977680&group_id=5470
From noreply at sourceforge.net  Sat Jul 10 23:40:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 10 23:40:54 2004
Subject: [ python-Bugs-621057 ] File write examples are inadequate
Message-ID: <E1BjPaU-0006NQ-00@sc8-sf-web2.sourceforge.net>

Bugs item #621057, was opened at 2002-10-09 18:39
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Stagg (kandrew)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: File write examples are inadequate

Initial Comment:
The examples provided for writing to files in 
section 7.2 of the documentation are overly simple 
showing only writing of a static string.  Reading 
through 7.1 (although not actually discussing file 
I/O) helps a little as the % operator is mentioned 
but the &quot;...C sprintf()-style format string...&quot; 
specifiers which are valid aren't cross referenced 
(and the 'Library Reference' is a largish search 
area).  I had to find out experimentally that %f isn't 
valid although %d is.  To date, I haven't been able 
to experimentally findout how to print a list or 
tuple.

trying:
  file.write('&quot;%s&quot;', str(relatedMeasurements))

results in:
  TypeError: read-only buffer, tuple

The addition of examples printing a list or tuple 
would be extremely helpful.  Similarly, examples of 
using file.write() to produce print type output 
would be very illuminating.

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 17:40

Message:
Logged In: YES 
user_id=99874

I took a close look at this, and considered adding text like
you describe to the tutorial. However, looking at it
carefully, I think it's probably best to leave the tutorial
as it is (and close this bug). Here's my reasoning:

(1) the write() method of files takes strings. If you need
to output some structured variable, first convert it into a
string somehow, then pass that to write(). Your complaint
(if I understand correctly) was that as a beginner you came
to this and assumed that the write() method of files might
work rather like the print statement -- with special
processing allowing one to pass in other types and have them
automatically converted. You propose including one example
in the tutorial to demonstrate the correct way of doing it.

(2) The current tutorial is simple and clear. It has just
one one-line example of how to use write() (passing it a
string). This is easy to follow, and doesn't cause anyone to
confuse converting to a string with writing to a file.
*Unnecessarily* complicating this would be unwise.

(3) So the question is whether debunking your error is
"necessary" (well, whether it's worth making that part of
the tutorial more complex. I would say no, because I think
your error is uncommon. (Not to say that it didn't have
*you* fooled for a time, just that it wouldn't fool *lots*
of first-time users.) The example demonstrates how to print
a string. The truth is that strings are all that you can
print. The section on files doesn't help much for the person
who needs to learn how to convert a more complex data
structure to a string, but then I wouldn't expect it to --
that section is supposed to be about files. The other
information is in section 7.1 *immediately preceeding* the
section on files. I figure most readers will at least be
skimming the tutorial in order, and will already know how to
convert their data structures by the time they get to
section 7.2.

kandrew, please feel free to correct me if I've missed an
important point you had to make, but barring a
misunderstanding, I propose closing this bug.
-- Michael Chermside

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-10-28 10:45

Message:
Logged In: YES 
user_id=80475

That's cool.
I'll leave this one for Fred.
Hopefully, 2.2.6.2 can be made easier to find.

----------------------------------------------------------------------

Comment By: Andrew Stagg (kandrew)
Date: 2002-10-28 10:40

Message:
Logged In: YES 
user_id=577467

I appear to have failed to clearly state the point of this 
bug report.  It has nothing to do with debugging a 
specific piece of code and everything to do with the 
difficulty in finding the required information for an 
experienced developer to write code to perform a 
standard task.  The changes suggested to correct this 
issue as, in fact, quite simple.


Examining tutorial section 7.2:

http://www.python.org/doc/current/tut/node9.html#SE
CTION009200000000000000000


The examples provided show only static strings.

Example 1:

&gt;&gt;&gt; f.write('This is a test\n')


Example 2:

&gt;&gt;&gt; f.write('0123456789abcdef')


 Including even one example with a variable of any type 
would be a large step forward and this is the primary 
point of this bug report.

I.e. consider including the following example:

Printing a variable:
&gt;&gt;&gt; a = 123.456
&gt;&gt;&gt; f.write( '%d' % (a))

and: Printing a tuple:
&gt;&gt;&gt; b = ('This', 'is', 9876.654, 'not a string')
&gt;&gt;&gt; f.write(str(b))

or printing the tuple without the brackets:
&gt;&gt;&gt; for element in b
...    f.write('%s ' % str(element))

I believe this to be an essential point to be made and 
addressed because every (IMI EVERY) other example of 
generating output in the tutorial that I have seen uses 
the print() function.  If you examine the language 
reference, it is quite apparent that print() accepts 
a 'expression' which is a much more flexible construct 
then the 'string' accepted by file.write().  It's obvious 
that you are aware of the difference between the two 
functions yet you appear to be insisting that there's no 
need to provide anything more then the most trivial of 
examples when discussing the more restrictive of 
them.  This bug report was raised specifically because 
of the difficulty encountered by a non-guru in 
determining what is required to make that more 
restrictive function work.

No sir, I will not withdraw the bug report at this time as 
it has not yet been addressed and the core issue here is 
not debugging a piece of code.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-10-28 10:21

Message:
Logged In: YES 
user_id=3066

Raymond:  I asked Andrew to file this bug report after he
first sent a note to the python-docs address; I do think
there's room for improvement in the docs.  i'd hoped to get
to this before now, but still intend to do so.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-10-28 08:30

Message:
Logged In: YES 
user_id=80475

When coded with the proper syntax, the example runs fine:

&gt;&gt;&gt; peakPres = {'meas1': 1, 'Unknown': 0}
&gt;&gt;&gt; f = open('test1', 'w')
&gt;&gt;&gt; for pres in peakPres:
        f.write('%s: %s, ' % (pres, peakPres[pres]))

	
&gt;&gt;&gt; f.close()
&gt;&gt;&gt; open('test1').read()
'Unknown: 0, meas1: 1, '


To debug your code, please do the following:
-- don't use variable names like file, list, etc
-- use the % formatting operator instead of a comma
-- build a correctly formatting string before worrying
   about writing it to a file
-- the % operator takes a single tuple argument so the
   values must be wrapped in parentheses:
        formatstring % (val1, val2, val3)

Note, the tutorial and library reference are stand-alone 
documents and do not cross reference with each other.

Recommend that you withdraw the bug report.

----------------------------------------------------------------------

Comment By: Andrew Stagg (kandrew)
Date: 2002-10-25 15:50

Message:
Logged In: YES 
user_id=577467

The comment that the example is incomplete is well 
founded.  Therefore I attach a standalone example of 
the problem I ran into:

&gt;&gt;&gt; peakPres = {'Unknown':0}
&gt;&gt;&gt; peakPres['meas1'] = 0
&gt;&gt;&gt; peakPres['meas1'] = peakPres['meas1']+1
&gt;&gt;&gt; print peakPres
{'meas1': 1, 'Unknown': 0}
&gt;&gt;&gt; for pres in peakPres.keys():
... 	print pres, peakPres[pres]
... 
meas1 1
Unknown 0
&gt;&gt;&gt; file.open('test1.dat', 'w')
Traceback (innermost last):
  File &quot;&lt;interactive input&gt;&quot;, line 1, in ?
NameError: file
&gt;&gt;&gt; file = open('test1.dat', 'w')
&gt;&gt;&gt; for pres in peakPres.keys():
... 	file.write('%s: %s, ', pres, peakPres[pres])
... 
Traceback (innermost last):
  File &quot;&lt;interactive input&gt;&quot;, line 2, in ?
TypeError: read-only buffer, tuple
&gt;&gt;&gt; 

Note that the call to print works while the call to 
file.write does not.  The reason is that the print 
statement makes a call to __str__.  

Thus, and file.write() do not have the same relationship 
as C++ stream classes ostream and ofstream or C's 
printf and fprintf.  (As implied by rhettinger and the 
current contents of the tutorial.)

Hence, my request that the tutorial's examples of file 
output be expanded to the non-trival level of writing 
list and dictionary members.  Cross referenceing the 
legal format specifiers (in the language reference) from 
the tutorial examples would also be extremely helpful.


----------------------------------------------------------------------

Comment By: Andrew Stagg (kandrew)
Date: 2002-10-25 15:48

Message:
Logged In: YES 
user_id=577467

The comment that the example is incomplete is well 
founded.  Therefore I attach a standalone example of 
the problem I ran into:

&gt;&gt;&gt; peakPres = {'Unknown':0}
&gt;&gt;&gt; peakPres['meas1'] = 0
&gt;&gt;&gt; peakPres['meas1'] = peakPres['meas1']+1
&gt;&gt;&gt; print peakPres
{'meas1': 1, 'Unknown': 0}
&gt;&gt;&gt; for pres in peakPres.keys():
... 	print pres, peakPres[pres]
... 
meas1 1
Unknown 0
&gt;&gt;&gt; file.open('test1.dat', 'w')
Traceback (innermost last):
  File &quot;&lt;interactive input&gt;&quot;, line 1, in ?
NameError: file
&gt;&gt;&gt; file = open('test1.dat', 'w')
&gt;&gt;&gt; for pres in peakPres.keys():
... 	file.write('%s: %s, ', pres, peakPres[pres])
... 
Traceback (innermost last):
  File &quot;&lt;interactive input&gt;&quot;, line 2, in ?
TypeError: read-only buffer, tuple
&gt;&gt;&gt; 

Note that the call to print works while the call to 
file.write does not.  The reason is that the print 
statement makes a call to __str__.  

Thus, and file.write() do not have the same relationship 
as C++ stream classes ostream and ofstream or C's 
printf and fprintf.  (As implied by rhettinger and the 
current contents of the tutorial.)

Hence, my request that the tutorial's examples of file 
output be expanded to the non-trival level of writing 
list and dictionary members.  Cross referenceing the 
legal format specifiers (in the language reference) from 
the tutorial examples would also be extremely helpful.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-10-23 09:58

Message:
Logged In: YES 
user_id=80475

Here are a few thoughts:

The % formatting operator is fully documented in 2.2.6.2 
of the library reference.  I think the tutorial should be kept 
at an introductory level and the details left in the reference. 
OTOH, I agree that 2.2.6.2 is hard to find.

%f is a valid format:  '%f' % 3.14

There are several oddities in the file.write error in your 
post. First, the double quotes inside the single quotes 
(perhaps this is intentional).  Second, the comma should 
have been the % formatting operator.  Third, since 'file' is 
the name of a type, it is normally a good idea to pick 
another name like 'infil' or 'outfil'.

The post doesn't include enough information to be able to 
reproduce the error.  We need to know the value of 
relatedMeasurements and have a line showing how the file 
was opened.

To debug the example, it would help to separate the 
concerns of file writing from the string formatting.  Get the 
program to successfully format and print a string.  Only 
then, add a line to write it out to a file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621057&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 00:30:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 00:30:21 2004
Subject: [ python-Bugs-988120 ] httplib.HTTPResponse.read() not updating the
	length correctl
Message-ID: <E1BjQMK-0001PI-00@sc8-sf-web3.sourceforge.net>

Bugs item #988120, was opened at 2004-07-09 18:37
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988120&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib.HTTPResponse.read() not updating the length correctl

Initial Comment:
I believe there is a bug in HTTPResponse.read. This is
the last part:
                                                      
                         
                                                      
                         
                                                      
                         
        if self.length is not None:
            if amt > self.length:
                # clip the read to the "end of response"
                amt = self.length
            self.length -= amt
                                                      
                         
        # we do not use _safe_read() here because this
may be a .will_close
        # connection, and the user is reading more
bytes than will be provided
        # (for example, reading in 1k chunks)
        s = self.fp.read(amt)
                                                      
                         
        return s
                                                      
                         
                                                      
                         
self.length is the response's length as presented by
the Content-Length header.
                                                      
                         
If I am not mistaken, self.fp.read(amt) (for the case
where amt is not None) returns _up to_, not _exactly_
amt bytes.
                                                      
                         
So, if amt is originally 1024 bytes and self.fp.read
returns only 520 bytes (because, let's say, you are
reading from an SSL socket), then self.length is
decremented by 1024 and not by 520. So you end up
reading less than self.length
                                                      
                         
I am seeing this when plugging an SSL socket/file from
pyOpenSSL.


----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-10 23:30

Message:
Logged In: YES 
user_id=261020

Patch 988642 addresses this.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-10 04:31

Message:
Logged In: YES 
user_id=6380

Python's regular files always return the requested amount
except at EOF. But many file-like objects don't guarantee
this, so I agree that it's better to only adjust the
position by the number of bytes actually read.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988120&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 00:30:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 00:31:04 2004
Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Message-ID: <E1BjQMz-0008Px-00@sc8-sf-web1.sourceforge.net>

Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Comment added) made by tinolange
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Kiendl (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL-ed sockets don't close correct?

Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :

---

I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )

I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.

I wrap the cmd socket like:

        self.voidcmd('AUTH TLS')
        ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
        import httplib
        self.sock = httplib.FakeSocket(self.sock, ssl)
        self.file = self.sock.makefile('rb')

Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...

        self.voidcmd('PBSZ 0')
        self.voidcmd('PROT P')

wrap the data connection with SSL:

            ssl = socket.ssl(conn, self.key_file,
self.cert_file)
            import httplib
            conn = httplib.FakeSocket(conn, ssl)

than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?

    def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
        self.voidcmd('TYPE I')
        conn = self.transfercmd(cmd, rest)
        fp = conn.makefile('rb')
        while 1:
            #data = conn.recv(blocksize)
            data = fp.read()    #blocksize)
            if not data:
                break
            callback(data)
        fp.close()
        conn.close()
        return self.voidresp()


what could be reason? 
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)

----------------------------------------------------------------------

Comment By: Tino Lange (tinolange)
Date: 2004-07-11 00:30

Message:
Logged In: YES 
user_id=212920

Hi Roberto!

Today a patch for _ssl.c was checked in (see #945642) that
might solve your problem, too.

Could you please grab the *next* alpha (this will be Python
2.4 Alpha 2) and test and report afterwards if it is solved?

Thanks for your help!

Tino


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 00:42:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 00:42:12 2004
Subject: [ python-Bugs-988120 ] httplib.HTTPResponse.read() not updating the
	length correctl
Message-ID: <E1BjQXo-0007rB-00@sc8-sf-web2.sourceforge.net>

Bugs item #988120, was opened at 2004-07-09 17:37
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988120&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib.HTTPResponse.read() not updating the length correctl

Initial Comment:
I believe there is a bug in HTTPResponse.read. This is
the last part:
                                                      
                         
                                                      
                         
                                                      
                         
        if self.length is not None:
            if amt > self.length:
                # clip the read to the "end of response"
                amt = self.length
            self.length -= amt
                                                      
                         
        # we do not use _safe_read() here because this
may be a .will_close
        # connection, and the user is reading more
bytes than will be provided
        # (for example, reading in 1k chunks)
        s = self.fp.read(amt)
                                                      
                         
        return s
                                                      
                         
                                                      
                         
self.length is the response's length as presented by
the Content-Length header.
                                                      
                         
If I am not mistaken, self.fp.read(amt) (for the case
where amt is not None) returns _up to_, not _exactly_
amt bytes.
                                                      
                         
So, if amt is originally 1024 bytes and self.fp.read
returns only 520 bytes (because, let's say, you are
reading from an SSL socket), then self.length is
decremented by 1024 and not by 520. So you end up
reading less than self.length
                                                      
                         
I am seeing this when plugging an SSL socket/file from
pyOpenSSL.


----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2004-07-10 22:42

Message:
Logged In: YES 
user_id=22785

Submitted patch #988642 to fix this

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-10 22:30

Message:
Logged In: YES 
user_id=261020

Patch 988642 addresses this.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-07-10 03:31

Message:
Logged In: YES 
user_id=6380

Python's regular files always return the requested amount
except at EOF. But many file-like objects don't guarantee
this, so I agree that it's better to only adjust the
position by the number of bytes actually read.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988120&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 00:59:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 00:59:46 2004
Subject: [ python-Bugs-930024 ] os.path.realpath can't handle symlink loops
Message-ID: <E1BjQon-0001yh-00@sc8-sf-web3.sourceforge.net>

Bugs item #930024, was opened at 2004-04-05 13:59
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=930024&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.realpath can't handle symlink loops

Initial Comment:
Create a symlink pointing to itself:

ln -s infinite infinite

Run os.path.realpath() on it, and it recurses
infinitely (until the stack limit is hit):

>>> import os
>>> os.path.realpath('/home/amk/infinite')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/posixpath.py", line 416, in
realpath
    return realpath(newpath)

os.path.realpath() should be fixed; /home/amk/infinite
is a perfectly good path, though it can't be followed.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 15:59

Message:
Logged In: YES 
user_id=357491

Applied as rev. 1.67 in 2.4a2 and rev. 1.62.6.2 in 2.3.5 with only minor 
cleanup.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-06-05 11:58

Message:
Logged In: YES 
user_id=11375

Patch attached; review requested.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=930024&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 01:03:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 01:03:32 2004
Subject: [ python-Feature Requests-985094 ] getattr(object,
	name) accepts only strings
Message-ID: <E1BjQsE-0006Sh-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #985094, was opened at 2004-07-04 16:21
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=985094&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: getattr(object,name) accepts only strings

Initial Comment:
getattr(object,name) function accepts only strings. This behavior prohibits some interesting usage of callables as names in database column and field references.

For example:

Someone references a database field:
value=record.field_name

Programmatically, when name is the name of the field:
value=getattr(record,field_name)

Calculated fields could be implemented by passing a callable as a field name:

def fn(record): return '%s (%s)'%(record.name,record.number)

value=getattr(record,fn)

The database backend checks if the name is callable and then call the name with the record.

But this cannot be implemented in the simple way if getattr checks if the name is a string or not. This is an unneccessary check in getattr, setattr and delattr, since prevents interesting solutions.

Temporary workaround:

value=record.__getattr__(fn)

There can be many unneccessary type checks and limitations in core and library functions. They should be removed to allow free usage.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=985094&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 01:06:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 01:06:34 2004
Subject: [ python-Bugs-984691 ] Tiny suggestion to improve optparse doc
Message-ID: <E1BjQvN-00029l-00@sc8-sf-web3.sourceforge.net>

Bugs item #984691, was opened at 2004-07-03 11:32
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984691&group_id=5470

Category: Documentation
Group: Not a Bug
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tiny suggestion to improve optparse doc

Initial Comment:
In section 6.20.2.7 Putting it all together
 the usage string is given as 
usage = "usage: \%prog [-f] [-v] [-q] firstarg secondarg"

but then later you get to
if len(args) != 1:
        parser.error("incorrect number of arguments")

... should be 2, no, to correspond to the usage ....

Laura


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 16:06

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 1.14 in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984691&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 01:15:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 01:15:25 2004
Subject: [ python-Bugs-980938 ] smtplib.SMTP prints debug stuff to stdout
Message-ID: <E1BjR3v-0006nj-00@sc8-sf-web4.sourceforge.net>

Bugs item #980938, was opened at 2004-06-27 17:51
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980938&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib.SMTP prints debug stuff to stdout

Initial Comment:
The SMTP class in smtplib.py sends its debug output to 
stdout.  This should at least be changed to stderr.  Better 
yet would be to make the destination configurable via a 
set_debug_output() method.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 16:15

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 1.65 in CVS.  Not backporting since some one some where 
might actually depend on it going to stdout.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980938&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 01:47:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 01:47:55 2004
Subject: [ python-Bugs-956408 ] Simplifiy coding in cmd.py
Message-ID: <E1BjRZI-00035q-00@sc8-sf-web3.sourceforge.net>

Bugs item #956408, was opened at 2004-05-18 20:54
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=956408&group_id=5470

Category: None
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 1
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Simplifiy coding in cmd.py

Initial Comment:
In the cmd.py 1.35 checkin on 2/6/2003, there are many
lines like:

    self.stdout.write("%s\n"%str(header))

I believe the str() call in unnecessary.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-06-12 19:48

Message:
Logged In: YES 
user_id=33168

The str call is necessary if header is a tuple.  AFAIK, if
header is not a tuple, using str() is redundant.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-07 00:01

Message:
Logged In: YES 
user_id=80475

Neal, is this a simplification you would like to make?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=956408&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 01:48:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 01:48:53 2004
Subject: [ python-Bugs-988613 ] compiler.transformer and tuple unpacking
Message-ID: <E1BjRaC-0007Xq-00@sc8-sf-web4.sourceforge.net>

Bugs item #988613, was opened at 2004-07-10 20:03
Message generated for change (Comment added) made by jpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988613&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Felix Wiemann (felixwiemann)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler.transformer and tuple unpacking

Initial Comment:
compiler.transformer.parse chokes on tuple unpacking
when parentheses are present.

To reproduce, try:

import compiler.transformer
compiler.transformer.parse('(a, b) = 1, 2')

... in Python 2.3 and Python 2.4.  It works in Python
2.3. In Python 2.4, it causes a SyntaxError "bad
assignment".

It works in both Python versions when omitting the
parentheses, i.e. using 'a, b = 1, 2' instead.

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2004-07-10 23:48

Message:
Logged In: YES 
user_id=22785

I've uploaded patch #988698 to fix this

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988613&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 01:55:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 01:55:22 2004
Subject: [ python-Bugs-979794 ] diffutil errors when comparing 2 0 byte
	entries
Message-ID: <E1BjRgc-0001P4-00@sc8-sf-web2.sourceforge.net>

Bugs item #979794, was opened at 2004-06-25 08:12
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979794&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Robert M. Zigweid (rzigweid)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: diffutil errors when comparing 2 0 byte entries

Initial Comment:
difflib has a problem where if the two things that it is comparing are 
0 byte/null that when it comes time to output the results, it errors 
because a generator appears to not be properly set up.

To duplicate easily, use the diff.py utility in Tools/scripts and diff 
two zero byte files. 

This error does not occur if either of the objects being compared has 
content.


  File "diff.py", line 40, in ?
    sys.stdout.writelines(diff)
  File "/usr/local/lib/python2.3/difflib.py", line 1215, in context_diff
    for group in 
SequenceMatcher(None,a,b).get_grouped_opcodes(n):
  File "/usr/local/lib/python2.3/difflib.py", line 574, in 
get_grouped_opcodes
    if codes[0][0] == 'equal':
IndexError: list index out of range


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 16:55

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 1.21 in CVS.  Not backporting in case someone actually 
relies on this behavior.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-06-25 20:17

Message:
Logged In: YES 
user_id=12800

Probably a dup of 980117


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979794&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 01:55:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 01:55:54 2004
Subject: [ python-Bugs-980117 ] Index error for empty lists in Difflib
Message-ID: <E1BjRh9-0001QC-00@sc8-sf-web2.sourceforge.net>

Bugs item #980117, was opened at 2004-06-25 19:41
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980117&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rocco Moretti (roccomoretti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Index error for empty lists in Difflib

Initial Comment:
When using the context_diff and unified_diff functions
in difflib, submitting two empty lists to compare to
each other produces an IndexError, as opposed to the
expected empty diff. This error does not occur when
using ndiff, or when comparing a nonempty list to an
empty list. (In either direction)

<See patch manager for a potential fix.>

Example Behavior:

Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import difflib
>>> difflib.unified_diff([],[])
<generator object at 0x008E0918>
>>> list(difflib.unified_diff([],[]))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python23\lib\difflib.py", line 1149, in
unified_diff
    for group in
SequenceMatcher(None,a,b).get_grouped_opcodes(n):
  File "C:\Python23\lib\difflib.py", line 574, in
get_grouped_opcodes
    if codes[0][0] == 'equal':
IndexError: list index out of range
>>> list(difflib.unified_diff([],['']))
['---  \n', '+++  \n', '@@ -1,0 +1,1 @@\n', '+']
>>> list(difflib.unified_diff([''],[]))
['---  \n', '+++  \n', '@@ -1,1 +1,0 @@\n', '-']
>>>


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 16:55

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 1.21.  Not being backported in case someone actually 
expects this behavior.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-06-25 20:18

Message:
Logged In: YES 
user_id=12800

Probably a dup of 979794


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980117&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 01:58:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 01:58:12 2004
Subject: [ python-Bugs-985753 ] weakref should have a WeakSet
Message-ID: <E1BjRjJ-0003K2-00@sc8-sf-web3.sourceforge.net>

Bugs item #985753, was opened at 2004-07-06 01:42
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985753&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref should have a WeakSet

Initial Comment:
It'd be nice if weakref had a WeakSet. This way I
wouldn't need a WeakValueDictionary keyed by id(object)
when all I want is to iterate over the objects that are
still alive.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-10 18:58

Message:
Logged In: YES 
user_id=80475

Closing this as won't fix.

The WeakKeyDictionary and fromkeys() method meet this need
easily:

alive = WeakKeyDictionary.fromkeys(*objlist)
  . . .
print list(alive)    # always current list of alive objects


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-06 09:09

Message:
Logged In: YES 
user_id=80475

Why not use a WeakKeyDictionary with the values set to True?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985753&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 02:05:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 02:05:21 2004
Subject: [ python-Bugs-796116 ] Parser wart
Message-ID: <E1BjRqF-0003Sb-00@sc8-sf-web3.sourceforge.net>

Bugs item #796116, was opened at 2003-08-27 12:26
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796116&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
Resolution: None
Priority: 2
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jeremy Hylton (jhylton)
Summary: Parser wart

Initial Comment:
Its okay that the parser allows 10+2 to be correctly 
interpreted, but keywords should require whitespace 
separation.  Currently, intervening whitespace is not 
required:

&gt;&gt;&gt; 10and 1
1




----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-29 03:29

Message:
Logged In: YES 
user_id=539787

History: this wart (keywords legally appended to numeric 
constants, which keywords don't start with 'e', 'f', and 'd' 
perhaps) appears in all languages I have used in my life (well, 
except for the ZX Spectrum 48K Basic, where eg. the 1.5 
keypress for 'and' produced ' and ' forcefully :)

The easiest way would be to have a significant_whitespace 
node in Grammar/Grammar, which would be inserted just 
before the 'and' and 'or' keywords in and_test and or_test, 
but Grammar does not deal with whitespace.  Let's look 
parsemodule.c... could one SIG_WHITESPACE token be 
produced?  Also, what about line continuations having 'and' 
or 'or' in the beginning of a physical line?

I believe this wart should be eliminated only if letter suffixes 
are allowed to numeric constants, which I doubt will happen; 
I'd suggest to lower the priority of this unless somebody finds 
a quick-n-dirty solution.  Not that important.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796116&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 03:21:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 03:21:51 2004
Subject: [ python-Bugs-450803 ] smtpd.py needs documentation
Message-ID: <E1BjT2K-0003MU-00@sc8-sf-web2.sourceforge.net>

Bugs item #450803, was opened at 2001-08-14 10:18
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: smtpd.py needs documentation

Initial Comment:
smtpd.py needs documentation for the standard library

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 21:21

Message:
Logged In: YES 
user_id=99874

Update: I got the docs compiling on my machine, and I can
confirm that there are no other errors. I've also learned
that file should be named "libsmptd.tex" instead, and
there's a trivial one-line addition needed in lib.tex. But,
of course, you already knew that <wink>.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 14:55

Message:
Logged In: YES 
user_id=99874

I think moshez's text may be minimal but it's way better
than having NO docs. So I propose we accept it as-is: we can
always improve things later. With that in mind, I am
re-assigning this to Fred, and I've also revised moshez's
attachment slightly. Add this file as smptd.tex in
python/dist/src/Doc/lib and it should work. (I've made it
pass texcheck.py, there could still be some higher-level tex
errors.)

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2002-06-11 05:48

Message:
Logged In: YES 
user_id=11645

Here's something you can use as a start, Barry.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 04:16:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 04:17:42 2004
Subject: [ python-Bugs-820583 ] urllib2 silently returns None when auth_uri
	is mismatched
Message-ID: <E1BjTsu-0004Ud-00@sc8-sf-web2.sourceforge.net>

Bugs item #820583, was opened at 2003-10-09 07:11
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820583&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christopher Armstrong (radeex)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: urllib2 silently returns None when auth_uri is mismatched

Initial Comment:
Code like the following, where the `uri' argument which
I pass to add_password is not actually the URI that the
web server gives me in its request for basic auth,
makes the return value of OpenDirector.open None. This
is either a code bug or a documentation bug. I expected
director.open to raise an error, but saying something
like &quot;open will return None in these cases: ....&quot; would
also be a valid solution, if one that's not as good,
IMO... the AuthHandler could raise an error once it
realizes that none of the URIs we have match, perhaps?

import urllib2

realm = &quot;Linksys BEFW11S4 V4&quot;

passman = urllib2.HTTPPasswordMgr()
passman.add_password(realm,
'NOT_WHAT_THE_SERVER_GIVES_ME', 'user', 'password')

auther = urllib2.HTTPBasicAuthHandler(passman)
getter = urllib2.HTTPHandler()

director = urllib2.OpenerDirector()

director.add_handler(auther)
director.add_handler(getter)


f = director.open('http://192.168.1.1/Status.htm')
print f, &quot;is None&quot;


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-07-10 21:16

Message:
Logged In: YES 
user_id=149084

patch 851752 applied

liburllib2.tex 1.20

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-11-30 17:18

Message:
Logged In: YES 
user_id=261020

Uploaded doc fix as patch 851752. 

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2003-10-29 18:56

Message:
Logged In: YES 
user_id=261020

It's a doc bug.  I'll add a doc patch later. 
 
Returning None from a handler means &quot;I can't handle this, but 
another handler might&quot;.  So AuthHandler is correct to return 
None, and shouldn't raise an exception.  If you want to get a 
URLError in cases where all relevant handlers return None, 
you need to do: 
 
director.add_handler(UnknownHandler) 
 
(which build_opener will do for you, actually) 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820583&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 05:32:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 05:32:39 2004
Subject: [ python-Bugs-852532 ] ^$ won't split on empty line
Message-ID: <E1BjV4t-0006zu-00@sc8-sf-web1.sourceforge.net>

Bugs item #852532, was opened at 2003-12-02 05:01
Message generated for change (Comment added) made by mkc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852532&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: Postponed
Priority: 5
Submitted By: Jan Burgy (jburgy)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ^$ won't split on empty line

Initial Comment:
Python 2.3.2 (#49, Oct  2 2003, 20:02:00) [MSC v.1200 
32 bit (Intel)] on win32

&gt;&gt;&gt; import re
&gt;&gt;&gt; re.compile('^$', re.MULTILINE).split('foo\n\nbar')
['foo\n\nbar']

I expect ['foo\n', '\nbar'], since, according to the 
documentation $ &quot;in MULTILINE mode also matches 
before a newline&quot;.

Thanks, Jan

----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2004-07-10 22:32

Message:
Logged In: YES 
user_id=555

I made a patch that addresses this (#988761).

----------------------------------------------------------------------

Comment By: Jan Burgy (jburgy)
Date: 2004-01-14 05:07

Message:
Logged In: YES 
user_id=618572

Since I really needed the functionality described above, I 
came up with a broke-around. It's a sufficient replacement, 
maybe it belongs in some FAQ:

>>> import re
>>> re.sub('(?im)^$', '\f', 'foo\n\nbar').split('\f')
['foo\n', '\nbar']

Another "magic" byte could replace '\f'...

Regards, Jan

----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2003-12-31 23:28

Message:
Logged In: YES 
user_id=555

Hi, I was going to file this bug just now myself, as this
seems like a really useful feature.  For example, I've
several times wanted to split on '^' or '^(?=S)' (to split
up a data file into paragraphs that start with an initial
S).  Instead I have to do something like '\n(?=S)', which is
rather more hideous.

To answer tim_one's challenge, yes, I *do* expect splitting
by 'x*' to break a string into letters, now that I've
thought about it.  To not do so is a bizarre and surprising
behavior, IMO.  (Patient: Doctor, when I split on this
nonsense pattern I get nonsense!  Doctor: Then don't do that.)

The fix should be near this line in _sre.c, I think.

        if (state.start == state.ptr) {

I could work on a patch if you'll take it...

Mike


----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2003-12-11 07:42

Message:
Logged In: YES 
user_id=38376

Split never splits on empty substrings; see Tim's answer for a 
brief discussion.

Fred, can you perhaps add something to the documentation?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-12-02 09:20

Message:
Logged In: YES 
user_id=31435

Confirmed on Pythons 2.1.3, 2.2.3, 2.3.2, and current CVS.

More generally, split() doesn't appear to split on any empty 
(0-length) match.  For example,

&gt;&gt;&gt; pat = re.compile(r'\b')
&gt;&gt;&gt; pat.split('(a b)')
['(a b)']
&gt;&gt;&gt; pat.findall('(a b)')  # but the pattern matches 4 places
['', '', '', '']
&gt;&gt;&gt;

That's probably a design constraint, but isn't documented.  
For example, if you split &quot;abc&quot; by the pattern x*, what do you 
expect?  The pattern matches (with length 0) at 4 places, 
but I bet most people would be surprised to get

['', 'a', 'b', 'c', '']

back instead of (as they do get)

['abc']

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=852532&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 07:37:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 07:37:23 2004
Subject: [ python-Bugs-988784 ] Windows installer missing test files
Message-ID: <E1BjX1b-0008MP-00@sc8-sf-web2.sourceforge.net>

Bugs item #988784, was opened at 2004-07-11 01:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988784&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. L?wis (loewis)
Summary: Windows installer missing test files

Initial Comment:
The 2.4a1 Windows installer doesn't include the test file 
cfgparser.1, so test_cfgparser gets three errors in an 
installed Python on Windows:

==========================================
============================
FAIL: test_read_returns_file_list 
(__main__.ConfigParserTestCase)
------------------------------------------------------
----------------
Traceback (most recent call last):
  File "lib\test\test_cfgparser.py", line 250, in 
test_read_returns_file_list
    self.assertEqual(parsed_files, [file1])
AssertionError: [] != ['cfgparser.1']

==========================================
============================
FAIL: test_read_returns_file_list 
(__main__.RawConfigParserTestCase)
------------------------------------------------------
----------------
Traceback (most recent call last):
  File "lib\test\test_cfgparser.py", line 250, in 
test_read_returns_file_list
    self.assertEqual(parsed_files, [file1])
AssertionError: [] != ['cfgparser.1']

==========================================
============================
FAIL: test_read_returns_file_list 
(__main__.SafeConfigParserTestCase)
------------------------------------------------------
----------------
Traceback (most recent call last):
  File "lib\test\test_cfgparser.py", line 250, in 
test_read_returns_file_list
    self.assertEqual(parsed_files, [file1])
AssertionError: [] != ['cfgparser.1']

------------------------------------------------------
----------------
Ran 39 tests in 0.031s

FAILED (failures=3)

I think test files for the new decimal module are missing 
too, although I believe you won't notice this unless you 
pass "-u decimal" to regrtest.py, or run test_decimal.py 
directly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988784&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 08:00:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 08:00:26 2004
Subject: [ python-Bugs-788520 ] Queue class has logic error when non-blocking
Message-ID: <E1BjXNq-0006Qp-00@sc8-sf-web4.sourceforge.net>

Bugs item #788520, was opened at 2003-08-13 23:57
Message generated for change (Comment added) made by berryman77
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Queue class has logic error when non-blocking

Initial Comment:
Looking at the Queue class, I noticed that it might
incorrectly raise a Full/Empty Exception when called
with block=False.

This leads to the following undesirable behaviour:
 * Full exception raised when Queue not full
 * Full exception raised when Queue has no maxsize

Here's my logic (for put(), but get() is similar):

First part of code for put, in Queue.py:
    def put(self, item, block=1):
        if block:
            self.fsema.acquire()
        elif not self.fsema.acquire(0):
            raise Full

Now, for the purposes of raising a Full exception, we
are assuming that fsema is locked if and only if the
Queue is full.

BUT, it seems that fsema is locked every time an item
is added to the Queue, even if that item would not make
the Queue full.

Hence, it might be possible for a Full exception to be
raised, when fsema is locked due to adding an item that
would not  actually make the Queue full. 

An example...

 * Queue with maxsize 10, currently 5 objects in it.
 * Threads T1 and T2, both trying to add an item with
Queue.put(item, block=True).
 * This should obviously be fine, resulting in a Queue
with 7 items.
 [1] Call T1.put(item1, block=True)
 [2] Call T2.put(item2, block=True)
 [3] T1 grabs fsema and mutex, but then the current
thread changes before they are released...
 [4] T2 cannot acquire fsema (since T1 currently has
it), and so raises the Full exception (incorrectly)

Of course, I may have misunderstood something, since I
haven't been able to consistently reproduce the problem
(threading errors are so vexing).

I have no easy solution to this issue (redo the class
using a threading.BoundedSemaphore to count the Queue
length?).

My python version:
Python 2.2.2 (#1, Feb 24 2003, 17:36:09)
[GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2

----------------------------------------------------------------------

Comment By: Randall B. Smith (berryman77)
Date: 2004-07-11 01:00

Message:
Logged In: YES 
user_id=880241

A Full exception is returned when the queue is NOT FULL. 
This is a bug!  The lack of an immediate solution is not an
excuse to accept incorrect code.



----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-21 22:40

Message:
Logged In: YES 
user_id=693152

Okay, that makes more sense. So, loosely expressed,
non-blocking means there's no way the user can put the Queue
in a blocked state (and especially not deadlocked) - as with
your example of waiting forever on a get call. But,
obviously, internal locks can always be used (in a careful
manner).

I think that's closer to my implicit understand of blocking
that I was trying to express. In the case of put/get, I had
a slightly different expectation about what we were blocking
for (as we have already dicscussed at length :-). Anyway,
I've knocked up some modifications to the documentation,
which you're welcome to use, abuse, or reject out of hand.

I've done this in the form of modifications to the source
code. I assume that's the correct approach, but the 2.3
source code and 2.3 HTML documentation seem to be a bit
different (so I ended up incorporating the relevant HTML
doco into the python source doco, then modifying that).

The patch is the output from:
% diff Queue_v2_3.py Queue_doc_change.py

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-18 00:41

Message:
Logged In: YES 
user_id=31435

It depends on what you mean by &quot;blocking&quot; &lt;wink&gt;.  If the 
thread implementation schedules fairly, it's impossible for 
self.mutex to be held for a &quot;long&quot; time by any thread -- unlike 
esema and fsema, self.mutex is used only for mutual exclusion 
over brief sections of code that don't wait for anything, and 
nothing Queue clients do can cause self.mutex to be held for 
an arbitrarily long time (a spectacularly bad OS 
implementation of thread scheduling could, but that's out of 
the user's-- and out of Python's --hands).

The usual meaning of &quot;blocking&quot; is that clients *can* do 
something to get the system into a state where a call can 
take arbitrarily long to complete (while assuming fair thread 
scheduling).  The obvious example here is that Queue.get() 
can take forever if the Queue is empty and the app stops 
adding anything to the Queue.  There's nothing (sane) the 
app can do that can make Queue.get_nowait() take forever.

BTW, I hope you're looking at the 2.3 code here!  Queue is 
more complicated in 2.3 because these methods have also 
grown optional timeout arguments.  If you're really worried 
about &quot;spurious&quot; Full exceptions, doing a blocking 2.3 
Queue.put() call with a short timeout will try to grab fsema 
several times before giving up.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 23:52

Message:
Logged In: YES 
user_id=693152

Whoops - let's try that question in a clearer way:

When you do a non-blocking call to put(), why does it
acquire mutex in a blocking way (ie. &quot;put(block=False)&quot; will
call &quot;mutex.acquire()&quot;, which could block whilst acquiring
mutex). I thought the theory was that you *never* block
anywhere.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 23:32

Message:
Logged In: YES 
user_id=31435

We acquire a mutex with a blocking call because the use of a 
blocking call announces that the client is *willing* to block, 
and nothing about the state of a Queue can be changed 
without acquiring a lock first.  So it wouldn't make sense not 
to acquire a lock in that case.

I have no objection at all to improving the docs.  They appear 
to be what they are now because the original version of the 
Queue module didn't have a non-blocking put() method, or a 
Full exception.  I added those 7(!) years later, in 1999.  
Development was done by emailing changes to Guido at that 
time, though, and doc changes were often dropped on the 
floor.

If you can work up a doc patch to supply words that would 
make better sense to you, that would be great.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 22:53

Message:
Logged In: YES 
user_id=693152

First up, you're right that non-blocking calls are unusual.
This isn't exactly a critical matter for me :-)

Okay, I have misunderstood the meaning of non-blocking calls
- so it actually means &quot;ensure we never under any
circumstances block&quot;. Why then do we acquire mutex with a
blocking call?

I am not suggesting there's anything wrong with the naming
of Full (amusing as your suggestion is :-). Of course you
can't completely describe how an exception will be used in
it's name.

It just seems more intuitive for put's documentation to
fully and unambiguously describe when an exception is
raised, rather than to have part of the function
documentation (&quot;or locked&quot;) in the Exception documentation.
More straightforward, etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 22:22

Message:
Logged In: YES 
user_id=31435

The primary point of a non-blocking call is never to block.  
That's the common meaning of &quot;non-blocking&quot; (in or out of 
Python).  After all, a &quot;non-blocking&quot; call that *could* block is 
useless for apps that need not to block.  If you're willing to 
block, use the blocking methods (which most apps do use, 
BTW -- using the non-blocking methods is unusual).

The Full exception isn't raised incorrectly.  &quot;Full&quot; is just 4 
letters strung together, and is only meant to be suggestive 
and convenient -- its full meaning is explained in the docs, 
albeit somewhat cryptically.  I don't think it would be a real 
improvement to, e.g., rename this exception to 
FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo
WeSkippedThat &lt;wink&gt;.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 21:55

Message:
Logged In: YES 
user_id=693152

Sorry - my fault. I didn't read that part of the doco well
enough.

However, is it an issue that important behaviour of a
function is described separately to the function (ie. in the
exception)? Could we put a general note in the put/get
documentation also (Eg. &quot;In the current implementation the
Full exception may sometimes be raised incorrectly.&quot;)

Also, I may have the wrong expectations for how this class
should behave. My assumption was that put(block=False) means
 don't block waiting for a slot in the queue, but it's
implicitly okay to block for other reasons (eg. internal
data sharing, as actually happens with mutex). Was this
incorrect?

I'll see if I can think up an alternative implementation
over the next few days.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 15:50

Message:
Logged In: YES 
user_id=31435

Yes, but unless it's a screamingly obvious non-bug I like to 
wait at least a week to see whether somebody else has a 
clever approach that works as well but without the surprising 
parts.  The docs in this case aren't terribly clear, because 
they really can't explain the whole truth without explaining 
the implementation.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-17 15:30

Message:
Logged In: YES 
user_id=80475

Can this be closed as invalid?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-14 09:59

Message:
Logged In: YES 
user_id=31435

As the docs say (ALL CAPS emphasis added),

&quot;&quot;&quot;
exception Full 

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full OR LOCKED. 
&quot;&quot;&quot;

and similarly for Empty.  The primary point of a non-blocking 
call is never to block, and that's why &quot;or locked&quot; is in the 
docs.  A BoundedSemaphore (or any other &quot;reliable&quot; 
synchronization gimmick) could block, so cannot be used.

In practice, it doesn't matter:  a Queue user who wants to 
use non-blocking calls has to be prepared for Full or Empty 
exceptions, and that's the end of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 08:32:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 08:32:53 2004
Subject: [ python-Bugs-788520 ] Queue class has logic error when non-blocking
Message-ID: <E1BjXtH-000749-00@sc8-sf-web4.sourceforge.net>

Bugs item #788520, was opened at 2003-08-14 00:57
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Queue class has logic error when non-blocking

Initial Comment:
Looking at the Queue class, I noticed that it might
incorrectly raise a Full/Empty Exception when called
with block=False.

This leads to the following undesirable behaviour:
 * Full exception raised when Queue not full
 * Full exception raised when Queue has no maxsize

Here's my logic (for put(), but get() is similar):

First part of code for put, in Queue.py:
    def put(self, item, block=1):
        if block:
            self.fsema.acquire()
        elif not self.fsema.acquire(0):
            raise Full

Now, for the purposes of raising a Full exception, we
are assuming that fsema is locked if and only if the
Queue is full.

BUT, it seems that fsema is locked every time an item
is added to the Queue, even if that item would not make
the Queue full.

Hence, it might be possible for a Full exception to be
raised, when fsema is locked due to adding an item that
would not  actually make the Queue full. 

An example...

 * Queue with maxsize 10, currently 5 objects in it.
 * Threads T1 and T2, both trying to add an item with
Queue.put(item, block=True).
 * This should obviously be fine, resulting in a Queue
with 7 items.
 [1] Call T1.put(item1, block=True)
 [2] Call T2.put(item2, block=True)
 [3] T1 grabs fsema and mutex, but then the current
thread changes before they are released...
 [4] T2 cannot acquire fsema (since T1 currently has
it), and so raises the Full exception (incorrectly)

Of course, I may have misunderstood something, since I
haven't been able to consistently reproduce the problem
(threading errors are so vexing).

I have no easy solution to this issue (redo the class
using a threading.BoundedSemaphore to count the Queue
length?).

My python version:
Python 2.2.2 (#1, Feb 24 2003, 17:36:09)
[GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-11 02:32

Message:
Logged In: YES 
user_id=31435

berryman77, as the first comment in this report suggested, 
read the documentation:

"""
Full

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full or locked. 
"""

Note the "OR LOCKED" part, a natural counterpoint to 
your "NOT FULL" screaming <wink>.

When code functions as designed and as documented, you 
can argue about the design, or about the quality of the docs, 
but you can't call it "a bug" (well, not if you want to be taken 
seriously).

The name of the exception is simply briefly suggestive, as are 
the names of most exceptions; 
FULL_OR_NOT_FULL_BUT_LOCKED would be more accurate, 
but too clumsy.


----------------------------------------------------------------------

Comment By: Randall B. Smith (berryman77)
Date: 2004-07-11 02:00

Message:
Logged In: YES 
user_id=880241

A Full exception is returned when the queue is NOT FULL. 
This is a bug!  The lack of an immediate solution is not an
excuse to accept incorrect code.



----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-21 23:40

Message:
Logged In: YES 
user_id=693152

Okay, that makes more sense. So, loosely expressed,
non-blocking means there's no way the user can put the Queue
in a blocked state (and especially not deadlocked) - as with
your example of waiting forever on a get call. But,
obviously, internal locks can always be used (in a careful
manner).

I think that's closer to my implicit understand of blocking
that I was trying to express. In the case of put/get, I had
a slightly different expectation about what we were blocking
for (as we have already dicscussed at length :-). Anyway,
I've knocked up some modifications to the documentation,
which you're welcome to use, abuse, or reject out of hand.

I've done this in the form of modifications to the source
code. I assume that's the correct approach, but the 2.3
source code and 2.3 HTML documentation seem to be a bit
different (so I ended up incorporating the relevant HTML
doco into the python source doco, then modifying that).

The patch is the output from:
% diff Queue_v2_3.py Queue_doc_change.py

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-18 01:41

Message:
Logged In: YES 
user_id=31435

It depends on what you mean by &quot;blocking&quot; &lt;wink&gt;.  If the 
thread implementation schedules fairly, it's impossible for 
self.mutex to be held for a &quot;long&quot; time by any thread -- unlike 
esema and fsema, self.mutex is used only for mutual exclusion 
over brief sections of code that don't wait for anything, and 
nothing Queue clients do can cause self.mutex to be held for 
an arbitrarily long time (a spectacularly bad OS 
implementation of thread scheduling could, but that's out of 
the user's-- and out of Python's --hands).

The usual meaning of &quot;blocking&quot; is that clients *can* do 
something to get the system into a state where a call can 
take arbitrarily long to complete (while assuming fair thread 
scheduling).  The obvious example here is that Queue.get() 
can take forever if the Queue is empty and the app stops 
adding anything to the Queue.  There's nothing (sane) the 
app can do that can make Queue.get_nowait() take forever.

BTW, I hope you're looking at the 2.3 code here!  Queue is 
more complicated in 2.3 because these methods have also 
grown optional timeout arguments.  If you're really worried 
about &quot;spurious&quot; Full exceptions, doing a blocking 2.3 
Queue.put() call with a short timeout will try to grab fsema 
several times before giving up.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-18 00:52

Message:
Logged In: YES 
user_id=693152

Whoops - let's try that question in a clearer way:

When you do a non-blocking call to put(), why does it
acquire mutex in a blocking way (ie. &quot;put(block=False)&quot; will
call &quot;mutex.acquire()&quot;, which could block whilst acquiring
mutex). I thought the theory was that you *never* block
anywhere.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-18 00:32

Message:
Logged In: YES 
user_id=31435

We acquire a mutex with a blocking call because the use of a 
blocking call announces that the client is *willing* to block, 
and nothing about the state of a Queue can be changed 
without acquiring a lock first.  So it wouldn't make sense not 
to acquire a lock in that case.

I have no objection at all to improving the docs.  They appear 
to be what they are now because the original version of the 
Queue module didn't have a non-blocking put() method, or a 
Full exception.  I added those 7(!) years later, in 1999.  
Development was done by emailing changes to Guido at that 
time, though, and doc changes were often dropped on the 
floor.

If you can work up a doc patch to supply words that would 
make better sense to you, that would be great.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 23:53

Message:
Logged In: YES 
user_id=693152

First up, you're right that non-blocking calls are unusual.
This isn't exactly a critical matter for me :-)

Okay, I have misunderstood the meaning of non-blocking calls
- so it actually means &quot;ensure we never under any
circumstances block&quot;. Why then do we acquire mutex with a
blocking call?

I am not suggesting there's anything wrong with the naming
of Full (amusing as your suggestion is :-). Of course you
can't completely describe how an exception will be used in
it's name.

It just seems more intuitive for put's documentation to
fully and unambiguously describe when an exception is
raised, rather than to have part of the function
documentation (&quot;or locked&quot;) in the Exception documentation.
More straightforward, etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 23:22

Message:
Logged In: YES 
user_id=31435

The primary point of a non-blocking call is never to block.  
That's the common meaning of &quot;non-blocking&quot; (in or out of 
Python).  After all, a &quot;non-blocking&quot; call that *could* block is 
useless for apps that need not to block.  If you're willing to 
block, use the blocking methods (which most apps do use, 
BTW -- using the non-blocking methods is unusual).

The Full exception isn't raised incorrectly.  &quot;Full&quot; is just 4 
letters strung together, and is only meant to be suggestive 
and convenient -- its full meaning is explained in the docs, 
albeit somewhat cryptically.  I don't think it would be a real 
improvement to, e.g., rename this exception to 
FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo
WeSkippedThat &lt;wink&gt;.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 22:55

Message:
Logged In: YES 
user_id=693152

Sorry - my fault. I didn't read that part of the doco well
enough.

However, is it an issue that important behaviour of a
function is described separately to the function (ie. in the
exception)? Could we put a general note in the put/get
documentation also (Eg. &quot;In the current implementation the
Full exception may sometimes be raised incorrectly.&quot;)

Also, I may have the wrong expectations for how this class
should behave. My assumption was that put(block=False) means
 don't block waiting for a slot in the queue, but it's
implicitly okay to block for other reasons (eg. internal
data sharing, as actually happens with mutex). Was this
incorrect?

I'll see if I can think up an alternative implementation
over the next few days.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 16:50

Message:
Logged In: YES 
user_id=31435

Yes, but unless it's a screamingly obvious non-bug I like to 
wait at least a week to see whether somebody else has a 
clever approach that works as well but without the surprising 
parts.  The docs in this case aren't terribly clear, because 
they really can't explain the whole truth without explaining 
the implementation.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-17 16:30

Message:
Logged In: YES 
user_id=80475

Can this be closed as invalid?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-14 10:59

Message:
Logged In: YES 
user_id=31435

As the docs say (ALL CAPS emphasis added),

&quot;&quot;&quot;
exception Full 

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full OR LOCKED. 
&quot;&quot;&quot;

and similarly for Empty.  The primary point of a non-blocking 
call is never to block, and that's why &quot;or locked&quot; is in the 
docs.  A BoundedSemaphore (or any other &quot;reliable&quot; 
synchronization gimmick) could block, so cannot be used.

In practice, it doesn't matter:  a Queue user who wants to 
use non-blocking calls has to be prepared for Full or Empty 
exceptions, and that's the end of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 15:50:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 15:50:21 2004
Subject: [ python-Bugs-987870 ] Windows installer for 2.4a1 shows
	non-standard version
Message-ID: <E1Bjeib-0002gd-00@sc8-sf-web4.sourceforge.net>

Bugs item #987870, was opened at 2004-07-09 12:03
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470

Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: Windows installer for 2.4a1 shows non-standard version

Initial Comment:
The Windows installer (MSI) for Python 2.4a1 displays 
the Python version as 2.4.0.12607. This is not the 
standard version format, which should show as 2.4a0.

While this is mainly a cosmetic issue, it will make it 
difficult to verify that the version installed matches the 
latest released alpha/beta. (It's not clear whether the 
final number - the 12607 - will be dropped with the 
release, so this may not be an issue for 2.4 final).

----------------------------------------------------------------------

>Comment By: Paul Moore (pmoore)
Date: 2004-07-11 14:50

Message:
Logged In: YES 
user_id=113328

I'm closing this myself, as "won't fix". I assume that's OK.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-10 10:31

Message:
Logged In: YES 
user_id=113328

Fair enough. So the final release will show 2.4 (or 2.4.0?).
That's the main thing, I guess.

I'm happy for this to be closed as something that the MSI
format doesn't support. (Can I do that myself...?)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-09 21:13

Message:
Logged In: YES 
user_id=21627

It is no issue for the final release, which will drop this
number.

The version number must be a number, so it can't be 2.4a1.
The text displayed in the dialogs could be different, of
course - it just would be more work to make it so.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-09 13:15

Message:
Logged In: YES 
user_id=11105

Martin v. Loewis builds the MSI's.  Assigned to him.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 17:47:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 17:47:21 2004
Subject: [ python-Bugs-450803 ] smtpd.py needs documentation
Message-ID: <E1BjgXr-0002BW-00@sc8-sf-web1.sourceforge.net>

Bugs item #450803, was opened at 2001-08-14 10:18
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Barry A. Warsaw (bwarsaw)
>Assigned to: Just van Rossum (jvr)
Summary: smtpd.py needs documentation

Initial Comment:
smtpd.py needs documentation for the standard library

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-11 11:47

Message:
Logged In: YES 
user_id=3066

Michael:  Thanks for reviewing this!  I'll have it committed
shortly.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 21:21

Message:
Logged In: YES 
user_id=99874

Update: I got the docs compiling on my machine, and I can
confirm that there are no other errors. I've also learned
that file should be named "libsmptd.tex" instead, and
there's a trivial one-line addition needed in lib.tex. But,
of course, you already knew that <wink>.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 14:55

Message:
Logged In: YES 
user_id=99874

I think moshez's text may be minimal but it's way better
than having NO docs. So I propose we accept it as-is: we can
always improve things later. With that in mind, I am
re-assigning this to Fred, and I've also revised moshez's
attachment slightly. Add this file as smptd.tex in
python/dist/src/Doc/lib and it should work. (I've made it
pass texcheck.py, there could still be some higher-level tex
errors.)

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2002-06-11 05:48

Message:
Logged In: YES 
user_id=11645

Here's something you can use as a start, Barry.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 17:50:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 17:50:57 2004
Subject: [ python-Bugs-450803 ] smtpd.py needs documentation
Message-ID: <E1BjgbN-000297-00@sc8-sf-web3.sourceforge.net>

Bugs item #450803, was opened at 2001-08-14 10:18
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Barry A. Warsaw (bwarsaw)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: smtpd.py needs documentation

Initial Comment:
smtpd.py needs documentation for the standard library

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-11 11:50

Message:
Logged In: YES 
user_id=3066

Sorry, Just, didn't mean to assign this to you!  Not sure
how I did that...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-11 11:47

Message:
Logged In: YES 
user_id=3066

Michael:  Thanks for reviewing this!  I'll have it committed
shortly.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 21:21

Message:
Logged In: YES 
user_id=99874

Update: I got the docs compiling on my machine, and I can
confirm that there are no other errors. I've also learned
that file should be named "libsmptd.tex" instead, and
there's a trivial one-line addition needed in lib.tex. But,
of course, you already knew that <wink>.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 14:55

Message:
Logged In: YES 
user_id=99874

I think moshez's text may be minimal but it's way better
than having NO docs. So I propose we accept it as-is: we can
always improve things later. With that in mind, I am
re-assigning this to Fred, and I've also revised moshez's
attachment slightly. Add this file as smptd.tex in
python/dist/src/Doc/lib and it should work. (I've made it
pass texcheck.py, there could still be some higher-level tex
errors.)

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2002-06-11 05:48

Message:
Logged In: YES 
user_id=11645

Here's something you can use as a start, Barry.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 18:26:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 18:26:16 2004
Subject: [ python-Bugs-450803 ] smtpd.py needs documentation
Message-ID: <E1Bjh9Y-0003BR-00@sc8-sf-web3.sourceforge.net>

Bugs item #450803, was opened at 2001-08-14 10:18
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: smtpd.py needs documentation

Initial Comment:
smtpd.py needs documentation for the standard library

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-11 12:26

Message:
Logged In: YES 
user_id=3066

Committed to CVS:

Doc/Makefile.deps  1.117
Doc/lib/lib.tex  1.228
Doc/lib/libsmtpd.tex  1.1

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-11 11:50

Message:
Logged In: YES 
user_id=3066

Sorry, Just, didn't mean to assign this to you!  Not sure
how I did that...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-11 11:47

Message:
Logged In: YES 
user_id=3066

Michael:  Thanks for reviewing this!  I'll have it committed
shortly.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 21:21

Message:
Logged In: YES 
user_id=99874

Update: I got the docs compiling on my machine, and I can
confirm that there are no other errors. I've also learned
that file should be named "libsmptd.tex" instead, and
there's a trivial one-line addition needed in lib.tex. But,
of course, you already knew that <wink>.

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-10 14:55

Message:
Logged In: YES 
user_id=99874

I think moshez's text may be minimal but it's way better
than having NO docs. So I propose we accept it as-is: we can
always improve things later. With that in mind, I am
re-assigning this to Fred, and I've also revised moshez's
attachment slightly. Add this file as smptd.tex in
python/dist/src/Doc/lib and it should work. (I've made it
pass texcheck.py, there could still be some higher-level tex
errors.)

----------------------------------------------------------------------

Comment By: Moshe Zadka (moshez)
Date: 2002-06-11 05:48

Message:
Logged In: YES 
user_id=11645

Here's something you can use as a start, Barry.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450803&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 21:13:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 21:13:40 2004
Subject: [ python-Bugs-788520 ] Queue class has logic error when non-blocking
Message-ID: <E1BjjlU-0008GG-00@sc8-sf-web3.sourceforge.net>

Bugs item #788520, was opened at 2003-08-13 23:57
Message generated for change (Comment added) made by berryman77
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Queue class has logic error when non-blocking

Initial Comment:
Looking at the Queue class, I noticed that it might
incorrectly raise a Full/Empty Exception when called
with block=False.

This leads to the following undesirable behaviour:
 * Full exception raised when Queue not full
 * Full exception raised when Queue has no maxsize

Here's my logic (for put(), but get() is similar):

First part of code for put, in Queue.py:
    def put(self, item, block=1):
        if block:
            self.fsema.acquire()
        elif not self.fsema.acquire(0):
            raise Full

Now, for the purposes of raising a Full exception, we
are assuming that fsema is locked if and only if the
Queue is full.

BUT, it seems that fsema is locked every time an item
is added to the Queue, even if that item would not make
the Queue full.

Hence, it might be possible for a Full exception to be
raised, when fsema is locked due to adding an item that
would not  actually make the Queue full. 

An example...

 * Queue with maxsize 10, currently 5 objects in it.
 * Threads T1 and T2, both trying to add an item with
Queue.put(item, block=True).
 * This should obviously be fine, resulting in a Queue
with 7 items.
 [1] Call T1.put(item1, block=True)
 [2] Call T2.put(item2, block=True)
 [3] T1 grabs fsema and mutex, but then the current
thread changes before they are released...
 [4] T2 cannot acquire fsema (since T1 currently has
it), and so raises the Full exception (incorrectly)

Of course, I may have misunderstood something, since I
haven't been able to consistently reproduce the problem
(threading errors are so vexing).

I have no easy solution to this issue (redo the class
using a threading.BoundedSemaphore to count the Queue
length?).

My python version:
Python 2.2.2 (#1, Feb 24 2003, 17:36:09)
[GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2

----------------------------------------------------------------------

Comment By: Randall B. Smith (berryman77)
Date: 2004-07-11 14:13

Message:
Logged In: YES 
user_id=880241

Rather than reiterating here, I agree with this post: 

Date: 2003-08-17 21:55
Sender: gazzadee

I did read the docs for the put method, but not for the Full
Exception, as I assumed it means the queue is full. 
Although the documentation of the Full exception makes the
code technically correct, I found (as several of the posters
here did) that it is unintuitive.  So much so that it
appears to be a bug (hence this bug report).  As I see it,
the documentation simply documents the bug.

"""
The name of the exception is simply briefly suggestive, as are 
the names of most exceptions; 
FULL_OR_NOT_FULL_BUT_LOCKED would be more accurate, 
but too clumsy.
"""

The programmer is not aware of the internal blocking unless
s/he has looked at the source of Queue.  S/he is most likely
expecting put_nowait() to not wait on the queue to free a
slot.  This is to me the intuitive functionality of this
method. According to the comments here,  there is
disagreement on this issue.  So if put_nowait means there is
to be no blocking internally or by the queue, then there
should be 2 exceptions, Full and Locked, so that the user
can distinguish between the two.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-11 01:32

Message:
Logged In: YES 
user_id=31435

berryman77, as the first comment in this report suggested, 
read the documentation:

"""
Full

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full or locked. 
"""

Note the "OR LOCKED" part, a natural counterpoint to 
your "NOT FULL" screaming <wink>.

When code functions as designed and as documented, you 
can argue about the design, or about the quality of the docs, 
but you can't call it "a bug" (well, not if you want to be taken 
seriously).

The name of the exception is simply briefly suggestive, as are 
the names of most exceptions; 
FULL_OR_NOT_FULL_BUT_LOCKED would be more accurate, 
but too clumsy.


----------------------------------------------------------------------

Comment By: Randall B. Smith (berryman77)
Date: 2004-07-11 01:00

Message:
Logged In: YES 
user_id=880241

A Full exception is returned when the queue is NOT FULL. 
This is a bug!  The lack of an immediate solution is not an
excuse to accept incorrect code.



----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-21 22:40

Message:
Logged In: YES 
user_id=693152

Okay, that makes more sense. So, loosely expressed,
non-blocking means there's no way the user can put the Queue
in a blocked state (and especially not deadlocked) - as with
your example of waiting forever on a get call. But,
obviously, internal locks can always be used (in a careful
manner).

I think that's closer to my implicit understand of blocking
that I was trying to express. In the case of put/get, I had
a slightly different expectation about what we were blocking
for (as we have already dicscussed at length :-). Anyway,
I've knocked up some modifications to the documentation,
which you're welcome to use, abuse, or reject out of hand.

I've done this in the form of modifications to the source
code. I assume that's the correct approach, but the 2.3
source code and 2.3 HTML documentation seem to be a bit
different (so I ended up incorporating the relevant HTML
doco into the python source doco, then modifying that).

The patch is the output from:
% diff Queue_v2_3.py Queue_doc_change.py

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-18 00:41

Message:
Logged In: YES 
user_id=31435

It depends on what you mean by &quot;blocking&quot; &lt;wink&gt;.  If the 
thread implementation schedules fairly, it's impossible for 
self.mutex to be held for a &quot;long&quot; time by any thread -- unlike 
esema and fsema, self.mutex is used only for mutual exclusion 
over brief sections of code that don't wait for anything, and 
nothing Queue clients do can cause self.mutex to be held for 
an arbitrarily long time (a spectacularly bad OS 
implementation of thread scheduling could, but that's out of 
the user's-- and out of Python's --hands).

The usual meaning of &quot;blocking&quot; is that clients *can* do 
something to get the system into a state where a call can 
take arbitrarily long to complete (while assuming fair thread 
scheduling).  The obvious example here is that Queue.get() 
can take forever if the Queue is empty and the app stops 
adding anything to the Queue.  There's nothing (sane) the 
app can do that can make Queue.get_nowait() take forever.

BTW, I hope you're looking at the 2.3 code here!  Queue is 
more complicated in 2.3 because these methods have also 
grown optional timeout arguments.  If you're really worried 
about &quot;spurious&quot; Full exceptions, doing a blocking 2.3 
Queue.put() call with a short timeout will try to grab fsema 
several times before giving up.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 23:52

Message:
Logged In: YES 
user_id=693152

Whoops - let's try that question in a clearer way:

When you do a non-blocking call to put(), why does it
acquire mutex in a blocking way (ie. &quot;put(block=False)&quot; will
call &quot;mutex.acquire()&quot;, which could block whilst acquiring
mutex). I thought the theory was that you *never* block
anywhere.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 23:32

Message:
Logged In: YES 
user_id=31435

We acquire a mutex with a blocking call because the use of a 
blocking call announces that the client is *willing* to block, 
and nothing about the state of a Queue can be changed 
without acquiring a lock first.  So it wouldn't make sense not 
to acquire a lock in that case.

I have no objection at all to improving the docs.  They appear 
to be what they are now because the original version of the 
Queue module didn't have a non-blocking put() method, or a 
Full exception.  I added those 7(!) years later, in 1999.  
Development was done by emailing changes to Guido at that 
time, though, and doc changes were often dropped on the 
floor.

If you can work up a doc patch to supply words that would 
make better sense to you, that would be great.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 22:53

Message:
Logged In: YES 
user_id=693152

First up, you're right that non-blocking calls are unusual.
This isn't exactly a critical matter for me :-)

Okay, I have misunderstood the meaning of non-blocking calls
- so it actually means &quot;ensure we never under any
circumstances block&quot;. Why then do we acquire mutex with a
blocking call?

I am not suggesting there's anything wrong with the naming
of Full (amusing as your suggestion is :-). Of course you
can't completely describe how an exception will be used in
it's name.

It just seems more intuitive for put's documentation to
fully and unambiguously describe when an exception is
raised, rather than to have part of the function
documentation (&quot;or locked&quot;) in the Exception documentation.
More straightforward, etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 22:22

Message:
Logged In: YES 
user_id=31435

The primary point of a non-blocking call is never to block.  
That's the common meaning of &quot;non-blocking&quot; (in or out of 
Python).  After all, a &quot;non-blocking&quot; call that *could* block is 
useless for apps that need not to block.  If you're willing to 
block, use the blocking methods (which most apps do use, 
BTW -- using the non-blocking methods is unusual).

The Full exception isn't raised incorrectly.  &quot;Full&quot; is just 4 
letters strung together, and is only meant to be suggestive 
and convenient -- its full meaning is explained in the docs, 
albeit somewhat cryptically.  I don't think it would be a real 
improvement to, e.g., rename this exception to 
FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo
WeSkippedThat &lt;wink&gt;.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 21:55

Message:
Logged In: YES 
user_id=693152

Sorry - my fault. I didn't read that part of the doco well
enough.

However, is it an issue that important behaviour of a
function is described separately to the function (ie. in the
exception)? Could we put a general note in the put/get
documentation also (Eg. &quot;In the current implementation the
Full exception may sometimes be raised incorrectly.&quot;)

Also, I may have the wrong expectations for how this class
should behave. My assumption was that put(block=False) means
 don't block waiting for a slot in the queue, but it's
implicitly okay to block for other reasons (eg. internal
data sharing, as actually happens with mutex). Was this
incorrect?

I'll see if I can think up an alternative implementation
over the next few days.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 15:50

Message:
Logged In: YES 
user_id=31435

Yes, but unless it's a screamingly obvious non-bug I like to 
wait at least a week to see whether somebody else has a 
clever approach that works as well but without the surprising 
parts.  The docs in this case aren't terribly clear, because 
they really can't explain the whole truth without explaining 
the implementation.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-17 15:30

Message:
Logged In: YES 
user_id=80475

Can this be closed as invalid?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-14 09:59

Message:
Logged In: YES 
user_id=31435

As the docs say (ALL CAPS emphasis added),

&quot;&quot;&quot;
exception Full 

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full OR LOCKED. 
&quot;&quot;&quot;

and similarly for Empty.  The primary point of a non-blocking 
call is never to block, and that's why &quot;or locked&quot; is in the 
docs.  A BoundedSemaphore (or any other &quot;reliable&quot; 
synchronization gimmick) could block, so cannot be used.

In practice, it doesn't matter:  a Queue user who wants to 
use non-blocking calls has to be prepared for Full or Empty 
exceptions, and that's the end of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 21:47:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 21:47:58 2004
Subject: [ python-Bugs-788520 ] Queue class has logic error when non-blocking
Message-ID: <E1BjkIe-0004fu-00@sc8-sf-web4.sourceforge.net>

Bugs item #788520, was opened at 2003-08-14 00:57
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470

Category: Threads
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Queue class has logic error when non-blocking

Initial Comment:
Looking at the Queue class, I noticed that it might
incorrectly raise a Full/Empty Exception when called
with block=False.

This leads to the following undesirable behaviour:
 * Full exception raised when Queue not full
 * Full exception raised when Queue has no maxsize

Here's my logic (for put(), but get() is similar):

First part of code for put, in Queue.py:
    def put(self, item, block=1):
        if block:
            self.fsema.acquire()
        elif not self.fsema.acquire(0):
            raise Full

Now, for the purposes of raising a Full exception, we
are assuming that fsema is locked if and only if the
Queue is full.

BUT, it seems that fsema is locked every time an item
is added to the Queue, even if that item would not make
the Queue full.

Hence, it might be possible for a Full exception to be
raised, when fsema is locked due to adding an item that
would not  actually make the Queue full. 

An example...

 * Queue with maxsize 10, currently 5 objects in it.
 * Threads T1 and T2, both trying to add an item with
Queue.put(item, block=True).
 * This should obviously be fine, resulting in a Queue
with 7 items.
 [1] Call T1.put(item1, block=True)
 [2] Call T2.put(item2, block=True)
 [3] T1 grabs fsema and mutex, but then the current
thread changes before they are released...
 [4] T2 cannot acquire fsema (since T1 currently has
it), and so raises the Full exception (incorrectly)

Of course, I may have misunderstood something, since I
haven't been able to consistently reproduce the problem
(threading errors are so vexing).

I have no easy solution to this issue (redo the class
using a threading.BoundedSemaphore to count the Queue
length?).

My python version:
Python 2.2.2 (#1, Feb 24 2003, 17:36:09)
[GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-11 15:47

Message:
Logged In: YES 
user_id=31435

Well, there aren't "several posters" here:  before you jumped 
in, there were exactly three in this report's history:  the 
person who filed the original report (gazzadee), me, and 
Raymond Hettinger (who asked once whether to close the 
report as invalid).  In the 11 months this has been open, 
nobody else has cared enough to comment, let alone produce 
a different implementation.

The reasons the current implementation is reasonable have 
already been explained here at some length, so I'm not going 
over them again.  If you can't tolerate the Full or Empty 
exceptions. don't use non-blocking calls.  It's typical of non-
blocking calls (in and out of Python) that they may return for 
no other reason than that they cannot succeed immediately, 
so honor their contract not to block by returning at once but 
without a useful response.

I still agree the docs could stand improvement.

----------------------------------------------------------------------

Comment By: Randall B. Smith (berryman77)
Date: 2004-07-11 15:13

Message:
Logged In: YES 
user_id=880241

Rather than reiterating here, I agree with this post: 

Date: 2003-08-17 21:55
Sender: gazzadee

I did read the docs for the put method, but not for the Full
Exception, as I assumed it means the queue is full. 
Although the documentation of the Full exception makes the
code technically correct, I found (as several of the posters
here did) that it is unintuitive.  So much so that it
appears to be a bug (hence this bug report).  As I see it,
the documentation simply documents the bug.

"""
The name of the exception is simply briefly suggestive, as are 
the names of most exceptions; 
FULL_OR_NOT_FULL_BUT_LOCKED would be more accurate, 
but too clumsy.
"""

The programmer is not aware of the internal blocking unless
s/he has looked at the source of Queue.  S/he is most likely
expecting put_nowait() to not wait on the queue to free a
slot.  This is to me the intuitive functionality of this
method. According to the comments here,  there is
disagreement on this issue.  So if put_nowait means there is
to be no blocking internally or by the queue, then there
should be 2 exceptions, Full and Locked, so that the user
can distinguish between the two.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-11 02:32

Message:
Logged In: YES 
user_id=31435

berryman77, as the first comment in this report suggested, 
read the documentation:

"""
Full

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full or locked. 
"""

Note the "OR LOCKED" part, a natural counterpoint to 
your "NOT FULL" screaming <wink>.

When code functions as designed and as documented, you 
can argue about the design, or about the quality of the docs, 
but you can't call it "a bug" (well, not if you want to be taken 
seriously).

The name of the exception is simply briefly suggestive, as are 
the names of most exceptions; 
FULL_OR_NOT_FULL_BUT_LOCKED would be more accurate, 
but too clumsy.


----------------------------------------------------------------------

Comment By: Randall B. Smith (berryman77)
Date: 2004-07-11 02:00

Message:
Logged In: YES 
user_id=880241

A Full exception is returned when the queue is NOT FULL. 
This is a bug!  The lack of an immediate solution is not an
excuse to accept incorrect code.



----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-21 23:40

Message:
Logged In: YES 
user_id=693152

Okay, that makes more sense. So, loosely expressed,
non-blocking means there's no way the user can put the Queue
in a blocked state (and especially not deadlocked) - as with
your example of waiting forever on a get call. But,
obviously, internal locks can always be used (in a careful
manner).

I think that's closer to my implicit understand of blocking
that I was trying to express. In the case of put/get, I had
a slightly different expectation about what we were blocking
for (as we have already dicscussed at length :-). Anyway,
I've knocked up some modifications to the documentation,
which you're welcome to use, abuse, or reject out of hand.

I've done this in the form of modifications to the source
code. I assume that's the correct approach, but the 2.3
source code and 2.3 HTML documentation seem to be a bit
different (so I ended up incorporating the relevant HTML
doco into the python source doco, then modifying that).

The patch is the output from:
% diff Queue_v2_3.py Queue_doc_change.py

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-18 01:41

Message:
Logged In: YES 
user_id=31435

It depends on what you mean by &quot;blocking&quot; &lt;wink&gt;.  If the 
thread implementation schedules fairly, it's impossible for 
self.mutex to be held for a &quot;long&quot; time by any thread -- unlike 
esema and fsema, self.mutex is used only for mutual exclusion 
over brief sections of code that don't wait for anything, and 
nothing Queue clients do can cause self.mutex to be held for 
an arbitrarily long time (a spectacularly bad OS 
implementation of thread scheduling could, but that's out of 
the user's-- and out of Python's --hands).

The usual meaning of &quot;blocking&quot; is that clients *can* do 
something to get the system into a state where a call can 
take arbitrarily long to complete (while assuming fair thread 
scheduling).  The obvious example here is that Queue.get() 
can take forever if the Queue is empty and the app stops 
adding anything to the Queue.  There's nothing (sane) the 
app can do that can make Queue.get_nowait() take forever.

BTW, I hope you're looking at the 2.3 code here!  Queue is 
more complicated in 2.3 because these methods have also 
grown optional timeout arguments.  If you're really worried 
about &quot;spurious&quot; Full exceptions, doing a blocking 2.3 
Queue.put() call with a short timeout will try to grab fsema 
several times before giving up.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-18 00:52

Message:
Logged In: YES 
user_id=693152

Whoops - let's try that question in a clearer way:

When you do a non-blocking call to put(), why does it
acquire mutex in a blocking way (ie. &quot;put(block=False)&quot; will
call &quot;mutex.acquire()&quot;, which could block whilst acquiring
mutex). I thought the theory was that you *never* block
anywhere.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-18 00:32

Message:
Logged In: YES 
user_id=31435

We acquire a mutex with a blocking call because the use of a 
blocking call announces that the client is *willing* to block, 
and nothing about the state of a Queue can be changed 
without acquiring a lock first.  So it wouldn't make sense not 
to acquire a lock in that case.

I have no objection at all to improving the docs.  They appear 
to be what they are now because the original version of the 
Queue module didn't have a non-blocking put() method, or a 
Full exception.  I added those 7(!) years later, in 1999.  
Development was done by emailing changes to Guido at that 
time, though, and doc changes were often dropped on the 
floor.

If you can work up a doc patch to supply words that would 
make better sense to you, that would be great.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 23:53

Message:
Logged In: YES 
user_id=693152

First up, you're right that non-blocking calls are unusual.
This isn't exactly a critical matter for me :-)

Okay, I have misunderstood the meaning of non-blocking calls
- so it actually means &quot;ensure we never under any
circumstances block&quot;. Why then do we acquire mutex with a
blocking call?

I am not suggesting there's anything wrong with the naming
of Full (amusing as your suggestion is :-). Of course you
can't completely describe how an exception will be used in
it's name.

It just seems more intuitive for put's documentation to
fully and unambiguously describe when an exception is
raised, rather than to have part of the function
documentation (&quot;or locked&quot;) in the Exception documentation.
More straightforward, etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 23:22

Message:
Logged In: YES 
user_id=31435

The primary point of a non-blocking call is never to block.  
That's the common meaning of &quot;non-blocking&quot; (in or out of 
Python).  After all, a &quot;non-blocking&quot; call that *could* block is 
useless for apps that need not to block.  If you're willing to 
block, use the blocking methods (which most apps do use, 
BTW -- using the non-blocking methods is unusual).

The Full exception isn't raised incorrectly.  &quot;Full&quot; is just 4 
letters strung together, and is only meant to be suggestive 
and convenient -- its full meaning is explained in the docs, 
albeit somewhat cryptically.  I don't think it would be a real 
improvement to, e.g., rename this exception to 
FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo
WeSkippedThat &lt;wink&gt;.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 22:55

Message:
Logged In: YES 
user_id=693152

Sorry - my fault. I didn't read that part of the doco well
enough.

However, is it an issue that important behaviour of a
function is described separately to the function (ie. in the
exception)? Could we put a general note in the put/get
documentation also (Eg. &quot;In the current implementation the
Full exception may sometimes be raised incorrectly.&quot;)

Also, I may have the wrong expectations for how this class
should behave. My assumption was that put(block=False) means
 don't block waiting for a slot in the queue, but it's
implicitly okay to block for other reasons (eg. internal
data sharing, as actually happens with mutex). Was this
incorrect?

I'll see if I can think up an alternative implementation
over the next few days.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 16:50

Message:
Logged In: YES 
user_id=31435

Yes, but unless it's a screamingly obvious non-bug I like to 
wait at least a week to see whether somebody else has a 
clever approach that works as well but without the surprising 
parts.  The docs in this case aren't terribly clear, because 
they really can't explain the whole truth without explaining 
the implementation.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-17 16:30

Message:
Logged In: YES 
user_id=80475

Can this be closed as invalid?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-14 10:59

Message:
Logged In: YES 
user_id=31435

As the docs say (ALL CAPS emphasis added),

&quot;&quot;&quot;
exception Full 

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full OR LOCKED. 
&quot;&quot;&quot;

and similarly for Empty.  The primary point of a non-blocking 
call is never to block, and that's why &quot;or locked&quot; is in the 
docs.  A BoundedSemaphore (or any other &quot;reliable&quot; 
synchronization gimmick) could block, so cannot be used.

In practice, it doesn't matter:  a Queue user who wants to 
use non-blocking calls has to be prepared for Full or Empty 
exceptions, and that's the end of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470
From noreply at sourceforge.net  Sun Jul 11 23:28:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 11 23:28:52 2004
Subject: [ python-Bugs-989066 ] profile.run raises TypeError encountering a
	list
Message-ID: <E1BjlsP-0001v0-00@sc8-sf-web2.sourceforge.net>

Bugs item #989066, was opened at 2004-07-11 23:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989066&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: profile.run raises TypeError encountering a list

Initial Comment:
def g():
    l = []
    l.append('hello')

import profile
profile.run("g()")

This code raises a TypeError in the latest Python 2.4
CVS build. It works in Python 2.3.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989066&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 02:46:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 02:47:05 2004
Subject: [ python-Bugs-788520 ] Queue class has logic error when non-blocking
Message-ID: <E1Bjoy6-0004I2-00@sc8-sf-web4.sourceforge.net>

Bugs item #788520, was opened at 2003-08-14 00:57
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470

Category: Threads
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: GaryD (gazzadee)
>Assigned to: Tim Peters (tim_one)
Summary: Queue class has logic error when non-blocking

Initial Comment:
Looking at the Queue class, I noticed that it might
incorrectly raise a Full/Empty Exception when called
with block=False.

This leads to the following undesirable behaviour:
 * Full exception raised when Queue not full
 * Full exception raised when Queue has no maxsize

Here's my logic (for put(), but get() is similar):

First part of code for put, in Queue.py:
    def put(self, item, block=1):
        if block:
            self.fsema.acquire()
        elif not self.fsema.acquire(0):
            raise Full

Now, for the purposes of raising a Full exception, we
are assuming that fsema is locked if and only if the
Queue is full.

BUT, it seems that fsema is locked every time an item
is added to the Queue, even if that item would not make
the Queue full.

Hence, it might be possible for a Full exception to be
raised, when fsema is locked due to adding an item that
would not  actually make the Queue full. 

An example...

 * Queue with maxsize 10, currently 5 objects in it.
 * Threads T1 and T2, both trying to add an item with
Queue.put(item, block=True).
 * This should obviously be fine, resulting in a Queue
with 7 items.
 [1] Call T1.put(item1, block=True)
 [2] Call T2.put(item2, block=True)
 [3] T1 grabs fsema and mutex, but then the current
thread changes before they are released...
 [4] T2 cannot acquire fsema (since T1 currently has
it), and so raises the Full exception (incorrectly)

Of course, I may have misunderstood something, since I
haven't been able to consistently reproduce the problem
(threading errors are so vexing).

I have no easy solution to this issue (redo the class
using a threading.BoundedSemaphore to count the Queue
length?).

My python version:
Python 2.2.2 (#1, Feb 24 2003, 17:36:09)
[GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-11 20:46

Message:
Logged In: YES 
user_id=31435

I rewrote the Queue put() and get() methods completely for 
2.4.  Since there wasn't "a bug" here, it won't get 
backported.  Full and Empty now mean that the queue was 
indeed full or empty (respectively) at the instant the queue 
was checked, but of course there's no guarantee (and never 
can be) that the queue is still full or empty by the time a 
caller sees those exceptions.

Doc/lib/libqueue.tex; new revision: 1.15
Lib/Queue.py; new revision: 1.21
Misc/NEWS; new revision: 1.1039


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-11 15:47

Message:
Logged In: YES 
user_id=31435

Well, there aren't "several posters" here:  before you jumped 
in, there were exactly three in this report's history:  the 
person who filed the original report (gazzadee), me, and 
Raymond Hettinger (who asked once whether to close the 
report as invalid).  In the 11 months this has been open, 
nobody else has cared enough to comment, let alone produce 
a different implementation.

The reasons the current implementation is reasonable have 
already been explained here at some length, so I'm not going 
over them again.  If you can't tolerate the Full or Empty 
exceptions. don't use non-blocking calls.  It's typical of non-
blocking calls (in and out of Python) that they may return for 
no other reason than that they cannot succeed immediately, 
so honor their contract not to block by returning at once but 
without a useful response.

I still agree the docs could stand improvement.

----------------------------------------------------------------------

Comment By: Randall B. Smith (berryman77)
Date: 2004-07-11 15:13

Message:
Logged In: YES 
user_id=880241

Rather than reiterating here, I agree with this post: 

Date: 2003-08-17 21:55
Sender: gazzadee

I did read the docs for the put method, but not for the Full
Exception, as I assumed it means the queue is full. 
Although the documentation of the Full exception makes the
code technically correct, I found (as several of the posters
here did) that it is unintuitive.  So much so that it
appears to be a bug (hence this bug report).  As I see it,
the documentation simply documents the bug.

"""
The name of the exception is simply briefly suggestive, as are 
the names of most exceptions; 
FULL_OR_NOT_FULL_BUT_LOCKED would be more accurate, 
but too clumsy.
"""

The programmer is not aware of the internal blocking unless
s/he has looked at the source of Queue.  S/he is most likely
expecting put_nowait() to not wait on the queue to free a
slot.  This is to me the intuitive functionality of this
method. According to the comments here,  there is
disagreement on this issue.  So if put_nowait means there is
to be no blocking internally or by the queue, then there
should be 2 exceptions, Full and Locked, so that the user
can distinguish between the two.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-11 02:32

Message:
Logged In: YES 
user_id=31435

berryman77, as the first comment in this report suggested, 
read the documentation:

"""
Full

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full or locked. 
"""

Note the "OR LOCKED" part, a natural counterpoint to 
your "NOT FULL" screaming <wink>.

When code functions as designed and as documented, you 
can argue about the design, or about the quality of the docs, 
but you can't call it "a bug" (well, not if you want to be taken 
seriously).

The name of the exception is simply briefly suggestive, as are 
the names of most exceptions; 
FULL_OR_NOT_FULL_BUT_LOCKED would be more accurate, 
but too clumsy.


----------------------------------------------------------------------

Comment By: Randall B. Smith (berryman77)
Date: 2004-07-11 02:00

Message:
Logged In: YES 
user_id=880241

A Full exception is returned when the queue is NOT FULL. 
This is a bug!  The lack of an immediate solution is not an
excuse to accept incorrect code.



----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-21 23:40

Message:
Logged In: YES 
user_id=693152

Okay, that makes more sense. So, loosely expressed,
non-blocking means there's no way the user can put the Queue
in a blocked state (and especially not deadlocked) - as with
your example of waiting forever on a get call. But,
obviously, internal locks can always be used (in a careful
manner).

I think that's closer to my implicit understand of blocking
that I was trying to express. In the case of put/get, I had
a slightly different expectation about what we were blocking
for (as we have already dicscussed at length :-). Anyway,
I've knocked up some modifications to the documentation,
which you're welcome to use, abuse, or reject out of hand.

I've done this in the form of modifications to the source
code. I assume that's the correct approach, but the 2.3
source code and 2.3 HTML documentation seem to be a bit
different (so I ended up incorporating the relevant HTML
doco into the python source doco, then modifying that).

The patch is the output from:
% diff Queue_v2_3.py Queue_doc_change.py

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-18 01:41

Message:
Logged In: YES 
user_id=31435

It depends on what you mean by &quot;blocking&quot; &lt;wink&gt;.  If the 
thread implementation schedules fairly, it's impossible for 
self.mutex to be held for a &quot;long&quot; time by any thread -- unlike 
esema and fsema, self.mutex is used only for mutual exclusion 
over brief sections of code that don't wait for anything, and 
nothing Queue clients do can cause self.mutex to be held for 
an arbitrarily long time (a spectacularly bad OS 
implementation of thread scheduling could, but that's out of 
the user's-- and out of Python's --hands).

The usual meaning of &quot;blocking&quot; is that clients *can* do 
something to get the system into a state where a call can 
take arbitrarily long to complete (while assuming fair thread 
scheduling).  The obvious example here is that Queue.get() 
can take forever if the Queue is empty and the app stops 
adding anything to the Queue.  There's nothing (sane) the 
app can do that can make Queue.get_nowait() take forever.

BTW, I hope you're looking at the 2.3 code here!  Queue is 
more complicated in 2.3 because these methods have also 
grown optional timeout arguments.  If you're really worried 
about &quot;spurious&quot; Full exceptions, doing a blocking 2.3 
Queue.put() call with a short timeout will try to grab fsema 
several times before giving up.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-18 00:52

Message:
Logged In: YES 
user_id=693152

Whoops - let's try that question in a clearer way:

When you do a non-blocking call to put(), why does it
acquire mutex in a blocking way (ie. &quot;put(block=False)&quot; will
call &quot;mutex.acquire()&quot;, which could block whilst acquiring
mutex). I thought the theory was that you *never* block
anywhere.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-18 00:32

Message:
Logged In: YES 
user_id=31435

We acquire a mutex with a blocking call because the use of a 
blocking call announces that the client is *willing* to block, 
and nothing about the state of a Queue can be changed 
without acquiring a lock first.  So it wouldn't make sense not 
to acquire a lock in that case.

I have no objection at all to improving the docs.  They appear 
to be what they are now because the original version of the 
Queue module didn't have a non-blocking put() method, or a 
Full exception.  I added those 7(!) years later, in 1999.  
Development was done by emailing changes to Guido at that 
time, though, and doc changes were often dropped on the 
floor.

If you can work up a doc patch to supply words that would 
make better sense to you, that would be great.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 23:53

Message:
Logged In: YES 
user_id=693152

First up, you're right that non-blocking calls are unusual.
This isn't exactly a critical matter for me :-)

Okay, I have misunderstood the meaning of non-blocking calls
- so it actually means &quot;ensure we never under any
circumstances block&quot;. Why then do we acquire mutex with a
blocking call?

I am not suggesting there's anything wrong with the naming
of Full (amusing as your suggestion is :-). Of course you
can't completely describe how an exception will be used in
it's name.

It just seems more intuitive for put's documentation to
fully and unambiguously describe when an exception is
raised, rather than to have part of the function
documentation (&quot;or locked&quot;) in the Exception documentation.
More straightforward, etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 23:22

Message:
Logged In: YES 
user_id=31435

The primary point of a non-blocking call is never to block.  
That's the common meaning of &quot;non-blocking&quot; (in or out of 
Python).  After all, a &quot;non-blocking&quot; call that *could* block is 
useless for apps that need not to block.  If you're willing to 
block, use the blocking methods (which most apps do use, 
BTW -- using the non-blocking methods is unusual).

The Full exception isn't raised incorrectly.  &quot;Full&quot; is just 4 
letters strung together, and is only meant to be suggestive 
and convenient -- its full meaning is explained in the docs, 
albeit somewhat cryptically.  I don't think it would be a real 
improvement to, e.g., rename this exception to 
FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo
WeSkippedThat &lt;wink&gt;.

----------------------------------------------------------------------

Comment By: GaryD (gazzadee)
Date: 2003-08-17 22:55

Message:
Logged In: YES 
user_id=693152

Sorry - my fault. I didn't read that part of the doco well
enough.

However, is it an issue that important behaviour of a
function is described separately to the function (ie. in the
exception)? Could we put a general note in the put/get
documentation also (Eg. &quot;In the current implementation the
Full exception may sometimes be raised incorrectly.&quot;)

Also, I may have the wrong expectations for how this class
should behave. My assumption was that put(block=False) means
 don't block waiting for a slot in the queue, but it's
implicitly okay to block for other reasons (eg. internal
data sharing, as actually happens with mutex). Was this
incorrect?

I'll see if I can think up an alternative implementation
over the next few days.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-17 16:50

Message:
Logged In: YES 
user_id=31435

Yes, but unless it's a screamingly obvious non-bug I like to 
wait at least a week to see whether somebody else has a 
clever approach that works as well but without the surprising 
parts.  The docs in this case aren't terribly clear, because 
they really can't explain the whole truth without explaining 
the implementation.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-17 16:30

Message:
Logged In: YES 
user_id=80475

Can this be closed as invalid?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-08-14 10:59

Message:
Logged In: YES 
user_id=31435

As the docs say (ALL CAPS emphasis added),

&quot;&quot;&quot;
exception Full 

Exception raised when non-blocking put() (or put_nowait()) is 
called on a Queue object which is full OR LOCKED. 
&quot;&quot;&quot;

and similarly for Empty.  The primary point of a non-blocking 
call is never to block, and that's why &quot;or locked&quot; is in the 
docs.  A BoundedSemaphore (or any other &quot;reliable&quot; 
synchronization gimmick) could block, so cannot be used.

In practice, it doesn't matter:  a Queue user who wants to 
use non-blocking calls has to be prepared for Full or Empty 
exceptions, and that's the end of it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 05:59:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 05:59:50 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bjryh-0000tP-00@sc8-sf-web4.sourceforge.net>

Bugs item #989185, was opened at 2004-07-11 20:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 06:46:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 06:46:51 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1BjsiC-0006Tz-00@sc8-sf-web3.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 12:59
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 13:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 07:07:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 07:07:28 2004
Subject: [ python-Bugs-989199 ] logging.config: Does not check
	logging.handlers for handlers
Message-ID: <E1Bjt2D-0002aj-00@sc8-sf-web4.sourceforge.net>

Bugs item #989199, was opened at 2004-07-12 15:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Leslie (tleslie)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging.config: Does not check logging.handlers for handlers

Initial Comment:
In fileConfig(), only the logging module is checked for
handler names.

klass = eval(klass, vars(logging))
...
args = eval(args, vars(logging))

This prevents the user from using handlers which are
defined in logging.handlers. 

A quick and dirty fix that seems to work for me is

klass = eval(klass, dict(vars(logging).items() +
vars(logging.handlers).items()))
...
args = eval(args, dict(vars(logging).items() +
vars(logging.handlers).items()))

This is almost certainly not the best way to do it, but
it Works For Me (TM)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 10:30:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 10:30:44 2004
Subject: [ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run
	after test_openpty
Message-ID: <E1BjwCv-0005NI-00@sc8-sf-web1.sourceforge.net>

Bugs item #713169, was opened at 2003-04-01 08:35
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_pty fails on HP-UX and AIX when run after test_openpty

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src &gt; ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File &quot;Lib/test/test_pty.py&quot;, line 58, in ?
    test_basic_pty()
  File &quot;Lib/test/test_pty.py&quot;, line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File &quot;Lib/test/test_pty.py&quot;, line 50, in handle_sig
    raise TestFailed, &quot;isatty hung&quot;
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 09:30

Message:
Logged In: YES 
user_id=200117

This still happens with Python-2.4.0a1 on HP-UX11i


----------------------------------------------------------------------

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 17:22

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 17:31

Message:
Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 17:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 11:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 10:41:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 10:41:08 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1BjwMz-0005Nw-00@sc8-sf-web3.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 09:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 11:22:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 11:22:17 2004
Subject: [ python-Bugs-987166 ] TimedRotatingFileHandler problems
Message-ID: <E1Bjx0n-0005pS-00@sc8-sf-web2.sourceforge.net>

Bugs item #987166, was opened at 2004-07-08 10:20
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987166&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Amaury Forgeot d'Arc (amauryf)
Assigned to: Vinay Sajip (vsajip)
Summary: TimedRotatingFileHandler problems

Initial Comment:
2 problems in the new TimedRotatingFileHandler class:
- "print" statements that where used for debugging were
not removed.
- the code that "find the oldest log file and delete
it" assumes that glob.glob returns files in
alphabetical order. This is not true for all
filesystems (FAT and Novell at least don't sort their
directories), so the file deleted may be a recent one...

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-12 09:22

Message:
Logged In: YES 
user_id=308438

Fixes checked into CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987166&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 11:24:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 11:24:07 2004
Subject: [ python-Bugs-989199 ] logging.config: Does not check
	logging.handlers for handlers
Message-ID: <E1Bjx2W-0005uV-00@sc8-sf-web2.sourceforge.net>

Bugs item #989199, was opened at 2004-07-12 05:07
Message generated for change (Settings changed) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Leslie (tleslie)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging.config: Does not check logging.handlers for handlers

Initial Comment:
In fileConfig(), only the logging module is checked for
handler names.

klass = eval(klass, vars(logging))
...
args = eval(args, vars(logging))

This prevents the user from using handlers which are
defined in logging.handlers. 

A quick and dirty fix that seems to work for me is

klass = eval(klass, dict(vars(logging).items() +
vars(logging.handlers).items()))
...
args = eval(args, dict(vars(logging).items() +
vars(logging.handlers).items()))

This is almost certainly not the best way to do it, but
it Works For Me (TM)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 11:26:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 11:26:41 2004
Subject: [ python-Bugs-979252 ] Trap OSError when calling
	RotatingFileHandler.doRollover
Message-ID: <E1Bjx53-00060g-00@sc8-sf-web2.sourceforge.net>

Bugs item #979252, was opened at 2004-06-24 20:43
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979252&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard T. Hewitt (hewittr)
Assigned to: Vinay Sajip (vsajip)
Summary: Trap OSError when calling RotatingFileHandler.doRollover

Initial Comment:
I use the RotatingFileHandler in most of my scripts.  The 
script will crash if the RotatingFileHandler encounters a 
locked log file.

I would like to see something like:

    def emit(self, record):
        """
        Emit a record.

        Output the record to the file, catering for rollover 
as described
        in __init__().
        """
        if self.maxBytes > 0:                   # are we rolling 
over?
            msg = "%s\n" % self.format(record)
            self.stream.seek(0, 2)  #due to non-posix-
compliant Windows feature
            if self.stream.tell() + len(msg) >= self.maxBytes:
                try:
                    self.doRollover()
                except Exception:
                    logging.FileHandler.emit(self, 'Failed to 
doRollover.')
        logging.FileHandler.emit(self, record)

My version of Python (2.3.2) had the wrong docstring as 
well, referring to a non-existent setRollover.

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-12 09:26

Message:
Logged In: YES 
user_id=308438

Added code to call handleError() when an exception is raised 
while emitting.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-08 10:00

Message:
Logged In: YES 
user_id=308438

Easy things first - the docstring has been corrected in a later 
release.

I believe that when an exception occurs during logging, one 
of two things should happen: if raiseExceptions is 0, then the 
exception should be swallowed silently (typically, for 
production environments). This is because logging-related 
errors should not be treated in the same way as application 
errors (it's a pseudo-philosophical point, and not everyone will 
agree). If raiseExceptions is 1 (development environments), 
the exception should be raised.

I think the solution given by David London (groodude) may be 
fine for specific applications, but not sufficiently general to 
be adopted as is. I will check in changes to CVS which will 
call handleError() when an exception occurs during emit(). It's 
best to derive from RotatingFileHandler and put any specific 
handling you want into an overridden handleError().

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-08 01:39

Message:
Logged In: YES 
user_id=33168

Vinay, any ideas?

----------------------------------------------------------------------

Comment By: David London (groodude)
Date: 2004-06-29 21:34

Message:
Logged In: YES 
user_id=975020

Richard,
I have also had the "joy" of encountering this bug (on a
windows 2000 machine), although I am still baffled at what
could be locking the file.

Our testing did not reveal this bug and now we have some
code in a production environment that is causing me grief,
so I had to come up with a solution quickly and I though
that I might share it with you (and others).

I don't believe that your solution will solve the problem.
In doRollover the stream is closed and then the files are
manipulated. Since this is where the errors will occur
simply calling the emit method again will only cause more
exceptions to be generated. Also, since the stream is never
opened again, you would never get any log messages until you
restarted.  Sorry, after looking a bit more it seems like
you will get tracebacks printed to the standard error (where
ever you have designated that to be).

What I am doing is replacing my version of doRollover with
this version;
    def doRollover(self):
        """
        Do a rollover, as described in __init__().
        """

        self.stream.close()
        openMode = "w"
        if self.backupCount > 0:
            try:
                for i in range(self.backupCount - 1, 0, -1):
                    sfn = "%s.%d" % (self.baseFilename, i)
                    dfn = "%s.%d" % (self.baseFilename, i + 1)
                    if os.path.exists(sfn):
                        #print "%s -> %s" % (sfn, dfn)
                        if os.path.exists(dfn):
                            os.remove(dfn)
                        os.rename(sfn, dfn)
                dfn = self.baseFilename + ".1"
                if os.path.exists(dfn):
                    os.remove(dfn)
                os.rename(self.baseFilename, dfn)
                #print "%s -> %s" % (self.baseFilename, dfn)
            except:
                ## There was some problem with the file
manipulationg above.
                ## If someone has some time, maybe they can
figure out what errors
                ## can occur and the best way to deal with
all of them.
                ## For my purposes, I'm just going to try
and re-open
                ## the original file.
                openMode = "a"
        try:
            self.stream = open(self.baseFilename, openMode)
        except:
            ## There was some problem opening the log file.
            ## Again, someone with more time can look into
all of the possible
            ## errors and figure out how best to handle them.
            ## I'm just going to try and open a 'problem'
log file.
            ## The idea is that this file will exist long
enough for the problems
            ## above to go away and the next time that we
attempt to rollover
            ## it will work as we expect.
            gotError = True
            count = 1
            while gotError:
                try:
                    problemFilename = self.baseFilename +
".pblm." + str(count)
                    self.stream = open(problemFilename,
openMode)
                    gotError = False
                except:
                    count += 1

If my logic works out, this should always open a file for
logging so the logging should never crash and no log
messages will be lost. 
Hopefully you will find this helpful.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979252&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 11:28:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 11:28:12 2004
Subject: [ python-Bugs-958180 ] logging functionality non-intuitive,
	levels confusing
Message-ID: <E1Bjx6W-00064Z-00@sc8-sf-web2.sourceforge.net>

Bugs item #958180, was opened at 2004-05-21 18:56
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=958180&group_id=5470

Category: Python Library
Group: Python 2.2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Vinay Sajip (vsajip)
Summary: logging functionality non-intuitive, levels confusing

Initial Comment:
If one tries to define additional logging levels without 
overriding the logger class, one runs into trouble with 
the log level naming conventions.  In particular, I 
observe the following strange behavior:

>>> import logging
>>> logging.basicConfig()
>>> logging.root.level
30
>>> logging.root.log( logging.INFO, 'test1' )
>>> logging.root.log( 20, 'test1' )
>>> logging.root.log( 'info', 'test1' )
Level info:root:test1
>>> logging.root.log( 'INFO', 'test1' )
20:root:test1
>>> logging.root.log( logging.WARNING, 'warning' )
WARNING:root:warning
>>> logging.root.log( 30, 'warning' )
WARNING:root:warning
>>> logging.root.log( 'warning', 'warning' )
Level warning:root:warning
>>> logging.root.log( 'WARNING', 'warning' )
30:root:warning

Note that if a string parameter is passed as the lvl 
parameter of the log() method, the message is logged 
regardless of the current logging level, and the output is 
furthermore inconsistent.

Additionally, when the user attempts to add a logging 
level, the user cannot reference that log level by name 
using any exposed (documented) interfaces.

For example:
>>> import logging
>>> logging.basicConfig()
>>> logging.root.level = logging.DEBUG # 10
>>> logging.addLevelName( 15, 'STATUS' )
>>> logging.root.log( 15, 'a status message' )
STATUS:root:a status message
>>> logging.root.log( logging._levelNames['STATUS'], 'a 
status message' )
STATUS:root:a status message

The only interface, as far as I can tell, to access the 
log level is to explicitly query the internal data 
structures.

Changes I propose:
(1) The log() methodshould either throw a TypeError 
when a string is passed for the log level or (better) it 
should accept string values and translate them 
transparently to the integer log levels that it currently 
expects.

(2) The logging module should include functionality to 
allow the user to query a logging level from a name.

def getLevelNumber( levelName ):
    return _levelNames[ levelName ]
    # error checking would be appropriate


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-12 09:28

Message:
Logged In: YES 
user_id=308438

Error checking added to log() - now in CVS.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-05-24 14:21

Message:
Logged In: YES 
user_id=308438

Point 1 - agreed.
Point 2 - getLevelName() already handles this, as it adds 
both name->value and value->name mappings to 
_levelNames. The point about type checks is valid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=958180&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 11:30:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 11:30:58 2004
Subject: [ python-Bugs-989199 ] logging.config: Does not check
	logging.handlers for handlers
Message-ID: <E1Bjx9B-0006A8-00@sc8-sf-web2.sourceforge.net>

Bugs item #989199, was opened at 2004-07-12 05:07
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Tim Leslie (tleslie)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.config: Does not check logging.handlers for handlers

Initial Comment:
In fileConfig(), only the logging module is checked for
handler names.

klass = eval(klass, vars(logging))
...
args = eval(args, vars(logging))

This prevents the user from using handlers which are
defined in logging.handlers. 

A quick and dirty fix that seems to work for me is

klass = eval(klass, dict(vars(logging).items() +
vars(logging.handlers).items()))
...
args = eval(args, dict(vars(logging).items() +
vars(logging.handlers).items()))

This is almost certainly not the best way to do it, but
it Works For Me (TM)

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-12 09:30

Message:
Logged In: YES 
user_id=308438

You can put a qualified name in the config file - 
e.g. "handlers.HTTPHandler".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 11:45:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 11:45:34 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1BjxNJ-00081z-00@sc8-sf-web3.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 13:00:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 13:00:21 2004
Subject: [ python-Bugs-989333 ] Empty curses module is loaded in win32
Message-ID: <E1BjyXh-0000v5-00@sc8-sf-web2.sourceforge.net>

Bugs item #989333, was opened at 2004-07-12 14:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Empty curses module is loaded in win32

Initial Comment:
When doing "import curses" an empty curses module is
loaded.
I think that since curses is not supported in win32
that an ImportError should be raised (like in 2.3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989333&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 13:07:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 13:07:08 2004
Subject: [ python-Bugs-989337 ] test_descr fails on win2k
Message-ID: <E1BjyeH-0002kl-00@sc8-sf-web3.sourceforge.net>

Bugs item #989337, was opened at 2004-07-12 14:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_descr fails on win2k

Initial Comment:
>>> from test import test_descr
>>> test_descr.verbose = 1
>>> test_descr.test_main()
Testing weakref segfault...
Testing SF bug 551412 ...
Testing SF bug 570483...
Testing list operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing dict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking a[b]=c
Testing dict constructor ...
Testing dir() ...
Testing int operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing long operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing float operations...
checking a >= b
checking a - b
checking a > b
checking a ** b
checking a < b
checking a != b
checking a + b
checking a <= b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking int(a)
checking - a
checking float(a)
checking + a
checking long(a)
checking abs(a)
Testing complex operations...
checking a - b
checking a ** b
checking a != b
checking a + b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking - a
checking + a
checking abs(a)
Testing spamlist operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing spamdict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking repr(a)
checking a[b]=c
Testing Python subclass of dict...
pydict stress test ...
Testing Python subclass of list...
Testing __metaclass__...
Testing Python subclass of module...
Testing multiple inheritance...
Testing error messages for MRO disagreement...
Testing multiple inheritance special cases...
Testing ex5 from C3 switch discussion...
Testing MRO monotonicity...
Testing consistentcy with EPG...
Testing object class...
Testing __slots__...
Testing __dict__ and __weakref__ in __slots__...
Testing class attribute propagation...
Testing errors...
Testing class methods...
Testing C-based class methods...
Testing static methods...
Testing C-based static methods...
Testing classic classes...
Testing computed attributes...
Testing __new__ slot override...
Testing mro() and overriding it...
Testing operator overloading...
Testing methods...
Testing special operators...

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in -toplevel-
    test_descr.test_main()
  File "C:\apps\Python24\lib\test\test_descr.py", line
4024, in test_main
    specials()
  File "C:\apps\Python24\lib\test\test_descr.py", line
1875, in specials
    print Letter('w')
PicklingError: Can't pickle <class
'test.test_descr.Letter'>: attribute lookup
test.test_descr.Letter failed
>>> 

This is Python 2.4a1 on win2k pro

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 13:11:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 13:11:22 2004
Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k
Message-ID: <E1BjyiN-0006tE-00@sc8-sf-web4.sourceforge.net>

Bugs item #989338, was opened at 2004-07-12 14:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_unicode_file fails on win2k

Initial Comment:
>>> test_support.verbose = 1
>>> test_unicode_file.test_main()
test_directories
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_single_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR

======================================================================
ERROR: test_directories
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
178, in test_directories
    self._do_directory(TESTFN_ENCODED+ext,
TESTFN_ENCODED+ext, True)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
112, in _do_directory
    os.mkdir(make_name)
OSError: [Errno 22] Invalid argument: '@test-??.dir'

======================================================================
ERROR: test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
170, in test_equivalent_files
    self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
154, in _test_equivalent
    f = file(filename1, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

======================================================================
ERROR: test_single_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
164, in test_single_files
    self._test_single(TESTFN_ENCODED)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
136, in _test_single
    f = file(filename, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

----------------------------------------------------------------------
Ran 3 tests in 0.061s

FAILED (errors=3)

Traceback (most recent call last):
  File "<pyshell#21>", line 1, in -toplevel-
    test_unicode_file.test_main()
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
191, in test_main
    run_suite(suite)
  File "C:\apps\Python24\lib\test\test_support.py",
line 274, in run_suite
    raise TestFailed(msg)
TestFailed: errors occurred; run in verbose mode for
details
>>> 

This is Python2.4a1 on win2k pro

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 13:12:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 13:12:05 2004
Subject: [ python-Bugs-989337 ] test_descr fails on win2k
Message-ID: <E1Bjyj4-0006uh-00@sc8-sf-web4.sourceforge.net>

Bugs item #989337, was opened at 2004-07-12 14:07
Message generated for change (Settings changed) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470

>Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_descr fails on win2k

Initial Comment:
>>> from test import test_descr
>>> test_descr.verbose = 1
>>> test_descr.test_main()
Testing weakref segfault...
Testing SF bug 551412 ...
Testing SF bug 570483...
Testing list operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing dict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking a[b]=c
Testing dict constructor ...
Testing dir() ...
Testing int operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing long operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing float operations...
checking a >= b
checking a - b
checking a > b
checking a ** b
checking a < b
checking a != b
checking a + b
checking a <= b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking int(a)
checking - a
checking float(a)
checking + a
checking long(a)
checking abs(a)
Testing complex operations...
checking a - b
checking a ** b
checking a != b
checking a + b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking - a
checking + a
checking abs(a)
Testing spamlist operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing spamdict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking repr(a)
checking a[b]=c
Testing Python subclass of dict...
pydict stress test ...
Testing Python subclass of list...
Testing __metaclass__...
Testing Python subclass of module...
Testing multiple inheritance...
Testing error messages for MRO disagreement...
Testing multiple inheritance special cases...
Testing ex5 from C3 switch discussion...
Testing MRO monotonicity...
Testing consistentcy with EPG...
Testing object class...
Testing __slots__...
Testing __dict__ and __weakref__ in __slots__...
Testing class attribute propagation...
Testing errors...
Testing class methods...
Testing C-based class methods...
Testing static methods...
Testing C-based static methods...
Testing classic classes...
Testing computed attributes...
Testing __new__ slot override...
Testing mro() and overriding it...
Testing operator overloading...
Testing methods...
Testing special operators...

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in -toplevel-
    test_descr.test_main()
  File "C:\apps\Python24\lib\test\test_descr.py", line
4024, in test_main
    specials()
  File "C:\apps\Python24\lib\test\test_descr.py", line
1875, in specials
    print Letter('w')
PicklingError: Can't pickle <class
'test.test_descr.Letter'>: attribute lookup
test.test_descr.Letter failed
>>> 

This is Python 2.4a1 on win2k pro

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 14:23:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 14:23:34 2004
Subject: [ python-Bugs-988300 ] Compiler warnings for
	Modules/readline.c:flex_complete()
Message-ID: <E1BjzqE-0005sz-00@sc8-sf-web1.sourceforge.net>

Bugs item #988300, was opened at 2004-07-10 00:53
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Michael Hudson (mwh)
Summary: Compiler warnings for Modules/readline.c:flex_complete()

Initial Comment:
When I compile on my OS X 10.3.4 with Fink's readline 4.3-25 I get 
the following two warnings:

/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: implicit declaration of function `completion_matches'
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: return makes pointer from integer without a cast

Now, although I have a version greater than 4.2, this only makes 
sense if HAVE_RL_COMPLETION_MATCHES is undefined and thus 
the completion_matches() macro is not being defined (although I 
checked and the headers have a prototype for 
rl_completion_matches() and my readline seems to compile and 
work well enough).

Would a #else statement that defines completion_matches() fit in 
there?  Problem would be the return type for flex_complete() 
might need to be covered as well unless a clever macro can be 
created that returns a char **.

Initially assigned to Michael since he seems to always deal with the 
readline stuff.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-12 13:23

Message:
Logged In: YES 
user_id=6656

> Initially assigned to Michael since he seems to always 
> deal with the readline stuff.

Oh, er, "good".

I'm a little confused.  Is this a new thing?  As in, introduced by my 
changes just before 2.4a1?  *Why* is 
HAVE_RL_COMPLETION_MATCHES undefined?  What do config.log 
and pyconfig.h have to say on the matter?

> Would a #else statement that defines completion_matches()
> fit in there?

Not unless we can work out why it's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 14:30:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 14:30:46 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1BjzxC-0001SB-00@sc8-sf-web4.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 21:19
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (shredwheat)
Assigned to: Michael Hudson (mwh)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-12 13:30

Message:
Logged In: YES 
user_id=6656

Um.  Any particular reason for assigning to me?  I could probably 
review and apply any patch that appears, but I'm unlikely to get to 
creating one myself...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 14:47:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 14:47:25 2004
Subject: [ python-Bugs-989066 ] profile.run raises TypeError encountering a
	list
Message-ID: <E1Bk0DC-0002Bq-00@sc8-sf-web4.sourceforge.net>

Bugs item #989066, was opened at 2004-07-11 22:28
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989066&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
>Assigned to: Nick Bastin (mondragon)
Summary: profile.run raises TypeError encountering a list

Initial Comment:
def g():
    l = []
    l.append('hello')

import profile
profile.run("g()")

This code raises a TypeError in the latest Python 2.4
CVS build. It works in Python 2.3.4.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-12 13:47

Message:
Logged In: YES 
user_id=6656

Mondragon, I'm reasonably sure this is your fault :-) (revision 
1.55 if I'm not mistaken).

Was this change the application of a patch on SF?  If so, you 
should have mentioned the patch # in the checkin comment.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989066&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 15:06:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 15:06:55 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bk0W3-000310-00@sc8-sf-web4.sourceforge.net>

Bugs item #989185, was opened at 2004-07-11 20:59
Message generated for change (Comment added) made by donut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: Matthew Mueller (donut)
Date: 2004-07-12 06:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 02:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-11 21:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 15:17:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 15:17:51 2004
Subject: [ python-Bugs-988613 ] compiler.transformer and tuple unpacking
Message-ID: <E1Bk0gl-0003S8-00@sc8-sf-web4.sourceforge.net>

Bugs item #988613, was opened at 2004-07-10 21:03
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988613&group_id=5470

Category: Parser/Compiler
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Felix Wiemann (felixwiemann)
>Assigned to: Michael Hudson (mwh)
Summary: compiler.transformer and tuple unpacking

Initial Comment:
compiler.transformer.parse chokes on tuple unpacking
when parentheses are present.

To reproduce, try:

import compiler.transformer
compiler.transformer.parse('(a, b) = 1, 2')

... in Python 2.3 and Python 2.4.  It works in Python
2.3. In Python 2.4, it causes a SyntaxError "bad
assignment".

It works in both Python versions when omitting the
parentheses, i.e. using 'a, b = 1, 2' instead.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-12 14:17

Message:
Logged In: YES 
user_id=6656

Fixed by applying the mentioned patch.

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2004-07-11 00:48

Message:
Logged In: YES 
user_id=22785

I've uploaded patch #988698 to fix this

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988613&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 15:23:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 15:23:44 2004
Subject: [ python-Bugs-989199 ] logging.config: Does not check
	logging.handlers for handlers
Message-ID: <E1Bk0mN-0008Os-00@sc8-sf-web1.sourceforge.net>

Bugs item #989199, was opened at 2004-07-12 15:07
Message generated for change (Comment added) made by tleslie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tim Leslie (tleslie)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.config: Does not check logging.handlers for handlers

Initial Comment:
In fileConfig(), only the logging module is checked for
handler names.

klass = eval(klass, vars(logging))
...
args = eval(args, vars(logging))

This prevents the user from using handlers which are
defined in logging.handlers. 

A quick and dirty fix that seems to work for me is

klass = eval(klass, dict(vars(logging).items() +
vars(logging.handlers).items()))
...
args = eval(args, dict(vars(logging).items() +
vars(logging.handlers).items()))

This is almost certainly not the best way to do it, but
it Works For Me (TM)

----------------------------------------------------------------------

>Comment By: Tim Leslie (tleslie)
Date: 2004-07-12 23:23

Message:
Logged In: YES 
user_id=1081664

Ah ok, that works much better. I was mislead by the examples
given in the docs:

http://www.python.org/doc/lib/logging-config-fileformat.html

[handler_hand06]
class=NTEventLogHandler
level=CRITICAL
formatter=form06
args=('Python Application', '', 'Application')

and similarly for hand07, 08 and 09, the fully qualified
name is not used. Presumably the docs are in error here. If
this is the case, should I file a new bug, or can it be
handled from here?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-12 19:30

Message:
Logged In: YES 
user_id=308438

You can put a qualified name in the config file - 
e.g. "handlers.HTTPHandler".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 15:31:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 15:31:46 2004
Subject: [ python-Bugs-989066 ] profile.run raises TypeError encountering a
	list
Message-ID: <E1Bk0uB-00040m-00@sc8-sf-web4.sourceforge.net>

Bugs item #989066, was opened at 2004-07-11 17:28
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989066&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nick Bastin (mondragon)
Summary: profile.run raises TypeError encountering a list

Initial Comment:
def g():
    l = []
    l.append('hello')

import profile
profile.run("g()")

This code raises a TypeError in the latest Python 2.4
CVS build. It works in Python 2.3.4.

----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-07-12 09:31

Message:
Logged In: YES 
user_id=430343

This may actually have been introduced with a recent change to ceval 
that changed the argument type on C calls (also my fault.. :-)).  I'll take 
a look at it - also, we should probably try to cook up some sort of test 
for this problem.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 08:47

Message:
Logged In: YES 
user_id=6656

Mondragon, I'm reasonably sure this is your fault :-) (revision 
1.55 if I'm not mistaken).

Was this change the application of a patch on SF?  If so, you 
should have mentioned the patch # in the checkin comment.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989066&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 15:35:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 15:36:05 2004
Subject: [ python-Bugs-968245 ] Python Logging filename & file number 
Message-ID: <E1Bk0yN-0004B2-00@sc8-sf-web4.sourceforge.net>

Bugs item #968245, was opened at 2004-06-07 10:49
Message generated for change (Comment added) made by superleo303
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan (superleo303)
Assigned to: Vinay Sajip (vsajip)
Summary: Python Logging filename & file number 

Initial Comment:
I use Freebsd and redhat 9.0 linus at work.

Using Python Logging filename & file number on freebsd
works fine.
When i print a log statement, and have my config
formatter section set like:
[formatter_default]
format=%(asctime)s <%(levelname)s>
<%(module)s:%(lineno)s> %(message)s
datefmt=

On bsd my logs look like:
<INFO> <propmancmd:95> stateOnly is: DE
<INFO> <propmancmd:105>  MEssages .........
<INFO> <propmancmd:107> collecting datasource: 1011
<INFO> <propman:98>   Collectors overwrite existing
pickle files: 0
<INFO> <propman:99>           Collectors run in
multiple threads: 4
<DEBUG> <propman:528> sql is:
...

See, the filename and file number get displayed with
each logging call,

Now, The same exact code run on the same exact version
of python on a linux machine yiedls the lines:

<INFO> <__init__:988> stateOnly is: DE
<INFO> <__init__:988>  MEssages
<INFO> <__init__:988> collecting datasource: 1011
<INFO> <__init__:988>   Collectors overwrite existing
pickle files: 0
<INFO> <__init__:988>           Collectors run in
multiple threads: 4
<DEBUG> <__init__:988> sql is: 
...

So i opened up ./python2.3/logging/__init__.py  line
988 and it seems to be where the problem is.

Can someone take a look at this asap?   I have to run
all my code on linux machines, so now i cant see which
file and which line is making the logging.

To reproduce, get a freebsd and linux machine,
then run a simple script that uses logging config files
and use the above example as your formatter in the
logging confrig file,

BSD should show the filenames and numbers, linux should
show __init__ 988 instead.


----------------------------------------------------------------------

>Comment By: Ryan (superleo303)
Date: 2004-07-12 08:35

Message:
Logged In: YES 
user_id=1058618

Sorry, no , i just have been very busy and havent had time
to reproduce the error, 
i promise by tomorrow ill have a small set of scripts  to
reproduce the error.
All the linux boxes, which is 4 of them, are red hat 9.0, so
maybe its only a problem with red hat?
Ill be posting the scripts tomorrow.
Thanks for checking into this 

-Ryan

ps - i wasnt able to send you an email, it said:

<vsajip@users.sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said:
    550 Administrative prohibition

<vsajip@sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said: 550
    Administrative prohibition


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-05 07:06

Message:
Logged In: YES 
user_id=308438

I'm not able to reproduce these problems under Linux - I only 
have access to Mandrake 10.0 (a Red Hat variant).

Can you upload a script or set of scripts which demonstrates 
the problem?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-06-10 12:18

Message:
Logged In: YES 
user_id=1058618

vsajip, i tested on both machines, both machines returned
the same results:

STACKWALKER RESULTS RUN ON LINUX RED HAT 9.0

[rsmith@marge]:~/ned$ cd bin/testing/stackwalk/
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw1.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw2.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw3.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw4.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python getcaller.py
/home/rsmith/ned/bin/testing/stackwalk/sw1.py(4)
/home/rsmith/ned/bin/testing/stackwalk/sw2.py(5)
/home/rsmith/ned/bin/testing/stackwalk/sw3.py(6)
/home/rsmith/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[rsmith@marge]:~/ned/bin/testing/stackwalk$


-------------------------------------------------------------------------

STACKWALKER RESULTS RUN ON FREEBSD 5.2.1-RELEASE-p8

[ryan@dev2]:~/ned$ cd bin/testing/stackwalk/
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw1.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw2.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw3.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw4.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python getcaller.py
/usr/home/ryan/ned/bin/testing/stackwalk/sw1.py(4)
/usr/home/ryan/ned/bin/testing/stackwalk/sw2.py(5)
/usr/home/ryan/ned/bin/testing/stackwalk/sw3.py(6)
/usr/home/ryan/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[ryan@dev2]:~/ned/bin/testing/stackwalk$

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 04:26

Message:
Logged In: YES 
user_id=308438

The problem appears to be related to some underlying 
problem with sys._getframe(). Can you please download the 
attached stackwalk.tar.gz and run it on both FreeBSD and 
Linux? Please post your findings here, thanks. Note that the 
stackwalk stuff contains no calls to the logging package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 15:36:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 15:36:18 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1Bk0yZ-0007Gr-00@sc8-sf-web2.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 15:19
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (shredwheat)
Assigned to: Michael Hudson (mwh)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 08:36

Message:
Logged In: YES 
user_id=80475

I thought you would have an interest and be in a good
position to know whether and how this should be fixed.  Feel
free to unassign.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 07:30

Message:
Logged In: YES 
user_id=6656

Um.  Any particular reason for assigning to me?  I could probably 
review and apply any patch that appears, but I'm unlikely to get to 
creating one myself...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 15:45:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 15:45:25 2004
Subject: [ python-Bugs-989066 ] profile.run raises TypeError encountering a
	list
Message-ID: <E1Bk17O-0007iT-00@sc8-sf-web2.sourceforge.net>

Bugs item #989066, was opened at 2004-07-11 17:28
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989066&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nick Bastin (mondragon)
Summary: profile.run raises TypeError encountering a list

Initial Comment:
def g():
    l = []
    l.append('hello')

import profile
profile.run("g()")

This code raises a TypeError in the latest Python 2.4
CVS build. It works in Python 2.3.4.

----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-07-12 09:45

Message:
Logged In: YES 
user_id=430343

Broken by recent change to ceval.  Fixed in Lib/profile.py 1.57

----------------------------------------------------------------------

Comment By: Nick Bastin (mondragon)
Date: 2004-07-12 09:31

Message:
Logged In: YES 
user_id=430343

This may actually have been introduced with a recent change to ceval 
that changed the argument type on C calls (also my fault.. :-)).  I'll take 
a look at it - also, we should probably try to cook up some sort of test 
for this problem.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 08:47

Message:
Logged In: YES 
user_id=6656

Mondragon, I'm reasonably sure this is your fault :-) (revision 
1.55 if I'm not mistaken).

Was this change the application of a patch on SF?  If so, you 
should have mentioned the patch # in the checkin comment.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989066&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 16:00:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 16:00:55 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bk1MQ-0001Xs-00@sc8-sf-web3.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 16:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 15:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 16:28:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 16:29:02 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bk1nV-0006VQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #989185, was opened at 2004-07-11 20:59
Message generated for change (Comment added) made by donut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: Matthew Mueller (donut)
Date: 2004-07-12 07:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 07:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 06:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 02:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-11 21:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 17:23:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 17:23:22 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bk2eE-0003ZO-00@sc8-sf-web2.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 17:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 16:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 16:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 15:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 17:51:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 17:51:34 2004
Subject: [ python-Bugs-989199 ] logging.config: Does not check
	logging.handlers for handlers
Message-ID: <E1Bk35K-0004mM-00@sc8-sf-web2.sourceforge.net>

Bugs item #989199, was opened at 2004-07-12 05:07
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470

Category: None
Group: None
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Leslie (tleslie)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.config: Does not check logging.handlers for handlers

Initial Comment:
In fileConfig(), only the logging module is checked for
handler names.

klass = eval(klass, vars(logging))
...
args = eval(args, vars(logging))

This prevents the user from using handlers which are
defined in logging.handlers. 

A quick and dirty fix that seems to work for me is

klass = eval(klass, dict(vars(logging).items() +
vars(logging.handlers).items()))
...
args = eval(args, dict(vars(logging).items() +
vars(logging.handlers).items()))

This is almost certainly not the best way to do it, but
it Works For Me (TM)

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-12 15:51

Message:
Logged In: YES 
user_id=308438

Yes, it was a bug in the docs. Now fixed in CVS. Thanks.

----------------------------------------------------------------------

Comment By: Tim Leslie (tleslie)
Date: 2004-07-12 13:23

Message:
Logged In: YES 
user_id=1081664

Ah ok, that works much better. I was mislead by the examples
given in the docs:

http://www.python.org/doc/lib/logging-config-fileformat.html

[handler_hand06]
class=NTEventLogHandler
level=CRITICAL
formatter=form06
args=('Python Application', '', 'Application')

and similarly for hand07, 08 and 09, the fully qualified
name is not used. Presumably the docs are in error here. If
this is the case, should I file a new bug, or can it be
handled from here?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-12 09:30

Message:
Logged In: YES 
user_id=308438

You can put a qualified name in the config file - 
e.g. "handlers.HTTPHandler".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989199&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 17:53:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 17:53:57 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bk37n-0006kQ-00@sc8-sf-web3.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 12:59
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-07-13 00:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-13 00:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 23:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 23:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 22:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 18:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 13:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 16:29:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 18:02:25 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1Bk1oK-0001Ok-00@sc8-sf-web2.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 20:19
Message generated for change (Comment added) made by shredwheat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (shredwheat)
Assigned to: Michael Hudson (mwh)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

>Comment By: Pete Shinners (shredwheat)
Date: 2004-07-12 14:29

Message:
Logged In: YES 
user_id=1076442

I will attempt a patch, this does not look difficult. I am
currently trying to get straight CVS Python to run the test
suite, but having difficulty. I will have a patch ready or
more comments otherwise later this week.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 13:36

Message:
Logged In: YES 
user_id=80475

I thought you would have an interest and be in a good
position to know whether and how this should be fixed.  Feel
free to unassign.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 12:30

Message:
Logged In: YES 
user_id=6656

Um.  Any particular reason for assigning to me?  I could probably 
review and apply any patch that appears, but I'm unlikely to get to 
creating one myself...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 18:03:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 18:03:15 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bk3Gn-0007e0-00@sc8-sf-web1.sourceforge.net>

Bugs item #989185, was opened at 2004-07-11 20:59
Message generated for change (Comment added) made by donut
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: Matthew Mueller (donut)
Date: 2004-07-12 09:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 08:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 08:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 07:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 07:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 06:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 02:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-11 21:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 18:35:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 18:35:09 2004
Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k
Message-ID: <E1Bk3lh-0006sB-00@sc8-sf-web2.sourceforge.net>

Bugs item #989338, was opened at 2004-07-12 07:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_unicode_file fails on win2k

Initial Comment:
>>> test_support.verbose = 1
>>> test_unicode_file.test_main()
test_directories
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_single_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR

======================================================================
ERROR: test_directories
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
178, in test_directories
    self._do_directory(TESTFN_ENCODED+ext,
TESTFN_ENCODED+ext, True)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
112, in _do_directory
    os.mkdir(make_name)
OSError: [Errno 22] Invalid argument: '@test-??.dir'

======================================================================
ERROR: test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
170, in test_equivalent_files
    self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
154, in _test_equivalent
    f = file(filename1, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

======================================================================
ERROR: test_single_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
164, in test_single_files
    self._test_single(TESTFN_ENCODED)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
136, in _test_single
    f = file(filename, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

----------------------------------------------------------------------
Ran 3 tests in 0.061s

FAILED (errors=3)

Traceback (most recent call last):
  File "<pyshell#21>", line 1, in -toplevel-
    test_unicode_file.test_main()
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
191, in test_main
    run_suite(suite)
  File "C:\apps\Python24\lib\test\test_support.py",
line 274, in run_suite
    raise TestFailed(msg)
TestFailed: errors occurred; run in verbose mode for
details
>>> 

This is Python2.4a1 on win2k pro

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-12 12:35

Message:
Logged In: YES 
user_id=31435

Peculiar -- it works fine on WinXP Pro, which ought to work 
the same as Win2K here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 19:59:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 20:00:10 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1Bk55p-0004Py-00@sc8-sf-web1.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 15:19
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (shredwheat)
Assigned to: Michael Hudson (mwh)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 12:59

Message:
Logged In: YES 
user_id=80475

Thanks, that will be nice.

Do make a special effort to make sure this has zero
performance impact on the common case.  No sense in mucking
up the works to satisfy a corner case that rarely impacts
real apps.

----------------------------------------------------------------------

Comment By: Pete Shinners (shredwheat)
Date: 2004-07-12 09:29

Message:
Logged In: YES 
user_id=1076442

I will attempt a patch, this does not look difficult. I am
currently trying to get straight CVS Python to run the test
suite, but having difficulty. I will have a patch ready or
more comments otherwise later this week.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 08:36

Message:
Logged In: YES 
user_id=80475

I thought you would have an interest and be in a good
position to know whether and how this should be fixed.  Feel
free to unassign.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 07:30

Message:
Logged In: YES 
user_id=6656

Um.  Any particular reason for assigning to me?  I could probably 
review and apply any patch that appears, but I'm unlikely to get to 
creating one myself...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 20:36:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 20:36:42 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1Bk5fG-0007zo-00@sc8-sf-web4.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 01:41
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
>Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 11:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 20:46:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 20:46:55 2004
Subject: [ python-Bugs-988300 ] Compiler warnings for
	Modules/readline.c:flex_complete()
Message-ID: <E1Bk5pD-0005eh-00@sc8-sf-web3.sourceforge.net>

Bugs item #988300, was opened at 2004-07-09 16:53
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Michael Hudson (mwh)
Summary: Compiler warnings for Modules/readline.c:flex_complete()

Initial Comment:
When I compile on my OS X 10.3.4 with Fink's readline 4.3-25 I get 
the following two warnings:

/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: implicit declaration of function `completion_matches'
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: return makes pointer from integer without a cast

Now, although I have a version greater than 4.2, this only makes 
sense if HAVE_RL_COMPLETION_MATCHES is undefined and thus 
the completion_matches() macro is not being defined (although I 
checked and the headers have a prototype for 
rl_completion_matches() and my readline seems to compile and 
work well enough).

Would a #else statement that defines completion_matches() fit in 
there?  Problem would be the return type for flex_complete() 
might need to be covered as well unless a clever macro can be 
created that returns a char **.

Initially assigned to Michael since he seems to always deal with the 
readline stuff.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 11:46

Message:
Logged In: YES 
user_id=357491

> Oh, er, "good".

If I was wrong to assign it to you feel free to unassign it.

I don't know when it was introduced; it might be old.  I just decided to go 
through my make output and look for any warnings before a1 when out 
the door.  I tend to compile with ``--without-toolbox-glue`` and that 
leads to a ton of output from modules wanting Carbon stuff and throwing 
a fit that they can't link so it just didn't catch my eye.

As for RL_COMPLETION_MATCHES, pyconfig.h has it commented out and 
config.log has test code fail at compilation because it can't find code for 
-lreadline::

configure:17625: checking for rl_completion_matches in -lreadline
configure:17656: gcc -o conftest -g -O2   conftest.c -lreadline -ltermcap 
-ldl  >        &5
ld: can't locate file for: -lreadline

so I end up with::

``ac_cv_lib_readline_rl_completion_matches=no``.

in config.log .

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 05:23

Message:
Logged In: YES 
user_id=6656

> Initially assigned to Michael since he seems to always 
> deal with the readline stuff.

Oh, er, "good".

I'm a little confused.  Is this a new thing?  As in, introduced by my 
changes just before 2.4a1?  *Why* is 
HAVE_RL_COMPLETION_MATCHES undefined?  What do config.log 
and pyconfig.h have to say on the matter?

> Would a #else statement that defines completion_matches()
> fit in there?

Not unless we can work out why it's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 20:55:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 20:55:16 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1Bk5xC-0004Ib-00@sc8-sf-web2.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 04:41
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-12 14:55

Message:
Logged In: YES 
user_id=31435

Brett, are you sure we understand this one?  It's the same 
test failing in the same way as I reported on Python-Dev, 
*but* Richard is seeing test_strptime fail in isolation (look at 
his attachment).  The failure I saw was due to interactions 
with test___all__ and test_site too -- test_strptime did not 
fail in isolation for me, but is failing in isolation for Richard.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 14:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 20:56:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 20:56:42 2004
Subject: [ python-Bugs-988300 ] Compiler warnings for
	Modules/readline.c:flex_complete()
Message-ID: <E1Bk5yg-0004MD-00@sc8-sf-web2.sourceforge.net>

Bugs item #988300, was opened at 2004-07-10 00:53
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Michael Hudson (mwh)
Summary: Compiler warnings for Modules/readline.c:flex_complete()

Initial Comment:
When I compile on my OS X 10.3.4 with Fink's readline 4.3-25 I get 
the following two warnings:

/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: implicit declaration of function `completion_matches'
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: return makes pointer from integer without a cast

Now, although I have a version greater than 4.2, this only makes 
sense if HAVE_RL_COMPLETION_MATCHES is undefined and thus 
the completion_matches() macro is not being defined (although I 
checked and the headers have a prototype for 
rl_completion_matches() and my readline seems to compile and 
work well enough).

Would a #else statement that defines completion_matches() fit in 
there?  Problem would be the return type for flex_complete() 
might need to be covered as well unless a clever macro can be 
created that returns a char **.

Initially assigned to Michael since he seems to always deal with the 
readline stuff.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-12 19:56

Message:
Logged In: YES 
user_id=6656

So I'm guessing that the answer to this is to teach the
configure test to look in /sw/lib, then.  Not sure how to do
that...

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 19:46

Message:
Logged In: YES 
user_id=357491

> Oh, er, "good".

If I was wrong to assign it to you feel free to unassign it.

I don't know when it was introduced; it might be old.  I just decided to go 
through my make output and look for any warnings before a1 when out 
the door.  I tend to compile with ``--without-toolbox-glue`` and that 
leads to a ton of output from modules wanting Carbon stuff and throwing 
a fit that they can't link so it just didn't catch my eye.

As for RL_COMPLETION_MATCHES, pyconfig.h has it commented out and 
config.log has test code fail at compilation because it can't find code for 
-lreadline::

configure:17625: checking for rl_completion_matches in -lreadline
configure:17656: gcc -o conftest -g -O2   conftest.c -lreadline -ltermcap 
-ldl  >        &5
ld: can't locate file for: -lreadline

so I end up with::

``ac_cv_lib_readline_rl_completion_matches=no``.

in config.log .

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 13:23

Message:
Logged In: YES 
user_id=6656

> Initially assigned to Michael since he seems to always 
> deal with the readline stuff.

Oh, er, "good".

I'm a little confused.  Is this a new thing?  As in, introduced by my 
changes just before 2.4a1?  *Why* is 
HAVE_RL_COMPLETION_MATCHES undefined?  What do config.log 
and pyconfig.h have to say on the matter?

> Would a #else statement that defines completion_matches()
> fit in there?

Not unless we can work out why it's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 21:16:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 21:16:12 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1Bk6HT-0007Vs-00@sc8-sf-web1.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 01:41
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 12:16

Message:
Logged In: YES 
user_id=357491

Well, I thought I did.  This little test is slowly turning into my personal 
Python hell for the week.

OK, so I may have a blind fix for this (if time.tzname[0] turns out to be 
UTC or GMT; realized this was a possibility).  And if that doesn't work the 
patch 
I am attaching should give us more information on what the test is 
dealing with.

Richard, can you apply the attached patch and let me know if it fixes 
things for you?  
If not please attach another traceback to the bug report.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 11:55

Message:
Logged In: YES 
user_id=31435

Brett, are you sure we understand this one?  It's the same 
test failing in the same way as I reported on Python-Dev, 
*but* Richard is seeing test_strptime fail in isolation (look at 
his attachment).  The failure I saw was due to interactions 
with test___all__ and test_site too -- test_strptime did not 
fail in isolation for me, but is failing in isolation for Richard.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 11:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 21:21:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 21:21:49 2004
Subject: [ python-Bugs-989672 ] misinforming help messages in pdb.py
Message-ID: <E1Bk6N0-00078D-00@sc8-sf-web3.sourceforge.net>

Bugs item #989672, was opened at 2004-07-12 21:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989672&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: misinforming help messages in pdb.py

Initial Comment:
The help messages the help_d and help_u methods of the
pdb.Pdb class gives have been switched. The standard
library documentation gets it right.

This is what it says:

pdb.Pdb.help_d: Move the current frame one level down
in the stack trace
(to an older frame).

pdb.Pdb.help_u: Move the current frame one level up in
the stack trace
(to a newer frame).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989672&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 21:22:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 21:22:24 2004
Subject: [ python-Bugs-989672 ] misinforming help messages in pdb.py
Message-ID: <E1Bk6NW-00079F-00@sc8-sf-web3.sourceforge.net>

Bugs item #989672, was opened at 2004-07-12 21:21
Message generated for change (Settings changed) made by percivall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989672&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 2
Submitted By: Simon Percivall (percivall)
Assigned to: Nobody/Anonymous (nobody)
Summary: misinforming help messages in pdb.py

Initial Comment:
The help messages the help_d and help_u methods of the
pdb.Pdb class gives have been switched. The standard
library documentation gets it right.

This is what it says:

pdb.Pdb.help_d: Move the current frame one level down
in the stack trace
(to an older frame).

pdb.Pdb.help_u: Move the current frame one level up in
the stack trace
(to a newer frame).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989672&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 21:31:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 21:31:20 2004
Subject: [ python-Bugs-988300 ] Compiler warnings for
	Modules/readline.c:flex_complete()
Message-ID: <E1Bk6WC-0001b8-00@sc8-sf-web4.sourceforge.net>

Bugs item #988300, was opened at 2004-07-09 16:53
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Michael Hudson (mwh)
Summary: Compiler warnings for Modules/readline.c:flex_complete()

Initial Comment:
When I compile on my OS X 10.3.4 with Fink's readline 4.3-25 I get 
the following two warnings:

/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: implicit declaration of function `completion_matches'
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: return makes pointer from integer without a cast

Now, although I have a version greater than 4.2, this only makes 
sense if HAVE_RL_COMPLETION_MATCHES is undefined and thus 
the completion_matches() macro is not being defined (although I 
checked and the headers have a prototype for 
rl_completion_matches() and my readline seems to compile and 
work well enough).

Would a #else statement that defines completion_matches() fit in 
there?  Problem would be the return type for flex_complete() 
might need to be covered as well unless a clever macro can be 
created that returns a char **.

Initially assigned to Michael since he seems to always deal with the 
readline stuff.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 12:31

Message:
Logged In: YES 
user_id=357491

Sounds like the right solution.  But unfortunately I don't know how to 
implement the fix either.  Ask on python-dev?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 11:56

Message:
Logged In: YES 
user_id=6656

So I'm guessing that the answer to this is to teach the
configure test to look in /sw/lib, then.  Not sure how to do
that...

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 11:46

Message:
Logged In: YES 
user_id=357491

> Oh, er, "good".

If I was wrong to assign it to you feel free to unassign it.

I don't know when it was introduced; it might be old.  I just decided to go 
through my make output and look for any warnings before a1 when out 
the door.  I tend to compile with ``--without-toolbox-glue`` and that 
leads to a ton of output from modules wanting Carbon stuff and throwing 
a fit that they can't link so it just didn't catch my eye.

As for RL_COMPLETION_MATCHES, pyconfig.h has it commented out and 
config.log has test code fail at compilation because it can't find code for 
-lreadline::

configure:17625: checking for rl_completion_matches in -lreadline
configure:17656: gcc -o conftest -g -O2   conftest.c -lreadline -ltermcap 
-ldl  >        &5
ld: can't locate file for: -lreadline

so I end up with::

``ac_cv_lib_readline_rl_completion_matches=no``.

in config.log .

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 05:23

Message:
Logged In: YES 
user_id=6656

> Initially assigned to Michael since he seems to always 
> deal with the readline stuff.

Oh, er, "good".

I'm a little confused.  Is this a new thing?  As in, introduced by my 
changes just before 2.4a1?  *Why* is 
HAVE_RL_COMPLETION_MATCHES undefined?  What do config.log 
and pyconfig.h have to say on the matter?

> Would a #else statement that defines completion_matches()
> fit in there?

Not unless we can work out why it's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 21:33:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 21:33:17 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1Bk6Y2-0005u6-00@sc8-sf-web2.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 09:41
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 20:33

Message:
Logged In: YES 
user_id=200117

Hi Brett,

I will test your patch when I return to work tomorrow (UK time).

FYI our HP workstations are set to GMT throughout the year.

regards,
Richard


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 20:16

Message:
Logged In: YES 
user_id=357491

Well, I thought I did.  This little test is slowly turning into my personal 
Python hell for the week.

OK, so I may have a blind fix for this (if time.tzname[0] turns out to be 
UTC or GMT; realized this was a possibility).  And if that doesn't work the 
patch 
I am attaching should give us more information on what the test is 
dealing with.

Richard, can you apply the attached patch and let me know if it fixes 
things for you?  
If not please attach another traceback to the bug report.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 19:55

Message:
Logged In: YES 
user_id=31435

Brett, are you sure we understand this one?  It's the same 
test failing in the same way as I reported on Python-Dev, 
*but* Richard is seeing test_strptime fail in isolation (look at 
his attachment).  The failure I saw was due to interactions 
with test___all__ and test_site too -- test_strptime did not 
fail in isolation for me, but is failing in isolation for Richard.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 19:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 21:41:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 21:41:36 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bk6fx-0007u9-00@sc8-sf-web3.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 21:41

Message:
Logged In: YES 
user_id=38388

Thanks for your descriptions, Hye-Shik.

Since the application space is very much targetted at East
Asian scripts, I would like the implementation to be moved
into unicodedata where all the other special Unicode
features are implemented. The .width() method should be removed.

Now that I understand better what the EAW is about, I would
also like to see the function be renamed to
east_asian_width() since that's what the function is based on.

If possible, I'd also rather like to see the full width
mapping implemented (as defined in the TR). The reduction to
narrow vs. wide seems to be oversimplified. The
east_asian_width() function should return the characters:
"N", "A", "H", "W", "F", "Na" and let the user decide how to
map these to character or string widths. We have followed
the same methodology for the other Unicode database
properties and this has not only given us much more
flexibility, it also is standards compliant and you can get
good documentation on these features.

Matthew, I suggest you write your own implementation of what
you think is right. In the face of ambiguity, there's no
such thing as the right approach to a certain problem.

Thanks.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 18:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 17:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 17:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 16:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 16:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 15:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Mon Jul 12 23:44:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 12 23:44:23 2004
Subject: [ python-Bugs-982679 ] Bad state of multi btree database file after
	large inserts
Message-ID: <E1Bk8av-0002LJ-00@sc8-sf-web2.sourceforge.net>

Bugs item #982679, was opened at 2004-06-30 11:11
Message generated for change (Comment added) made by mmangino
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982679&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Elerion Elrond (elerionelrond)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad state of multi btree database file after large inserts

Initial Comment:
The database on file is left in an bad state after
inserting a large number of entries at once in a BTREE
database. This happens when: a) multiple databases are
open in a file, b) the dbtype is DB_BTREE, c) a large
volume of key + data is inserted in the database. The
volume varies with the pagesize of the database. No
error is raised on insertion. However, if we check the
database file after insertion, we get the following
error: (-30980, 'DB_VERIFY_BAD: Database verification
failed -- Subdatabase entry references page 4 of
invalid type 5'). Moreover, running the test suite from
bsddb module yields 6 failures and 2 errors (see the
'bsddb_testrun.txt' attachment). The error condition
can be verified easily with the 'testdb.py' script -
see attachments). It was run with Python 2.3.3 and
2.3.4 on Windows XP, also with  Python 2.3.4 the cygwin
version and Python 2.3+ on Suse Linux 9.0.

----------------------------------------------------------------------

Comment By: Mike Mangino (mmangino)
Date: 2004-07-12 21:44

Message:
Logged In: YES 
user_id=74879

This happens when you open multiple databases inside a
single file without creating a database environment. With
the following code, your sample works.

import bsddb.db as db
                                                           
                    
file = "test.db"
dbenv=db.DBEnv()
dbenv.open(None,db.DB_CREATE|db.DB_INIT_MPOOL)
DB = db.DB(dbenv)
DB1 = db.DB(dbenv)
DB.open(file, "one", db.DB_BTREE, db.DB_CREATE)
DB1.open(file, "two", db.DB_BTREE, db.DB_CREATE)
                                                           
                    
for i in range(10000):
    DB[str(i)] = "1234567890123456"
                                                           
                    
DB.sync()
DB.close()
DB1.sync()
DB1.close()
                                                           
                    
db.DB().verify(file)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982679&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 00:08:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 00:08:11 2004
Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur
Message-ID: <E1Bk8xy-0004vI-00@sc8-sf-web3.sourceforge.net>

Bugs item #570300, was opened at 2002-06-18 04:24
Message generated for change (Comment added) made by amitar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470

Category: Python Library
Group: None
>Status: Open
Resolution: Out of Date
Priority: 3
Submitted By: Amit Aronovitch (amitar)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getmodule symlink-related failur

Initial Comment:
news:ae3e29$pib$1@news.netvision.net.il

Description:
--------------

  On a unix python2.2.1 installation I noticed that the 
documentations
generated for modules by pydoc (in any mode - even 
the help command) did NOT
contain any docs for functions.
  After some digging, I found out the reason for that, 
and now I believe it
indicates a deeper problem with the &quot;inspect&quot; module, 
concerning file
identification in the presence of symbolic or hard links, 
which I'll explain
below, and also suggest solutions.

Analysis:
-----------

  The reason the functions were dropped from the doc 
was pydoc's attempt to
remove functions which were imported from other 
modules. This is done by
something like &quot;inspect.getmodule(my_func) is 
my_module&quot;. I found out that
inspect.getmodule() returned &quot;None&quot; for these 
functions!

  Now, inspect.getmodule works by getting the 
function's filename, and then
searching it in a dictionary containing the filenames for 
all the modules
that were loaded (&quot;modulesbyfile&quot;). Unfortunately, the 
filename that
getabsfile() returns for the function is not the same 
STRING as the one it
returns for the module, but rather an equivalent unix 
path pointing to the
same FILE
(the reason for this fact is that the filename for a 
function is extracted
from the code-object, which holds the path the module 
was referred to at the
time it was COMPILED to .pyc, whereas the one for 
the module is taken from
it's __file__, which holds the path it was referred to 
when it was
IMPORTED - these two might differ even if it's the 
same file).

 So, the function's file is not found on the dictionary, 
and getmodule()
returns None...

Discussion:
--------------

  We see that the root cause of the problem is 
that &quot;inspect&quot; uses the
&quot;absolute path&quot; (os.path.abspath()) for representing 
the file's identity.
In unix systems, this might cause a problem, since 
this string is NOT unique
(it is a unique path, but different paths may refer to 
the same file).
If we only considered symbolic links, this could be 
resolved by scanning the
path elements and &quot;unfolding&quot; any symlinks, but we 
must recall that unix can
also has &quot;hard links&quot; which are equivalent references to 
the same inode, and
can't be discriminated.

  So, if we want to resolve the problem in a portable 
way, we need an
immutable (platform-dependant) object that will be 
unique to a FILE. This
object could then be used for comparing files and as 
keys for dictionaries.
 A reasonable way to get it would be by means of a 
new function in the os
module. e.g. :

 id = os.get_fileid(filename)
def samefile(f1,f2): return os.get_fileid(f1) is 
os.get_fileid(f2)

 This function could be implemented by the inode 
number (os.stat(f).st_ino)
on unix systems, and by the absolute path 
(os.path.abspath) on systems which
do not support links (such as windows), or by 
anything else, as long as it
would be immutable and unique for each file.


  Please let me know your opinion about this 
suggestion,

       Amit Aronovitch



----------------------------------------------------------------------

>Comment By: Amit Aronovitch (amitar)
Date: 2004-07-13 01:08

Message:
Logged In: YES 
user_id=564711

In my experience, problems don't just "go away" by
themselves. Someone needs to actually fix them.
 So, I tested on 2.4a - and results are EXACTLY THE SAME
(attached printout).

 It seems that no-one got to actually READ this lengthy
description, so I'll have to send patches. Sorry I did not
do that already, and sorry again but it seems I'm not going
to get to that soon enough. I'll try to get it done by the
end of July.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 21:23

Message:
Logged In: YES 
user_id=357491

Well, looks like this problem has gone away, at least in 2.4.  Closing out 
outdated.

----------------------------------------------------------------------

Comment By: Amit Aronovitch (amitar)
Date: 2003-05-18 23:10

Message:
Logged In: YES 
user_id=564711

Sorry - seems like I forgot most basic step in prob-
reporting - the &quot;howtorepeat&quot; :-) - so here it comes:

How to repeat:
----------------------
(as I said - you need unix &amp; symlinks to see this happening):

~&gt; mkdir test
~&gt; setenv PYTHONPATH ~/test
~&gt; cat &gt;test/test_mod.py
&quot;module doc&quot;
def blah():
   &quot;hello&quot;
   pass
^D
~&gt; python
&gt;&gt; import test_mod
&gt;&gt; help(test_mod)
&gt;&gt; ^D
[ Prints help - so far so good - no problem - but see now]

~&gt; ln -s test test2
~&gt; setenv PYTHONPATH test2
~&gt; python
&gt;&gt; import test_mod
&gt;&gt; help(test_mod)
[ Now the help shows up without the help of the blah 
function]

Relating the example to my explanations above:
------------------------------------------------------------------------
The help of the blah() function is filtered out, 
because &quot;inspect&quot; takes &quot;~/test/test_mod.pyc&quot; as it's 
filename, and &quot;~/test1/test_mod.pyc&quot; as the module's 
filename. It can't tell that these are the same file (see 
details in my &quot;Analysis&quot; section above).

  True, this messing up with symlinks and PYTHONPATH is 
a bit ugly, but this is just to demonstrate the problem. The 
system where I noticed it is quite complex, with disks 
shared (automounted) across several platforms, and it 
needs a few symlinks to make things easyer to maintain.
  As I explained, I think that few little changes in modules 
such as &quot;inspect&quot; and &quot;os&quot; can make them identify files 
better in the presence of links.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-17 05:34

Message:
Logged In: YES 
user_id=357491

Just tested under 2.2.2 and 2.3b1 using a module containing just::

 def blah():
    &quot;&quot;&quot;Hello&quot;&quot;&quot;&quot;
    pass

Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the 
name of the function and its docstring.  Am I missing something here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 02:26:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 02:26:07 2004
Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur
Message-ID: <E1BkB7R-0000I2-00@sc8-sf-web3.sourceforge.net>

Bugs item #570300, was opened at 2002-06-17 18:24
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: None
Priority: 3
Submitted By: Amit Aronovitch (amitar)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.getmodule symlink-related failur

Initial Comment:
news:ae3e29$pib$1@news.netvision.net.il

Description:
--------------

  On a unix python2.2.1 installation I noticed that the 
documentations
generated for modules by pydoc (in any mode - even 
the help command) did NOT
contain any docs for functions.
  After some digging, I found out the reason for that, 
and now I believe it
indicates a deeper problem with the &quot;inspect&quot; module, 
concerning file
identification in the presence of symbolic or hard links, 
which I'll explain
below, and also suggest solutions.

Analysis:
-----------

  The reason the functions were dropped from the doc 
was pydoc's attempt to
remove functions which were imported from other 
modules. This is done by
something like &quot;inspect.getmodule(my_func) is 
my_module&quot;. I found out that
inspect.getmodule() returned &quot;None&quot; for these 
functions!

  Now, inspect.getmodule works by getting the 
function's filename, and then
searching it in a dictionary containing the filenames for 
all the modules
that were loaded (&quot;modulesbyfile&quot;). Unfortunately, the 
filename that
getabsfile() returns for the function is not the same 
STRING as the one it
returns for the module, but rather an equivalent unix 
path pointing to the
same FILE
(the reason for this fact is that the filename for a 
function is extracted
from the code-object, which holds the path the module 
was referred to at the
time it was COMPILED to .pyc, whereas the one for 
the module is taken from
it's __file__, which holds the path it was referred to 
when it was
IMPORTED - these two might differ even if it's the 
same file).

 So, the function's file is not found on the dictionary, 
and getmodule()
returns None...

Discussion:
--------------

  We see that the root cause of the problem is 
that &quot;inspect&quot; uses the
&quot;absolute path&quot; (os.path.abspath()) for representing 
the file's identity.
In unix systems, this might cause a problem, since 
this string is NOT unique
(it is a unique path, but different paths may refer to 
the same file).
If we only considered symbolic links, this could be 
resolved by scanning the
path elements and &quot;unfolding&quot; any symlinks, but we 
must recall that unix can
also has &quot;hard links&quot; which are equivalent references to 
the same inode, and
can't be discriminated.

  So, if we want to resolve the problem in a portable 
way, we need an
immutable (platform-dependant) object that will be 
unique to a FILE. This
object could then be used for comparing files and as 
keys for dictionaries.
 A reasonable way to get it would be by means of a 
new function in the os
module. e.g. :

 id = os.get_fileid(filename)
def samefile(f1,f2): return os.get_fileid(f1) is 
os.get_fileid(f2)

 This function could be implemented by the inode 
number (os.stat(f).st_ino)
on unix systems, and by the absolute path 
(os.path.abspath) on systems which
do not support links (such as windows), or by 
anything else, as long as it
would be immutable and unique for each file.


  Please let me know your opinion about this 
suggestion,

       Amit Aronovitch



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 17:26

Message:
Logged In: YES 
user_id=357491

Well, when a bug gets old and you don't have a test to make sure it has 
been fixed, yes, things just do "go away" in the stdlib.  The amount of 
code change in the stdlib can easily lead to some other bug being fixed.

And I did read it.  But when the problem stopped presenting itself to me 
(and I don't know why; I spent a good amount of time on this on the July 
10 Bug Day)?I figured it was gone.  If I can't reproduce it I can't try to fix 
it.

But if you can come up with a patch to fix this feel free to assign it to 
me.

----------------------------------------------------------------------

Comment By: Amit Aronovitch (amitar)
Date: 2004-07-12 15:08

Message:
Logged In: YES 
user_id=564711

In my experience, problems don't just "go away" by
themselves. Someone needs to actually fix them.
 So, I tested on 2.4a - and results are EXACTLY THE SAME
(attached printout).

 It seems that no-one got to actually READ this lengthy
description, so I'll have to send patches. Sorry I did not
do that already, and sorry again but it seems I'm not going
to get to that soon enough. I'll try to get it done by the
end of July.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-10 11:23

Message:
Logged In: YES 
user_id=357491

Well, looks like this problem has gone away, at least in 2.4.  Closing out 
outdated.

----------------------------------------------------------------------

Comment By: Amit Aronovitch (amitar)
Date: 2003-05-18 13:10

Message:
Logged In: YES 
user_id=564711

Sorry - seems like I forgot most basic step in prob-
reporting - the &quot;howtorepeat&quot; :-) - so here it comes:

How to repeat:
----------------------
(as I said - you need unix &amp; symlinks to see this happening):

~&gt; mkdir test
~&gt; setenv PYTHONPATH ~/test
~&gt; cat &gt;test/test_mod.py
&quot;module doc&quot;
def blah():
   &quot;hello&quot;
   pass
^D
~&gt; python
&gt;&gt; import test_mod
&gt;&gt; help(test_mod)
&gt;&gt; ^D
[ Prints help - so far so good - no problem - but see now]

~&gt; ln -s test test2
~&gt; setenv PYTHONPATH test2
~&gt; python
&gt;&gt; import test_mod
&gt;&gt; help(test_mod)
[ Now the help shows up without the help of the blah 
function]

Relating the example to my explanations above:
------------------------------------------------------------------------
The help of the blah() function is filtered out, 
because &quot;inspect&quot; takes &quot;~/test/test_mod.pyc&quot; as it's 
filename, and &quot;~/test1/test_mod.pyc&quot; as the module's 
filename. It can't tell that these are the same file (see 
details in my &quot;Analysis&quot; section above).

  True, this messing up with symlinks and PYTHONPATH is 
a bit ugly, but this is just to demonstrate the problem. The 
system where I noticed it is quite complex, with disks 
shared (automounted) across several platforms, and it 
needs a few symlinks to make things easyer to maintain.
  As I explained, I think that few little changes in modules 
such as &quot;inspect&quot; and &quot;os&quot; can make them identify files 
better in the presence of links.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-16 19:34

Message:
Logged In: YES 
user_id=357491

Just tested under 2.2.2 and 2.3b1 using a module containing just::

 def blah():
    &quot;&quot;&quot;Hello&quot;&quot;&quot;&quot;
    pass

Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the 
name of the function and its docstring.  Am I missing something here?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 02:54:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 02:54:08 2004
Subject: [ python-Bugs-635453 ] urllib.urlretrieve() with ftp error 
Message-ID: <E1BkBYa-0007fc-00@sc8-sf-web2.sourceforge.net>

Bugs item #635453, was opened at 2002-11-08 03:39
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635453&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Brett Cannon (bcannon)
Summary: urllib.urlretrieve() with ftp error 

Initial Comment:
When using urllib.urlretrieve() to obtain a file
through ftp and the file is not readable the directory
listing of the file is returned.  The expected behavior
is that a &quot;permission denied&quot; error is generated.
The current behavior makes it impossible to detect
downloading a file failed.

To reproduce:

from urllib import urlretrieve
fname = &quot;/pub/vim/unstable/testfile&quot;
url = &quot;ftp://ftp.vim.org&quot;
resfile, h = urlretrieve(url + fname)
print &quot;file contents: '%s'&quot; % open(resfile).read()
print &quot;header stuff: &quot;, h

The result:
file contents: '-rw-------   1 506      450           
25 Nov  8 11:50 testfile
'

Using ftplib.FTP() does result in the expected error:

from ftplib import FTP
def list(s):
	print s
f = FTP(&quot;ftp.vim.org&quot;)
f.login()
f.retrbinary(&quot;RETR &quot; + fname, list)
f.quit()

The last line of the resulting exception:
ftplib.error_perm: 550 /pub/vim/unstable/testfile:
Permission denied.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 17:54

Message:
Logged In: YES 
user_id=357491

So this was discussed on python-dev (see the thread at http://
mail.python.org/pipermail/python-dev/2004-July/046035.html ) and the 
conclusion was to not change the behavior.  Since that handling is the 
only way for directory listings to work when people leave off a trailing 
slash it was deemed not as nice as the current situation.

A note has been added to the "Restrictions" part of the urllib docs to 
state this behavior.

----------------------------------------------------------------------

Comment By: John Ehresman (jpe)
Date: 2004-07-10 13:27

Message:
Logged In: YES 
user_id=22785

This is evidently the intended behavior when a url for an
unreadable file is opened, but I think it would make more
sense to raise an exception.  To change the behavior so it
raises an exception, simply remove the test for an exception
reason starting with 550 from ftpwrapper.retrfile() in
urllib.py.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635453&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 05:36:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 05:36:26 2004
Subject: [ python-Bugs-982679 ] Bad state of multi btree database file after
	large inserts
Message-ID: <E1BkE5c-0004yy-00@sc8-sf-web3.sourceforge.net>

Bugs item #982679, was opened at 2004-06-30 13:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982679&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Elerion Elrond (elerionelrond)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad state of multi btree database file after large inserts

Initial Comment:
The database on file is left in an bad state after
inserting a large number of entries at once in a BTREE
database. This happens when: a) multiple databases are
open in a file, b) the dbtype is DB_BTREE, c) a large
volume of key + data is inserted in the database. The
volume varies with the pagesize of the database. No
error is raised on insertion. However, if we check the
database file after insertion, we get the following
error: (-30980, 'DB_VERIFY_BAD: Database verification
failed -- Subdatabase entry references page 4 of
invalid type 5'). Moreover, running the test suite from
bsddb module yields 6 failures and 2 errors (see the
'bsddb_testrun.txt' attachment). The error condition
can be verified easily with the 'testdb.py' script -
see attachments). It was run with Python 2.3.3 and
2.3.4 on Windows XP, also with  Python 2.3.4 the cygwin
version and Python 2.3+ on Suse Linux 9.0.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-13 05:36

Message:
Logged In: YES 
user_id=21627

As mmangino says, this is not a bug, so closing it.

----------------------------------------------------------------------

Comment By: Mike Mangino (mmangino)
Date: 2004-07-12 23:44

Message:
Logged In: YES 
user_id=74879

This happens when you open multiple databases inside a
single file without creating a database environment. With
the following code, your sample works.

import bsddb.db as db
                                                           
                    
file = "test.db"
dbenv=db.DBEnv()
dbenv.open(None,db.DB_CREATE|db.DB_INIT_MPOOL)
DB = db.DB(dbenv)
DB1 = db.DB(dbenv)
DB.open(file, "one", db.DB_BTREE, db.DB_CREATE)
DB1.open(file, "two", db.DB_BTREE, db.DB_CREATE)
                                                           
                    
for i in range(10000):
    DB[str(i)] = "1234567890123456"
                                                           
                    
DB.sync()
DB.close()
DB1.sync()
DB1.close()
                                                           
                    
db.DB().verify(file)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=982679&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 08:10:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 08:10:49 2004
Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k
Message-ID: <E1BkGV3-0001tg-00@sc8-sf-web1.sourceforge.net>

Bugs item #989338, was opened at 2004-07-12 14:11
Message generated for change (Comment added) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_unicode_file fails on win2k

Initial Comment:
>>> test_support.verbose = 1
>>> test_unicode_file.test_main()
test_directories
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_single_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR

======================================================================
ERROR: test_directories
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
178, in test_directories
    self._do_directory(TESTFN_ENCODED+ext,
TESTFN_ENCODED+ext, True)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
112, in _do_directory
    os.mkdir(make_name)
OSError: [Errno 22] Invalid argument: '@test-??.dir'

======================================================================
ERROR: test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
170, in test_equivalent_files
    self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
154, in _test_equivalent
    f = file(filename1, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

======================================================================
ERROR: test_single_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
164, in test_single_files
    self._test_single(TESTFN_ENCODED)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
136, in _test_single
    f = file(filename, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

----------------------------------------------------------------------
Ran 3 tests in 0.061s

FAILED (errors=3)

Traceback (most recent call last):
  File "<pyshell#21>", line 1, in -toplevel-
    test_unicode_file.test_main()
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
191, in test_main
    run_suite(suite)
  File "C:\apps\Python24\lib\test\test_support.py",
line 274, in run_suite
    raise TestFailed(msg)
TestFailed: errors occurred; run in verbose mode for
details
>>> 

This is Python2.4a1 on win2k pro

----------------------------------------------------------------------

>Comment By: Miki Tebeka (tebeka)
Date: 2004-07-13 09:10

Message:
Logged In: YES 
user_id=358087

Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro.
Any other data I can send?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 19:35

Message:
Logged In: YES 
user_id=31435

Peculiar -- it works fine on WinXP Pro, which ought to work 
the same as Win2K here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 09:27:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 09:27:43 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1BkHhR-00064N-00@sc8-sf-web4.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 09:41
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2004-07-13 08:27

Message:
Logged In: YES 
user_id=200117

Brett, test_strptime.py still gives an error after I applied your 
patch - see attached file strptime_err.txt

Here are the variable settings from the time module:
    accept2dyear = 1
    altzone = -3600
    daylight = 0
    timezone = 0
    tzname = ('GMT', '')



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 20:33

Message:
Logged In: YES 
user_id=200117

Hi Brett,

I will test your patch when I return to work tomorrow (UK time).

FYI our HP workstations are set to GMT throughout the year.

regards,
Richard


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 20:16

Message:
Logged In: YES 
user_id=357491

Well, I thought I did.  This little test is slowly turning into my personal 
Python hell for the week.

OK, so I may have a blind fix for this (if time.tzname[0] turns out to be 
UTC or GMT; realized this was a possibility).  And if that doesn't work the 
patch 
I am attaching should give us more information on what the test is 
dealing with.

Richard, can you apply the attached patch and let me know if it fixes 
things for you?  
If not please attach another traceback to the bug report.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 19:55

Message:
Logged In: YES 
user_id=31435

Brett, are you sure we understand this one?  It's the same 
test failing in the same way as I reported on Python-Dev, 
*but* Richard is seeing test_strptime fail in isolation (look at 
his attachment).  The failure I saw was due to interactions 
with test___all__ and test_site too -- test_strptime did not 
fail in isolation for me, but is failing in isolation for Richard.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 19:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 19:17:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 19:17:58 2004
Subject: [ python-Bugs-990307 ] cgi.parse_qsl broken
Message-ID: <E1BkQuf-0004sL-00@sc8-sf-web4.sourceforge.net>

Bugs item #990307, was opened at 2004-07-13 17:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990307&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: A.M. Kuchling (akuchling)
Summary: cgi.parse_qsl broken

Initial Comment:
The cgi module has been changed so that now
parse_qsl("", keep_blank_values=True) returns [('',
'')].  I think that's wrong.  I thought about changing
it so that items with empty names are skipped but
test_cgi requires that "=a" produce [('', 'a')].  I
also thought about special casing the empty string to
return [] but test_cgi checks that parse_qsl("",
strict_parsing=1) raises ValueError.  That seems wrong
to me but I'm scared to change it since there may be
code out there that depends on this behavior.  OTOH, it
seems highly unlikely that people would find the strict
parsing flag useful (there's too much broken stuff on
the net).

The minimal fix would be to not generate any items that
are equal to ('', '').  Looking for advice.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990307&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 20:00:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 20:00:42 2004
Subject: [ python-Bugs-990325 ] testtar.tar is partially insane
Message-ID: <E1BkRa3-0007YE-00@sc8-sf-web1.sourceforge.net>

Bugs item #990325, was opened at 2004-07-13 14:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990325&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: testtar.tar is partially insane

Initial Comment:
The test file testtar.tar is a binary file, but contains 
(seemingly by accident) CVS keywords, like $Date$ and 
$Revision$.  As a result, if Python is checked out with -
kk (don't expand keywords), test_tarfile fails.  I'm not 
clear on exactly why.

Binary files shouldn't have CVS keywords inside them, 
and tests shouldn't care whether keywords are 
expanded anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990325&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 21:33:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 21:33:49 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1BkT28-000318-00@sc8-sf-web1.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 02:42
Message generated for change (Comment added) made by simon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

>Comment By: Simon Michael (simon)
Date: 2004-07-13 12:33

Message:
Logged In: YES 
user_id=572

See also discussion at http://collector.zope.org/Zope/1395

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 13:21

Message:
Logged In: YES 
user_id=4771

What I mean here is that you should report this bug to Zope, not to Python, unless there is a good reason to suspect that a bug in the Python core is causing it.  But to me it really looks like a bug in the Zope extension module, which for some reason shows up only with some version of Python or on some platform.

----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 12:25

Message:
Logged In: YES 
user_id=572

UnownedDTML is indeed a zope extension class.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 08:20

Message:
Logged In: YES 
user_id=4771

If this bug involves C extension modules specific to Zope
then I'd first consider it as a bug in one of these modules.
 I would be particularly suspicious that this is the case in
a file called testSecurity: isn't its goal to check some
C-implemented security feature of Zope?

If I am wrong please try to provide a Python code sample. 
Reading a class attribute out of some class tends to work
just fine.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2004-07-01 03:34

Message:
Logged In: YES 
user_id=11084

Works for me with Python 2.3.3/4 on three different Linux
systems.


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 02:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 22:02:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 22:02:39 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1BkTU4-0004Bq-00@sc8-sf-web1.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 04:42
Message generated for change (Comment added) made by adustman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

Comment By: Andy Dustman (adustman)
Date: 2004-07-13 15:02

Message:
Logged In: YES 
user_id=71372

This may or may not be related: I've had scattered reports
of people having trouble with attribute access (maybe) with
MySQLdb-1.0.0 on Python-2.3.4 (and maybe 2.3.3 but not 2.2)
on *BSD and Mac OS X, but I can't reproduce it on Linux
(x86) with 2.3.4. One person is getting a segfault upon
import (this is not in the bug listed below); I am trying to
get a gdb backtraces.

https://sourceforge.net/tracker/index.php?func=detail&aid=970667&group_id=22307&atid=374932


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-13 14:33

Message:
Logged In: YES 
user_id=572

See also discussion at http://collector.zope.org/Zope/1395

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 15:21

Message:
Logged In: YES 
user_id=4771

What I mean here is that you should report this bug to Zope, not to Python, unless there is a good reason to suspect that a bug in the Python core is causing it.  But to me it really looks like a bug in the Zope extension module, which for some reason shows up only with some version of Python or on some platform.

----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 14:25

Message:
Logged In: YES 
user_id=572

UnownedDTML is indeed a zope extension class.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 10:20

Message:
Logged In: YES 
user_id=4771

If this bug involves C extension modules specific to Zope
then I'd first consider it as a bug in one of these modules.
 I would be particularly suspicious that this is the case in
a file called testSecurity: isn't its goal to check some
C-implemented security feature of Zope?

If I am wrong please try to provide a Python code sample. 
Reading a class attribute out of some class tends to work
just fine.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2004-07-01 05:34

Message:
Logged In: YES 
user_id=11084

Works for me with Python 2.3.3/4 on three different Linux
systems.


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 04:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 22:59:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 22:59:13 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1BkUMk-00044L-00@sc8-sf-web3.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 20:19
Message generated for change (Comment added) made by shredwheat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (shredwheat)
Assigned to: Michael Hudson (mwh)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

>Comment By: Pete Shinners (shredwheat)
Date: 2004-07-13 20:59

Message:
Logged In: YES 
user_id=1076442

Here is patch, please review and let me know if further
revisions are necessary. Not sure if the comment line in
each error case is helpful or a distraction.

Performance difference is negligable for the common
'success' case. If multiple arguments raise exceptions it is
undefined which one is current when the function returns. A
NULL will still be returned if there are any exceptions.

(my first Python patch, exciting)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 17:59

Message:
Logged In: YES 
user_id=80475

Thanks, that will be nice.

Do make a special effort to make sure this has zero
performance impact on the common case.  No sense in mucking
up the works to satisfy a corner case that rarely impacts
real apps.

----------------------------------------------------------------------

Comment By: Pete Shinners (shredwheat)
Date: 2004-07-12 14:29

Message:
Logged In: YES 
user_id=1076442

I will attempt a patch, this does not look difficult. I am
currently trying to get straight CVS Python to run the test
suite, but having difficulty. I will have a patch ready or
more comments otherwise later this week.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 13:36

Message:
Logged In: YES 
user_id=80475

I thought you would have an interest and be in a good
position to know whether and how this should be fixed.  Feel
free to unassign.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 12:30

Message:
Logged In: YES 
user_id=6656

Um.  Any particular reason for assigning to me?  I could probably 
review and apply any patch that appears, but I'm unlikely to get to 
creating one myself...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 23:07:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 23:07:48 2004
Subject: [ python-Bugs-897820 ] db4 4.2 == :-( (test_anydbm and test_bsddb3)
Message-ID: <E1BkUV3-0005DM-00@sc8-sf-web4.sourceforge.net>

Bugs item #897820, was opened at 2004-02-15 22:03
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897820&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Gregory P. Smith (greg)
Summary: db4 4.2 == :-(  (test_anydbm and test_bsddb3)

Initial Comment:
This machine, running fedora core 2 (test) has db4
4.2.52 installed. test_anydbm fails utterly with this
combination. 
3 of the 4 tests fail, the failing part is the same in
each case:

  File "Lib/anydbm.py", line 83, in open
    return mod.open(file, flag, mode)
  File "Lib/dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
  File "Lib/bsddb/__init__.py", line 293, in hashopen
    d.open(file, db.DB_HASH, flags, mode)
DBInvalidArgError: (22, 'Invalid argument --
DB_TRUNCATE illegal with locking specified')

test_bsddb passes, but test_bsddb3 fails with a similar
error:

test test_bsddb3 failed -- Traceback (most recent call
last):
  File "Lib/bsddb/test/test_compat.py", line 82, in
test04_n_flag
    f = hashopen(self.filename, 'n')
  File "Lib/bsddb/__init__.py", line 293, in hashopen
    d.open(file, db.DB_HASH, flags, mode)
DBInvalidArgError: (22, 'Invalid argument --
DB_TRUNCATE illegal with locking specified')



----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2004-07-13 14:07

Message:
Logged In: YES 
user_id=413

committed to release23-maint as Lib/bsddb/__init__.py 1.5.10.5.

closing.


----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2004-06-27 16:00

Message:
Logged In: YES 
user_id=413

A workaround for this BerkeleyDB change has been committed
to HEAD.

dist/src/Lib/bsddb/__init__.py rev 1.15

I've marked this bug as "python 2.3" now as a reminder for
me to commit this to the 2.3 maintenance branch before 2.3.5.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-06-18 04:27

Message:
Logged In: YES 
user_id=29957

Regardless of whether there's a workaround or not, the test
suite should not fail. Fedora Core is a fairly well known
distro, and while FC2 is probably the first to ship with db
4.2, I'm sure it won't be the last.



----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2004-06-16 15:40

Message:
Logged In: YES 
user_id=413

As Tim Peters pointed out on python-dev in march:

> I suspect Sleepycat screwed us there, changing the rules
in midstream.
> Someone on c.l.py appeared to track down the same thing
here, but in an app
> instead of in our test suite:
> 
>    
http://mail.python.org/pipermail/python-list/2004-May/220168.html
> 
>     The change log of Berkeley DB 4.2.52 says "9. Fix a
bug to now
>     disallow DB_TRUNCATE on opens in locking environments,
since we
>     cannot prevent race conditions ..."

leaving the bug open until i look to see if there is a
workaround.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897820&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 23:14:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 23:14:20 2004
Subject: [ python-Bugs-890872 ] BSDDB set_location bug
Message-ID: <E1BkUbR-0002kx-00@sc8-sf-web2.sourceforge.net>

Bugs item #890872, was opened at 2004-02-05 01:08
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890872&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
>Assigned to: Gregory P. Smith (greg)
Summary: BSDDB set_location bug

Initial Comment:
In module \lib\bsddb\__init__.py line 147, the method
set_location() uses self.dbc.set(key) , which raises an
error if the key is not found.  It should be using
self.dbc.set_range(key) , which matches the documented
behaviour for btree databases.

Test for correct behaviour is attached.

Behaviour is seen under Python 2.3.3 win32 binary build.

----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2004-07-13 14:14

Message:
Logged In: YES 
user_id=413

this has been fixed in both HEAD and python 2.3 cvs with a
test case.  (appears to have been committed a while ago)

----------------------------------------------------------------------

Comment By: alan johnson (chomo)
Date: 2004-06-14 14:07

Message:
Logged In: YES 
user_id=943591

looks like need testcase

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890872&group_id=5470
From noreply at sourceforge.net  Tue Jul 13 23:41:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 13 23:41:56 2004
Subject: [ python-Bugs-990497 ] mistyped example
Message-ID: <E1BkV29-0005ag-00@sc8-sf-web3.sourceforge.net>

Bugs item #990497, was opened at 2004-07-13 14:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990497&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Pezely (pezely)
Assigned to: Nobody/Anonymous (nobody)
Summary: mistyped example

Initial Comment:
>From "What's New in Python 2.4"
http://www.python.org/dev/doc/devel/whatsnew/node7.html


Under "6 Other Language Changes" section:

Bullet item "There is a new built-in function
sorted(iterable) that works..." first example:

>>> L = [9,7,8,3,2,4,1,6,5]
>>> [10+i for i in sorted(L)]       # usable in a list
comprehension
[11, 12, 13, 14, 15, 16, 17, 18, 19]
>>> L = [9,7,8,3,2,4,1,6,5]         # original is left
unchanged
[9,7,8,3,2,4,1,6,5]   



To illustrate the point given in the text, the last 2
lines should be:

>>> L                                   # original is
left unchanged
[9,7,8,3,2,4,1,6,5]

That is, it should be without assignment.


Or perhaps:
>>> L == [9,7,8,3,2,4,1,6,5]         # original is left
unchanged
True



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990497&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 00:18:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 00:18:17 2004
Subject: [ python-Bugs-990524 ] online documentation says "Nac" in the link,
	"Nav" for mod
Message-ID: <E1BkVbL-0007lP-00@sc8-sf-web4.sourceforge.net>

Bugs item #990524, was opened at 2004-07-13 15:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990524&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Nobody/Anonymous (nobody)
Summary: online documentation says "Nac" in the link, "Nav" for mod

Initial Comment:
For the following webpage:
http://www.python.org/doc/2.3.4/modindex.html
the link for the module says "Nac (Mac)", but on the 
linked page:
http://www.python.org/doc/2.3.4/mac/module-Nac.html
The module name is listed as "Nav".

One of these names must be wrong.  I haven't checked 
to see what the correct module name is.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990524&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 01:53:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 01:53:28 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BkX5Q-0002B4-00@sc8-sf-web4.sourceforge.net>

Bugs item #990569, was opened at 2004-07-13 16:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 02:49:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 02:49:12 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1BkXxJ-0002V2-00@sc8-sf-web3.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 01:41
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-13 17:49

Message:
Logged In: YES 
user_id=357491

OK, so I screwed the patch up by using the line ``tz_name.lower() in 
("UTC", "GMT")``.  Notice how everything is in caps in the tuple but I call 
str.lower()?  Nice way to guarantee that the test is never true.

Sorry about that stupid mistake, Richard.  If you happen to still have the 
last patch applied, either just apply the new patch or fix line 283 yourself 
since it is just a single word change.  That should fix it.  At least my 
blind reasoning over what could be causing the failure was correct.

Thanks for putting up with this.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-13 00:27

Message:
Logged In: YES 
user_id=200117

Brett, test_strptime.py still gives an error after I applied your 
patch - see attached file strptime_err.txt

Here are the variable settings from the time module:
    accept2dyear = 1
    altzone = -3600
    daylight = 0
    timezone = 0
    tzname = ('GMT', '')



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 12:33

Message:
Logged In: YES 
user_id=200117

Hi Brett,

I will test your patch when I return to work tomorrow (UK time).

FYI our HP workstations are set to GMT throughout the year.

regards,
Richard


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 12:16

Message:
Logged In: YES 
user_id=357491

Well, I thought I did.  This little test is slowly turning into my personal 
Python hell for the week.

OK, so I may have a blind fix for this (if time.tzname[0] turns out to be 
UTC or GMT; realized this was a possibility).  And if that doesn't work the 
patch 
I am attaching should give us more information on what the test is 
dealing with.

Richard, can you apply the attached patch and let me know if it fixes 
things for you?  
If not please attach another traceback to the bug report.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 11:55

Message:
Logged In: YES 
user_id=31435

Brett, are you sure we understand this one?  It's the same 
test failing in the same way as I reported on Python-Dev, 
*but* Richard is seeing test_strptime fail in isolation (look at 
his attachment).  The failure I saw was due to interactions 
with test___all__ and test_site too -- test_strptime did not 
fail in isolation for me, but is failing in isolation for Richard.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 11:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 06:58:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 06:58:44 2004
Subject: [ python-Bugs-990669 ] os.path.realpath() does not handle symlinks
	correctly
Message-ID: <E1Bkbqq-0003A0-00@sc8-sf-web1.sourceforge.net>

Bugs item #990669, was opened at 2004-07-14 00:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990669&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Anton Koinov (dave0000)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.realpath() does not handle symlinks correctly

Initial Comment:
os.path.realpath() does not handle symlinks properly on
Linux (at least, does not do it the same way as the
Linux file functions do).

To reproduce follow these steps:

mkdir a
mkdir a/k
mkdir a/l
mkdir a/k/x
mkdir a/k/y
cd a
ln -s k/y link-y
ls link-y/..

This outputs: x/  y/
In other words, link-y/.. == a/k

Now, while still in directory 'a' (in bash) execute on
one line: 
python -c 'import os.path'$'\n''print
os.path.realpath("link-y/..")'

This will print: /path/to/a
In other words: os.path.realpath('link-y/..') == a

That is, the link link-y has not been expanded to the
directory it points to before .. (go to parent
directory) has been applied to the path.

os.path.normpath() has the same problem.

This may be a potential security risk if one uses
realpath to check if a requested path is inside a
certain restricted subdirectory.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990669&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 09:18:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 09:18:19 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1Bke1n-0005lf-00@sc8-sf-web4.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 09:41
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2004-07-14 08:18

Message:
Logged In: YES 
user_id=200117

I made the change and the test now runs without errors.

Thanks for fixing this - I'm glad I could help with the testing.




----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-14 01:49

Message:
Logged In: YES 
user_id=357491

OK, so I screwed the patch up by using the line ``tz_name.lower() in 
("UTC", "GMT")``.  Notice how everything is in caps in the tuple but I call 
str.lower()?  Nice way to guarantee that the test is never true.

Sorry about that stupid mistake, Richard.  If you happen to still have the 
last patch applied, either just apply the new patch or fix line 283 yourself 
since it is just a single word change.  That should fix it.  At least my 
blind reasoning over what could be causing the failure was correct.

Thanks for putting up with this.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-13 08:27

Message:
Logged In: YES 
user_id=200117

Brett, test_strptime.py still gives an error after I applied your 
patch - see attached file strptime_err.txt

Here are the variable settings from the time module:
    accept2dyear = 1
    altzone = -3600
    daylight = 0
    timezone = 0
    tzname = ('GMT', '')



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 20:33

Message:
Logged In: YES 
user_id=200117

Hi Brett,

I will test your patch when I return to work tomorrow (UK time).

FYI our HP workstations are set to GMT throughout the year.

regards,
Richard


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 20:16

Message:
Logged In: YES 
user_id=357491

Well, I thought I did.  This little test is slowly turning into my personal 
Python hell for the week.

OK, so I may have a blind fix for this (if time.tzname[0] turns out to be 
UTC or GMT; realized this was a possibility).  And if that doesn't work the 
patch 
I am attaching should give us more information on what the test is 
dealing with.

Richard, can you apply the attached patch and let me know if it fixes 
things for you?  
If not please attach another traceback to the bug report.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 19:55

Message:
Logged In: YES 
user_id=31435

Brett, are you sure we understand this one?  It's the same 
test failing in the same way as I reported on Python-Dev, 
*but* Richard is seeing test_strptime fail in isolation (look at 
his attachment).  The failure I saw was due to interactions 
with test___all__ and test_site too -- test_strptime did not 
fail in isolation for me, but is failing in isolation for Richard.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 19:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 10:56:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 10:56:09 2004
Subject: [ python-Bugs-983311 ] simple attribute access causing segfault in
	certain cases
Message-ID: <E1BkfYb-0006sj-00@sc8-sf-web2.sourceforge.net>

Bugs item #983311, was opened at 2004-07-01 10:42
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Michael (simon)
Assigned to: Nobody/Anonymous (nobody)
Summary: simple attribute access causing segfault in certain cases

Initial Comment:
Reproduce:

 zopectl debug (done in zope debugger to get necessary
imports)
 >>> from AccessControl.tests.testSecurity import
SecurityTests
 >>> SecurityTests.doc_class

Python 2.3.4 crashes silently. Python 2.3.3 works
normally on the same machine. This is some virtual
server variant of debian gnu/linux on intel
(aktiom.net. On another machine (standard debian i386)
Python 2.3.3 shows the same crash.

That attr in
zope/lib/python/AccessControl/tests/testSecurity.py
looks like:

 class SecurityTests (DTMLTests):
     doc_class = UnownedDTML # another class

Cf http://zwiki.org/IssueNo0860 .

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-14 09:56

Message:
Logged In: YES 
user_id=6656

Uh, there seems little chance this is a Python core bug.  Can we 
close this report?

----------------------------------------------------------------------

Comment By: Andy Dustman (adustman)
Date: 2004-07-13 21:02

Message:
Logged In: YES 
user_id=71372

This may or may not be related: I've had scattered reports
of people having trouble with attribute access (maybe) with
MySQLdb-1.0.0 on Python-2.3.4 (and maybe 2.3.3 but not 2.2)
on *BSD and Mac OS X, but I can't reproduce it on Linux
(x86) with 2.3.4. One person is getting a segfault upon
import (this is not in the bug listed below); I am trying to
get a gdb backtraces.

https://sourceforge.net/tracker/index.php?func=detail&aid=970667&group_id=22307&atid=374932


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-13 20:33

Message:
Logged In: YES 
user_id=572

See also discussion at http://collector.zope.org/Zope/1395

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 21:21

Message:
Logged In: YES 
user_id=4771

What I mean here is that you should report this bug to Zope, not to Python, unless there is a good reason to suspect that a bug in the Python core is causing it.  But to me it really looks like a bug in the Zope extension module, which for some reason shows up only with some version of Python or on some platform.

----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 20:25

Message:
Logged In: YES 
user_id=572

UnownedDTML is indeed a zope extension class.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-07-01 16:20

Message:
Logged In: YES 
user_id=4771

If this bug involves C extension modules specific to Zope
then I'd first consider it as a bug in one of these modules.
 I would be particularly suspicious that this is the case in
a file called testSecurity: isn't its goal to check some
C-implemented security feature of Zope?

If I am wrong please try to provide a Python code sample. 
Reading a class attribute out of some class tends to work
just fine.

----------------------------------------------------------------------

Comment By: Andreas Jung (ajung)
Date: 2004-07-01 11:34

Message:
Logged In: YES 
user_id=11084

Works for me with Python 2.3.3/4 on three different Linux
systems.


----------------------------------------------------------------------

Comment By: Simon Michael (simon)
Date: 2004-07-01 10:52

Message:
Logged In: YES 
user_id=572

> Python 2.3.3 works normally on the same machine.

I meant:  Python 2.3.3 works normally on another, similar
machine (virtual linux host).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=983311&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 11:05:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 11:05:05 2004
Subject: [ python-Bugs-990743 ] Crash when importing encoded file
Message-ID: <E1BkfhE-00005A-00@sc8-sf-web3.sourceforge.net>

Bugs item #990743, was opened at 2004-07-14 09:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990743&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Crash when importing encoded file

Initial Comment:
Python crashes (!) when it meets a non-ascii character in a file with 
encoding in use.

For example:
<file foo.py>
# encoding: mac-roman

...

<square root character>


<in Python>
>>> import user #so we can import 
>>> import foo
Parser/tokenizer.c:366: failed assertion `strlen(str) < (size_t)size'
Abort

When debugging, I found the StreamReader.readline() routine in 
codecs.py. It self.calls decode, which does return well; then readline 
returns, and then the inevitable happens.
Readline is called straight from the toplevel (from the viewpoint of 
the debugger), which probably means calling readline is part of the 
import logic in C.
So the bug must somewhere in there...
- Jurjen

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990743&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 11:18:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 11:19:02 2004
Subject: [ python-Bugs-990749 ] os constants missing
Message-ID: <E1Bkful-0007i6-00@sc8-sf-web2.sourceforge.net>

Bugs item #990749, was opened at 2004-07-14 09:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990749&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: os constants missing

Initial Comment:

Some constants are missing from the os module on Windows.

http://docs.python.org/lib/os-fd-ops.html falsely
claims that the following O_ constants are present on
Windows:

os.O_NDELAY
os.O_NONBLOCK
os.O_DSYNC
os.O_RSYNC
os.O_SYNC
os.O_NOCTTY

None of these constants are defined in module os on
Windows.

These constants allow file locking (via os.open). 
Currently, there is no cross platform way to lock a
file in Python.

I originally became interested in these constants
because of the following quote from module fcntl:

"The os.open function supports locking flags and is
available on a wider variety of platforms than the
fcntl.lockf and fcntl.flock functions, providing a more
platform-independent file locking facility."


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990749&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 12:59:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 12:59:08 2004
Subject: [ python-Bugs-988300 ] Compiler warnings for
	Modules/readline.c:flex_complete()
Message-ID: <E1BkhTd-0007Il-00@sc8-sf-web1.sourceforge.net>

Bugs item #988300, was opened at 2004-07-10 00:53
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Michael Hudson (mwh)
Summary: Compiler warnings for Modules/readline.c:flex_complete()

Initial Comment:
When I compile on my OS X 10.3.4 with Fink's readline 4.3-25 I get 
the following two warnings:

/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: implicit declaration of function `completion_matches'
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: return makes pointer from integer without a cast

Now, although I have a version greater than 4.2, this only makes 
sense if HAVE_RL_COMPLETION_MATCHES is undefined and thus 
the completion_matches() macro is not being defined (although I 
checked and the headers have a prototype for 
rl_completion_matches() and my readline seems to compile and 
work well enough).

Would a #else statement that defines completion_matches() fit in 
there?  Problem would be the return type for flex_complete() 
might need to be covered as well unless a clever macro can be 
created that returns a char **.

Initially assigned to Michael since he seems to always deal with the 
readline stuff.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-14 11:59

Message:
Logged In: YES 
user_id=6656

Hmm.  Does running 

LDFLAGS=-L/sw/lib ./configure

acheive anything interesting?

Speaking for myself, I'd prefer it if python's build process ignored 
/sw/ entirely by default...

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 20:31

Message:
Logged In: YES 
user_id=357491

Sounds like the right solution.  But unfortunately I don't know how to 
implement the fix either.  Ask on python-dev?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 19:56

Message:
Logged In: YES 
user_id=6656

So I'm guessing that the answer to this is to teach the
configure test to look in /sw/lib, then.  Not sure how to do
that...

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 19:46

Message:
Logged In: YES 
user_id=357491

> Oh, er, "good".

If I was wrong to assign it to you feel free to unassign it.

I don't know when it was introduced; it might be old.  I just decided to go 
through my make output and look for any warnings before a1 when out 
the door.  I tend to compile with ``--without-toolbox-glue`` and that 
leads to a ton of output from modules wanting Carbon stuff and throwing 
a fit that they can't link so it just didn't catch my eye.

As for RL_COMPLETION_MATCHES, pyconfig.h has it commented out and 
config.log has test code fail at compilation because it can't find code for 
-lreadline::

configure:17625: checking for rl_completion_matches in -lreadline
configure:17656: gcc -o conftest -g -O2   conftest.c -lreadline -ltermcap 
-ldl  >        &5
ld: can't locate file for: -lreadline

so I end up with::

``ac_cv_lib_readline_rl_completion_matches=no``.

in config.log .

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 13:23

Message:
Logged In: YES 
user_id=6656

> Initially assigned to Michael since he seems to always 
> deal with the readline stuff.

Oh, er, "good".

I'm a little confused.  Is this a new thing?  As in, introduced by my 
changes just before 2.4a1?  *Why* is 
HAVE_RL_COMPLETION_MATCHES undefined?  What do config.log 
and pyconfig.h have to say on the matter?

> Would a #else statement that defines completion_matches()
> fit in there?

Not unless we can work out why it's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 13:00:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 13:00:48 2004
Subject: [ python-Bugs-986528 ] bsddb/weakref error
Message-ID: <E1BkhVD-0007Ma-00@sc8-sf-web1.sourceforge.net>

Bugs item #986528, was opened at 2004-07-07 12:51
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bsddb/weakref error

Initial Comment:
After a cvs up and reinstall of Python, Spambayes is giving 
me this traceback:

Traceback (most recent call last):
  File "/Users/skip/local/bin/sb_filter.py", line 257, in ?
    main()
  File "/Users/skip/local/bin/sb_filter.py", line 248, in main
    action(msg)
  File "/Users/skip/local/bin/sb_filter.py", line 192, in 
train_spam
    self.open('c')
  File "/Users/skip/local/bin/sb_filter.py", line 163, in open
    self.h = hammie.open(self.dbname, self.usedb, 
self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/hammie.py", line 275, in open
    return Hammie(storage.open_storage(filename, useDB, 
mode))
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 679, in open_storage
    return klass(data_source_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 164, in __init__
    self.load()
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 189, in load
    self.dbm = dbmstorage.open(self.db_name, self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 65, in open
    return f(db_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 19, in open_dbhash
    import bsddb
  File "/Users/skip/local/lib/python2.4/bsddb/__init__.py", 
line 68, in ?
    exec """
  File "<string>", line 3, in ?
  File "/Users/skip/local/lib/python2.4/weakref.py", line 152, 
in ?
    class KeyedRef(ref):
TypeError: cannot create 'builtin_function_or_method' 
instances

I don't know what it means, but it wasn't happening before 
the cvs up.  I suspect something changed in the bsddb3 
stuff, so I'm provisionally giving it to Greg.



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-14 12:00

Message:
Logged In: YES 
user_id=6656

Have we worked out how Skip has hosed his install yet <wink>?  
IOW, if there's no evidence of a Python bug (and IMO there isn't) 
we should close this.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-09 16:12

Message:
Logged In: YES 
user_id=3066

What version of Spambayes are you using?

Is there a Spambayes test suite I can run with a given
Python, without screwing with my own Spambayes installation?
 I don't know anything about Spambayes development.

Is this running on Mac OS X of some flavor?  (Guessing from
the weird /Users directory.)

mwh's comment is right on target; something fishy is going
on here.  It looks like you're getting the CVS version of
weakref.py, but you _weakref.so is out of date.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 15:31

Message:
Logged In: YES 
user_id=44345

Yes.  My sandbox has no tags.  I generally just blindly do a
"cvs up ; configure ; make install" and start using the
result as my day-to-day Python interpreter.

I just reverted Fred's changes from July 2 to the relevant
.c, .py and .h files in my sandbox and confirmed that the
traceback disappeared.

Maybe there's nothing wrong with what Fred checked in, but
that it had an unintended effect on the bsddb package, and
that's where the problem needs to be resolved.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-09 15:14

Message:
Logged In: YES 
user_id=6656

Are you sure your build is completely up to date?  For
whatever reason, it looks like _weakref.ref in the traceback
above is a 'builtin_function_or_method', not a 'type' which
is what Fred's checkins turned it into.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 15:08

Message:
Logged In: YES 
user_id=44345

Further inspection of recent python-checkins activity shows
a large change to the weakref stuff by Fred on July 2nd
(more recent than Greg's change to bsddb on June 28th), so
reassigning to him in case it's a weakref problem.
I've been so-far unable to back out the change in my
repository (subsequent changes to some of the files make
that difficult), so I can't verify the weakref changes are
the root of my problems, but they seem pretty wide-ranging,
so that's my guess.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 13:06:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 13:06:57 2004
Subject: [ python-Bugs-990792 ] sre.sub documentation is incomplete
Message-ID: <E1BkhbC-0004es-00@sc8-sf-web4.sourceforge.net>

Bugs item #990792, was opened at 2004-07-14 13:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990792&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Laurent Pinchart (peter_pan78)
Assigned to: Nobody/Anonymous (nobody)
Summary: sre.sub documentation is incomplete

Initial Comment:
The sre.sub code documentation, as returned by help(sre.sub), is 
incomplete as it doesn't document the second form of the function 
which takes a callback function as the first argument. The 
documentation should be updated to at least state that the reader 
should refer to the official Python library documentation. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990792&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 13:11:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 13:11:36 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1Bkhff-0003n3-00@sc8-sf-web2.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 21:19
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (shredwheat)
Assigned to: Michael Hudson (mwh)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-14 12:11

Message:
Logged In: YES 
user_id=6656

Looks OK, I'll probably check it in (with slightly rearranged 
comments) after make test finishes.

Is this testable?  Maybe in testcapimodule. Maybe it's not worth it.

----------------------------------------------------------------------

Comment By: Pete Shinners (shredwheat)
Date: 2004-07-13 21:59

Message:
Logged In: YES 
user_id=1076442

Here is patch, please review and let me know if further
revisions are necessary. Not sure if the comment line in
each error case is helpful or a distraction.

Performance difference is negligable for the common
'success' case. If multiple arguments raise exceptions it is
undefined which one is current when the function returns. A
NULL will still be returned if there are any exceptions.

(my first Python patch, exciting)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 18:59

Message:
Logged In: YES 
user_id=80475

Thanks, that will be nice.

Do make a special effort to make sure this has zero
performance impact on the common case.  No sense in mucking
up the works to satisfy a corner case that rarely impacts
real apps.

----------------------------------------------------------------------

Comment By: Pete Shinners (shredwheat)
Date: 2004-07-12 15:29

Message:
Logged In: YES 
user_id=1076442

I will attempt a patch, this does not look difficult. I am
currently trying to get straight CVS Python to run the test
suite, but having difficulty. I will have a patch ready or
more comments otherwise later this week.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 14:36

Message:
Logged In: YES 
user_id=80475

I thought you would have an interest and be in a good
position to know whether and how this should be fixed.  Feel
free to unassign.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 13:30

Message:
Logged In: YES 
user_id=6656

Um.  Any particular reason for assigning to me?  I could probably 
review and apply any patch that appears, but I'm unlikely to get to 
creating one myself...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 13:28:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 13:28:41 2004
Subject: [ python-Bugs-984722 ] Py_BuildValue loses reference counts on error
Message-ID: <E1BkhwA-0004RT-00@sc8-sf-web2.sourceforge.net>

Bugs item #984722, was opened at 2004-07-03 21:19
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Pete Shinners (shredwheat)
Assigned to: Michael Hudson (mwh)
Summary: Py_BuildValue loses reference counts on error

Initial Comment:
Py_BuildValue has the convenient "N" type argument to
take a PyObject* without a reference count. To the
programmer this means your are transferring the object
ownership to the Py_BuildValue function (and the tuple
it creates).

If Py_BuildValue encounters an error processing an
argument it aborts and returns NULL. But the remaining
arguments are ignored. Therefore objects are leaked
from a leftover reference count.

>From looking at the code in Python/modsupport.c it
looks like a reasonable solution would be to insert a
Py_None into the tuple/list/dict being created and
internally set some sort of error flag. When the
function is returning it would check the error flag and
if set, Py_DECREF the created object and return NULL.

At first this may seem like a lot of work to do when we
already know the function will fail. But it is no more
work than we would be doing when the function succeeeds.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-14 12:28

Message:
Logged In: YES 
user_id=6656

Checked in as 

Python/modsupport.c revision 2.71

Thanks!

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-14 12:11

Message:
Logged In: YES 
user_id=6656

Looks OK, I'll probably check it in (with slightly rearranged 
comments) after make test finishes.

Is this testable?  Maybe in testcapimodule. Maybe it's not worth it.

----------------------------------------------------------------------

Comment By: Pete Shinners (shredwheat)
Date: 2004-07-13 21:59

Message:
Logged In: YES 
user_id=1076442

Here is patch, please review and let me know if further
revisions are necessary. Not sure if the comment line in
each error case is helpful or a distraction.

Performance difference is negligable for the common
'success' case. If multiple arguments raise exceptions it is
undefined which one is current when the function returns. A
NULL will still be returned if there are any exceptions.

(my first Python patch, exciting)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 18:59

Message:
Logged In: YES 
user_id=80475

Thanks, that will be nice.

Do make a special effort to make sure this has zero
performance impact on the common case.  No sense in mucking
up the works to satisfy a corner case that rarely impacts
real apps.

----------------------------------------------------------------------

Comment By: Pete Shinners (shredwheat)
Date: 2004-07-12 15:29

Message:
Logged In: YES 
user_id=1076442

I will attempt a patch, this does not look difficult. I am
currently trying to get straight CVS Python to run the test
suite, but having difficulty. I will have a patch ready or
more comments otherwise later this week.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-12 14:36

Message:
Logged In: YES 
user_id=80475

I thought you would have an interest and be in a good
position to know whether and how this should be fixed.  Feel
free to unassign.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 13:30

Message:
Logged In: YES 
user_id=6656

Um.  Any particular reason for assigning to me?  I could probably 
review and apply any patch that appears, but I'm unlikely to get to 
creating one myself...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984722&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 15:02:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 15:03:22 2004
Subject: [ python-Bugs-986528 ] bsddb/weakref error
Message-ID: <E1BkjOk-0003qf-00@sc8-sf-web1.sourceforge.net>

Bugs item #986528, was opened at 2004-07-07 06:51
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bsddb/weakref error

Initial Comment:
After a cvs up and reinstall of Python, Spambayes is giving 
me this traceback:

Traceback (most recent call last):
  File "/Users/skip/local/bin/sb_filter.py", line 257, in ?
    main()
  File "/Users/skip/local/bin/sb_filter.py", line 248, in main
    action(msg)
  File "/Users/skip/local/bin/sb_filter.py", line 192, in 
train_spam
    self.open('c')
  File "/Users/skip/local/bin/sb_filter.py", line 163, in open
    self.h = hammie.open(self.dbname, self.usedb, 
self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/hammie.py", line 275, in open
    return Hammie(storage.open_storage(filename, useDB, 
mode))
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 679, in open_storage
    return klass(data_source_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 164, in __init__
    self.load()
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/storage.py", line 189, in load
    self.dbm = dbmstorage.open(self.db_name, self.mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 65, in open
    return f(db_name, mode)
  File "/Users/skip/local/lib/python2.4/site-packages/
spambayes/dbmstorage.py", line 19, in open_dbhash
    import bsddb
  File "/Users/skip/local/lib/python2.4/bsddb/__init__.py", 
line 68, in ?
    exec """
  File "<string>", line 3, in ?
  File "/Users/skip/local/lib/python2.4/weakref.py", line 152, 
in ?
    class KeyedRef(ref):
TypeError: cannot create 'builtin_function_or_method' 
instances

I don't know what it means, but it wasn't happening before 
the cvs up.  I suspect something changed in the bsddb3 
stuff, so I'm provisionally giving it to Greg.



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-14 08:02

Message:
Logged In: YES 
user_id=44345

No we haven't. ;-)  The only thing I can think of is I did a
cvs up right when
the changes were going into cvs and thus missed one of the
changed files.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-14 06:00

Message:
Logged In: YES 
user_id=6656

Have we worked out how Skip has hosed his install yet <wink>?  
IOW, if there's no evidence of a Python bug (and IMO there isn't) 
we should close this.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-09 10:12

Message:
Logged In: YES 
user_id=3066

What version of Spambayes are you using?

Is there a Spambayes test suite I can run with a given
Python, without screwing with my own Spambayes installation?
 I don't know anything about Spambayes development.

Is this running on Mac OS X of some flavor?  (Guessing from
the weird /Users directory.)

mwh's comment is right on target; something fishy is going
on here.  It looks like you're getting the CVS version of
weakref.py, but you _weakref.so is out of date.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 09:31

Message:
Logged In: YES 
user_id=44345

Yes.  My sandbox has no tags.  I generally just blindly do a
"cvs up ; configure ; make install" and start using the
result as my day-to-day Python interpreter.

I just reverted Fred's changes from July 2 to the relevant
.c, .py and .h files in my sandbox and confirmed that the
traceback disappeared.

Maybe there's nothing wrong with what Fred checked in, but
that it had an unintended effect on the bsddb package, and
that's where the problem needs to be resolved.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-09 09:14

Message:
Logged In: YES 
user_id=6656

Are you sure your build is completely up to date?  For
whatever reason, it looks like _weakref.ref in the traceback
above is a 'builtin_function_or_method', not a 'type' which
is what Fred's checkins turned it into.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-09 09:08

Message:
Logged In: YES 
user_id=44345

Further inspection of recent python-checkins activity shows
a large change to the weakref stuff by Fred on July 2nd
(more recent than Greg's change to bsddb on June 28th), so
reassigning to him in case it's a weakref problem.
I've been so-far unable to back out the change in my
repository (subsequent changes to some of the files make
that difficult), so I can't verify the weakref changes are
the root of my problems, but they seem pretty wide-ranging,
so that's my guess.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986528&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 16:54:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 16:54:37 2004
Subject: [ python-Bugs-990911 ] Crash from Rapid Clicks
Message-ID: <E1Bkl9V-0004sq-00@sc8-sf-web2.sourceforge.net>

Bugs item #990911, was opened at 2004-07-14 09:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl (thedisciple)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash from Rapid Clicks

Initial Comment:
IDLE crashes when I rapidly (within 1/2 second, maybe) 
click the Run, then Options menus on the menu bar.  
These seem to be the only menus for which the crash 
happens, which is odd.  I'm running Windows XP SP1 on 
an AMD system using Python 2.3.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 17:15:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 17:16:07 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1BklUF-0006l7-00@sc8-sf-web3.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 12:59
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-07-15 00:15

Message:
Logged In: YES 
user_id=55188

Marc-Andre, here's a patch written as you've suggested.
Can you please give a review on this?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-13 04:41

Message:
Logged In: YES 
user_id=38388

Thanks for your descriptions, Hye-Shik.

Since the application space is very much targetted at East
Asian scripts, I would like the implementation to be moved
into unicodedata where all the other special Unicode
features are implemented. The .width() method should be removed.

Now that I understand better what the EAW is about, I would
also like to see the function be renamed to
east_asian_width() since that's what the function is based on.

If possible, I'd also rather like to see the full width
mapping implemented (as defined in the TR). The reduction to
narrow vs. wide seems to be oversimplified. The
east_asian_width() function should return the characters:
"N", "A", "H", "W", "F", "Na" and let the user decide how to
map these to character or string widths. We have followed
the same methodology for the other Unicode database
properties and this has not only given us much more
flexibility, it also is standards compliant and you can get
good documentation on these features.

Matthew, I suggest you write your own implementation of what
you think is right. In the face of ambiguity, there's no
such thing as the right approach to a certain problem.

Thanks.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-13 01:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-13 00:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-13 00:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 23:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 23:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 22:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 18:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 13:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 17:27:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 17:27:47 2004
Subject: [ python-Bugs-990941 ] Uninstall Python shortcut does not work
Message-ID: <E1Bklfa-0007Dn-00@sc8-sf-web3.sourceforge.net>

Bugs item #990941, was opened at 2004-07-14 17:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: Uninstall Python shortcut does not work

Initial Comment:
I get a box 'This action is only valid for products
which are currently installed'.
Uninstalling with Control Panel -> Add/Remove works fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 17:31:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 17:31:33 2004
Subject: [ python-Bugs-968245 ] Python Logging filename & file number 
Message-ID: <E1BkljD-0001nc-00@sc8-sf-web1.sourceforge.net>

Bugs item #968245, was opened at 2004-06-07 10:49
Message generated for change (Comment added) made by superleo303
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan (superleo303)
Assigned to: Vinay Sajip (vsajip)
Summary: Python Logging filename & file number 

Initial Comment:
I use Freebsd and redhat 9.0 linus at work.

Using Python Logging filename & file number on freebsd
works fine.
When i print a log statement, and have my config
formatter section set like:
[formatter_default]
format=%(asctime)s <%(levelname)s>
<%(module)s:%(lineno)s> %(message)s
datefmt=

On bsd my logs look like:
<INFO> <propmancmd:95> stateOnly is: DE
<INFO> <propmancmd:105>  MEssages .........
<INFO> <propmancmd:107> collecting datasource: 1011
<INFO> <propman:98>   Collectors overwrite existing
pickle files: 0
<INFO> <propman:99>           Collectors run in
multiple threads: 4
<DEBUG> <propman:528> sql is:
...

See, the filename and file number get displayed with
each logging call,

Now, The same exact code run on the same exact version
of python on a linux machine yiedls the lines:

<INFO> <__init__:988> stateOnly is: DE
<INFO> <__init__:988>  MEssages
<INFO> <__init__:988> collecting datasource: 1011
<INFO> <__init__:988>   Collectors overwrite existing
pickle files: 0
<INFO> <__init__:988>           Collectors run in
multiple threads: 4
<DEBUG> <__init__:988> sql is: 
...

So i opened up ./python2.3/logging/__init__.py  line
988 and it seems to be where the problem is.

Can someone take a look at this asap?   I have to run
all my code on linux machines, so now i cant see which
file and which line is making the logging.

To reproduce, get a freebsd and linux machine,
then run a simple script that uses logging config files
and use the above example as your formatter in the
logging confrig file,

BSD should show the filenames and numbers, linux should
show __init__ 988 instead.


----------------------------------------------------------------------

>Comment By: Ryan (superleo303)
Date: 2004-07-14 10:31

Message:
Logged In: YES 
user_id=1058618

Hi ,
I have attached a script to reproduce the error, jsut run
./test.py in the folder.

This is what freebsd produces:
$ python ./test.py
2004-07-14 11:29:47,067 <INFO> <test:9> This is a inof call.
2004-07-14 11:29:47,069 <WARNING> <test:10> This is a warn call.
2004-07-14 11:29:47,069 <ERROR> <test:11> This is a error call.

This is what redhat produces:
$ python ./test.py
2004-07-14 11:28:24,812 <INFO> <__init__:988> This is a info
call.
2004-07-14 11:28:24,812 <WARNING> <__init__:988> This is a
warn call.
2004-07-14 11:28:24,812 <ERROR> <__init__:988> This is a
error call.

As you can see, the filename:fileno attributes are different.



----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-12 08:35

Message:
Logged In: YES 
user_id=1058618

Sorry, no , i just have been very busy and havent had time
to reproduce the error, 
i promise by tomorrow ill have a small set of scripts  to
reproduce the error.
All the linux boxes, which is 4 of them, are red hat 9.0, so
maybe its only a problem with red hat?
Ill be posting the scripts tomorrow.
Thanks for checking into this 

-Ryan

ps - i wasnt able to send you an email, it said:

<vsajip@users.sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said:
    550 Administrative prohibition

<vsajip@sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said: 550
    Administrative prohibition


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-05 07:06

Message:
Logged In: YES 
user_id=308438

I'm not able to reproduce these problems under Linux - I only 
have access to Mandrake 10.0 (a Red Hat variant).

Can you upload a script or set of scripts which demonstrates 
the problem?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-06-10 12:18

Message:
Logged In: YES 
user_id=1058618

vsajip, i tested on both machines, both machines returned
the same results:

STACKWALKER RESULTS RUN ON LINUX RED HAT 9.0

[rsmith@marge]:~/ned$ cd bin/testing/stackwalk/
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw1.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw2.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw3.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw4.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python getcaller.py
/home/rsmith/ned/bin/testing/stackwalk/sw1.py(4)
/home/rsmith/ned/bin/testing/stackwalk/sw2.py(5)
/home/rsmith/ned/bin/testing/stackwalk/sw3.py(6)
/home/rsmith/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[rsmith@marge]:~/ned/bin/testing/stackwalk$


-------------------------------------------------------------------------

STACKWALKER RESULTS RUN ON FREEBSD 5.2.1-RELEASE-p8

[ryan@dev2]:~/ned$ cd bin/testing/stackwalk/
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw1.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw2.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw3.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw4.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python getcaller.py
/usr/home/ryan/ned/bin/testing/stackwalk/sw1.py(4)
/usr/home/ryan/ned/bin/testing/stackwalk/sw2.py(5)
/usr/home/ryan/ned/bin/testing/stackwalk/sw3.py(6)
/usr/home/ryan/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[ryan@dev2]:~/ned/bin/testing/stackwalk$

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 04:26

Message:
Logged In: YES 
user_id=308438

The problem appears to be related to some underlying 
problem with sys._getframe(). Can you please download the 
attached stackwalk.tar.gz and run it on both FreeBSD and 
Linux? Please post your findings here, thanks. Note that the 
stackwalk stuff contains no calls to the logging package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 17:32:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 17:32:23 2004
Subject: [ python-Bugs-990945 ] python24.dll installation problems
Message-ID: <E1Bklk3-0001q4-00@sc8-sf-web1.sourceforge.net>

Bugs item #990945, was opened at 2004-07-14 17:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990945&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: python24.dll installation problems

Initial Comment:
It seems that the msi installer does not overwrite an
existing python24.dll in the system directory.
Also, removing the 2.4 installation doesn't seem to
remove the python24.dll from the system directory.

I've seen both in win2k and winXP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990945&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 17:40:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 17:43:31 2004
Subject: [ python-Bugs-968245 ] Python Logging filename & file number 
Message-ID: <E1Bklrk-0007nU-00@sc8-sf-web3.sourceforge.net>

Bugs item #968245, was opened at 2004-06-07 10:49
Message generated for change (Comment added) made by superleo303
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan (superleo303)
Assigned to: Vinay Sajip (vsajip)
Summary: Python Logging filename & file number 

Initial Comment:
I use Freebsd and redhat 9.0 linus at work.

Using Python Logging filename & file number on freebsd
works fine.
When i print a log statement, and have my config
formatter section set like:
[formatter_default]
format=%(asctime)s <%(levelname)s>
<%(module)s:%(lineno)s> %(message)s
datefmt=

On bsd my logs look like:
<INFO> <propmancmd:95> stateOnly is: DE
<INFO> <propmancmd:105>  MEssages .........
<INFO> <propmancmd:107> collecting datasource: 1011
<INFO> <propman:98>   Collectors overwrite existing
pickle files: 0
<INFO> <propman:99>           Collectors run in
multiple threads: 4
<DEBUG> <propman:528> sql is:
...

See, the filename and file number get displayed with
each logging call,

Now, The same exact code run on the same exact version
of python on a linux machine yiedls the lines:

<INFO> <__init__:988> stateOnly is: DE
<INFO> <__init__:988>  MEssages
<INFO> <__init__:988> collecting datasource: 1011
<INFO> <__init__:988>   Collectors overwrite existing
pickle files: 0
<INFO> <__init__:988>           Collectors run in
multiple threads: 4
<DEBUG> <__init__:988> sql is: 
...

So i opened up ./python2.3/logging/__init__.py  line
988 and it seems to be where the problem is.

Can someone take a look at this asap?   I have to run
all my code on linux machines, so now i cant see which
file and which line is making the logging.

To reproduce, get a freebsd and linux machine,
then run a simple script that uses logging config files
and use the above example as your formatter in the
logging confrig file,

BSD should show the filenames and numbers, linux should
show __init__ 988 instead.


----------------------------------------------------------------------

>Comment By: Ryan (superleo303)
Date: 2004-07-14 10:40

Message:
Logged In: YES 
user_id=1058618

Also,
Here are the versions of python i am using

$ python
Python 2.3.3 (#2, Jan 21 2004, 07:27:38)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>>

$ python
Python 2.3.4 (#2, Jul 12 2004, 09:19:42)
[GCC 3.3.3 [FreeBSD] 20031106] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>>

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 10:31

Message:
Logged In: YES 
user_id=1058618

Hi ,
I have attached a script to reproduce the error, jsut run
./test.py in the folder.

This is what freebsd produces:
$ python ./test.py
2004-07-14 11:29:47,067 <INFO> <test:9> This is a inof call.
2004-07-14 11:29:47,069 <WARNING> <test:10> This is a warn call.
2004-07-14 11:29:47,069 <ERROR> <test:11> This is a error call.

This is what redhat produces:
$ python ./test.py
2004-07-14 11:28:24,812 <INFO> <__init__:988> This is a info
call.
2004-07-14 11:28:24,812 <WARNING> <__init__:988> This is a
warn call.
2004-07-14 11:28:24,812 <ERROR> <__init__:988> This is a
error call.

As you can see, the filename:fileno attributes are different.



----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-12 08:35

Message:
Logged In: YES 
user_id=1058618

Sorry, no , i just have been very busy and havent had time
to reproduce the error, 
i promise by tomorrow ill have a small set of scripts  to
reproduce the error.
All the linux boxes, which is 4 of them, are red hat 9.0, so
maybe its only a problem with red hat?
Ill be posting the scripts tomorrow.
Thanks for checking into this 

-Ryan

ps - i wasnt able to send you an email, it said:

<vsajip@users.sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said:
    550 Administrative prohibition

<vsajip@sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said: 550
    Administrative prohibition


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-05 07:06

Message:
Logged In: YES 
user_id=308438

I'm not able to reproduce these problems under Linux - I only 
have access to Mandrake 10.0 (a Red Hat variant).

Can you upload a script or set of scripts which demonstrates 
the problem?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-06-10 12:18

Message:
Logged In: YES 
user_id=1058618

vsajip, i tested on both machines, both machines returned
the same results:

STACKWALKER RESULTS RUN ON LINUX RED HAT 9.0

[rsmith@marge]:~/ned$ cd bin/testing/stackwalk/
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw1.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw2.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw3.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw4.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python getcaller.py
/home/rsmith/ned/bin/testing/stackwalk/sw1.py(4)
/home/rsmith/ned/bin/testing/stackwalk/sw2.py(5)
/home/rsmith/ned/bin/testing/stackwalk/sw3.py(6)
/home/rsmith/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[rsmith@marge]:~/ned/bin/testing/stackwalk$


-------------------------------------------------------------------------

STACKWALKER RESULTS RUN ON FREEBSD 5.2.1-RELEASE-p8

[ryan@dev2]:~/ned$ cd bin/testing/stackwalk/
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw1.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw2.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw3.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw4.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python getcaller.py
/usr/home/ryan/ned/bin/testing/stackwalk/sw1.py(4)
/usr/home/ryan/ned/bin/testing/stackwalk/sw2.py(5)
/usr/home/ryan/ned/bin/testing/stackwalk/sw3.py(6)
/usr/home/ryan/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[ryan@dev2]:~/ned/bin/testing/stackwalk$

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 04:26

Message:
Logged In: YES 
user_id=308438

The problem appears to be related to some underlying 
problem with sys._getframe(). Can you please download the 
attached stackwalk.tar.gz and run it on both FreeBSD and 
Linux? Please post your findings here, thanks. Note that the 
stackwalk stuff contains no calls to the logging package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 17:44:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 17:44:58 2004
Subject: [ python-Bugs-990953 ] 2.4 msi installer installs too many files
Message-ID: <E1BklwD-0007l5-00@sc8-sf-web4.sourceforge.net>

Bugs item #990953, was opened at 2004-07-14 17:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990953&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: 2.4 msi installer installs too many files

Initial Comment:
The msi installer installs the directory
Lib/distutils/test/build and it's subdirs, at least if
they are present on the system where the msi is built.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990953&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 17:47:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 17:47:52 2004
Subject: [ python-Bugs-990954 ] IDLE displays wrong help pages on Windows
Message-ID: <E1Bklz3-0007Ak-00@sc8-sf-web2.sourceforge.net>

Bugs item #990954, was opened at 2004-07-14 17:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990954&group_id=5470

Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE displays wrong help pages on Windows

Initial Comment:
In 2.4a1, installed from the MSI installer, IDLE
doesn't open the CHM file to display the Python help
pages, instead it opens a browser which displays
http://www.python.org/doc/current.

I have no idea if this is related to the MSI installer
or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990954&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 17:59:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 17:59:22 2004
Subject: [ python-Bugs-990941 ] Uninstall Python shortcut does not work
Message-ID: <E1BkmA8-0007fi-00@sc8-sf-web2.sourceforge.net>

Bugs item #990941, was opened at 2004-07-14 11:27
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: Uninstall Python shortcut does not work

Initial Comment:
I get a box 'This action is only valid for products
which are currently installed'.
Uninstalling with Control Panel -> Add/Remove works fine.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-14 11:59

Message:
Logged In: YES 
user_id=31435

Curious!  The Uninstall Start Menu entry for 2.4a1 worked fine 
for me, WinXP Pro.

If it's a "deep" problem, I expect we could just toss the 
Uninstall menu entry -- all versions of Windows I care about 
<wink> have the Add/Remove gimmick, which most Windows 
users expect to use for uninstallation anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 18:04:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 18:04:55 2004
Subject: [ python-Bugs-990911 ] Crash from Rapid Clicks
Message-ID: <E1BkmFU-0000Au-00@sc8-sf-web4.sourceforge.net>

Bugs item #990911, was opened at 2004-07-14 09:54
Message generated for change (Comment added) made by thedisciple
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl (thedisciple)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash from Rapid Clicks

Initial Comment:
IDLE crashes when I rapidly (within 1/2 second, maybe) 
click the Run, then Options menus on the menu bar.  
These seem to be the only menus for which the crash 
happens, which is odd.  I'm running Windows XP SP1 on 
an AMD system using Python 2.3.3

----------------------------------------------------------------------

>Comment By: Karl (thedisciple)
Date: 2004-07-14 11:04

Message:
Logged In: YES 
user_id=1083575

Update:  With a little more expirimentation I found that it often 
crashes whenever any of the last 3 menus (Options, Windows, 
Help) are clicked. It works fine if another menu is clicked then 
the mouse is moved over one of the last three menus to open 
it.  I also noticed that after crashing the program many times 
to determine the problem, I see about twenty pythonw.exe 
processes running in Windows Task Manager.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 20:07:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 20:08:05 2004
Subject: [ python-Bugs-990941 ] Uninstall Python shortcut does not work
Message-ID: <E1BkoAg-0000B8-00@sc8-sf-web1.sourceforge.net>

Bugs item #990941, was opened at 2004-07-14 17:27
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: Uninstall Python shortcut does not work

Initial Comment:
I get a box 'This action is only valid for products
which are currently installed'.
Uninstalling with Control Panel -> Add/Remove works fine.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-14 20:07

Message:
Logged In: YES 
user_id=11105

Hm, it works for Martin's MSI (the one downloaded from
python.org), but not for those created myself from the CVS tree.

Using the menu entry is much faster for people testing the
installers (Add/Remove take a long time to open on my
machine).  Normal users shouldn't uninstall Python anyway ;-)

[5 minutes later]

I guess he has set 'alpha = 0' in the msi.py script he used
to build the installer.  The 'alpha' version seems to use
two conflicting product codes for the MSI: one hardcoded, at
the top of the script, the other created by
msilib.gen_uuid() at line 81.

I'll try it out again, and report back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-14 17:59

Message:
Logged In: YES 
user_id=31435

Curious!  The Uninstall Start Menu entry for 2.4a1 worked fine 
for me, WinXP Pro.

If it's a "deep" problem, I expect we could just toss the 
Uninstall menu entry -- all versions of Windows I care about 
<wink> have the Add/Remove gimmick, which most Windows 
users expect to use for uninstallation anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 20:49:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 20:49:24 2004
Subject: [ python-Bugs-979967 ] gethostbyname is broken on hpux 11.11
Message-ID: <E1Bkooi-0006th-00@sc8-sf-web4.sourceforge.net>

Bugs item #979967, was opened at 2004-06-25 14:50
Message generated for change (Comment added) made by ehab_teima
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979967&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Ehab Teima (ehab_teima)
Assigned to: Nobody/Anonymous (nobody)
Summary: gethostbyname is broken on hpux 11.11

Initial Comment:
This bug exists in Python 2.3.2, 2.3.3 and 2.3.4. 
socket.gethostbyname is broken on hpux HP-UX B.11.11 
U. This is what I'm getting when I try to call 
socket.gethostbyname('server'):

Traceback (most recent call last):
  File "../../test.py", line 2, in ?
    a=socket.gethostbyname('myserver')
socket.gaierror: (8, 'host nor service provided, or not 
known')

I got the same error when I tried getaddrinfo(server, 
port).

----------------------------------------------------------------------

>Comment By: Ehab Teima (ehab_teima)
Date: 2004-07-14 13:49

Message:
Logged In: YES 
user_id=1069522

By looking more into this problem, I found that several 
development groups have reported the exact same problem 
with hpux 11.11. The fix for them was to install DNS patch 
PHNE_27796 along with other patches. However, these patch 
did not fix my problem. As a workaround, I commented out 
HAVE_GETADDRINFO in pyconfig.h. This allowed getaddrinfo 
from python distribution to take place as oppose to the 
broken one from HP. This workaround fixed the problem. I'm 
closing this bug as it's apparently not in python nor python 
can fix it.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-06-27 15:59

Message:
Logged In: YES 
user_id=21627

Can you investigate this in more detail, and suggest a patch?

If not, it is unlikely that it will be fixed anytime soon,
because the bug is likely specific to the operating system,
and might be even specific to your installation.

----------------------------------------------------------------------

Comment By: Ehab Teima (ehab_teima)
Date: 2004-06-25 15:15

Message:
Logged In: YES 
user_id=1069522

The servername is supposed to be resolved via DNS query to 
get thje ip address. If I use the ip address instead of the 
servername, the function works fine [i.e. 
socket.gethostbyname('x.x.x.x') works fine.]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979967&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 21:42:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 21:42:16 2004
Subject: [ python-Bugs-991123 ] staticmethod not in index
Message-ID: <E1Bkpdu-0000WN-00@sc8-sf-web3.sourceforge.net>

Bugs item #991123, was opened at 2004-07-14 14:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991123&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: George Young (georgeryoung)
Assigned to: Nobody/Anonymous (nobody)
Summary: staticmethod not in index

Initial Comment:
The "staticmethod" builtin function does not appear in
the index for the language reference.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991123&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 21:49:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 21:49:45 2004
Subject: [ python-Bugs-991125 ] Make Problem on HPUX
Message-ID: <E1Bkpl8-0004Qf-00@sc8-sf-web1.sourceforge.net>

Bugs item #991125, was opened at 2004-07-14 15:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul D. Lusk (plusk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make Problem on HPUX

Initial Comment:
Build of _socket fails:

In file included from /home/python/Python-
2.4a1/Modules/socketmodule.c:314:
/home/python/Python-2.4a1/Modules/getaddrinfo.c: In 
function `fake_gai_strerror':
/home/python/Python-2.4a1/Modules/getaddrinfo.c:204: 
`EAI_MAX' undeclared (first use in this function)
/home/python/Python-2.4a1/Modules/getaddrinfo.c:204: 
(Each undeclared identifier is reported only once
/home/python/Python-2.4a1/Modules/getaddrinfo.c:204: 
for each function it appears in.)
/home/python/Python-2.4a1/Modules/getaddrinfo.c: In 
function `fake_getaddrinfo':
/home/python/Python-2.4a1/Modules/getaddrinfo.c:282: 
`EAI_BADHINTS' undeclared (first use in this function)
/home/python/Python-2.4a1/Modules/getaddrinfo.c:283: 
`AI_MASK' undeclared (first use in this function)
/home/python/Python-2.4a1/Modules/getaddrinfo.c:373: 
`EAI_PROTOCOL' undeclared (first use in this function)

The problem seems to be that 

#include "addrinfo.h"

is in an #if 0 block in getaddrinfo.c

When that include is moved out of the #if 0
block, the _socket module compiles and 
make test does not show any errors.

System information:

uname -a
HP-UX voyager B.11.11 U 9000/800 3108770354 
unlimited-user license

The above problem occurs with both gcc and with
HP's C compiler.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 21:04:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 22:02:34 2004
Subject: [ python-Bugs-990941 ] Uninstall Python shortcut does not work
Message-ID: <E1Bkp3D-0006v2-00@sc8-sf-web2.sourceforge.net>

Bugs item #990941, was opened at 2004-07-14 17:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: Uninstall Python shortcut does not work

Initial Comment:
I get a box 'This action is only valid for products
which are currently installed'.
Uninstalling with Control Panel -> Add/Remove works fine.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-14 21:04

Message:
Logged In: YES 
user_id=21627

There was a bug in the script that would use different
product codes for an alpha (i.e. the "final" product code)
for uninstall. I have fixed this in my CVS sandbox before
the release of 2.4a0, but not yet committed - will do so
tomorrow.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-14 20:07

Message:
Logged In: YES 
user_id=11105

Hm, it works for Martin's MSI (the one downloaded from
python.org), but not for those created myself from the CVS tree.

Using the menu entry is much faster for people testing the
installers (Add/Remove take a long time to open on my
machine).  Normal users shouldn't uninstall Python anyway ;-)

[5 minutes later]

I guess he has set 'alpha = 0' in the msi.py script he used
to build the installer.  The 'alpha' version seems to use
two conflicting product codes for the MSI: one hardcoded, at
the top of the script, the other created by
msilib.gen_uuid() at line 81.

I'll try it out again, and report back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-14 17:59

Message:
Logged In: YES 
user_id=31435

Curious!  The Uninstall Start Menu entry for 2.4a1 worked fine 
for me, WinXP Pro.

If it's a "deep" problem, I expect we could just toss the 
Uninstall menu entry -- all versions of Windows I care about 
<wink> have the Add/Remove gimmick, which most Windows 
users expect to use for uninstallation anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 23:16:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 23:16:42 2004
Subject: [ python-Bugs-991123 ] staticmethod not in index
Message-ID: <E1Bkr7G-0003dW-00@sc8-sf-web2.sourceforge.net>

Bugs item #991123, was opened at 2004-07-14 14:42
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991123&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: George Young (georgeryoung)
Assigned to: Nobody/Anonymous (nobody)
Summary: staticmethod not in index

Initial Comment:
The "staticmethod" builtin function does not appear in
the index for the language reference.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-14 16:16

Message:
Logged In: YES 
user_id=80475

You'll find it in the index for the Library Reference which
covers all of the built-in functions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991123&group_id=5470
From noreply at sourceforge.net  Wed Jul 14 23:30:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 14 23:30:27 2004
Subject: [ python-Bugs-991196 ] An inconsistency with nested scopes
Message-ID: <E1BkrKa-00085a-00@sc8-sf-web1.sourceforge.net>

Bugs item #991196, was opened at 2004-07-14 16:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991196&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Jacobson (nickjacobson)
Assigned to: Nobody/Anonymous (nobody)
Summary: An inconsistency with nested scopes

Initial Comment:
There's an inconsistency with nested scopes.

>From the Python Ref. Manual:

"If [a local variable] definition occurs in a function block, 
the scope extends to any blocks contained within the 
defining one..."

i.e. So as long as code is not on the module level, 
scopes are extended.  Therefore this works:

def main():
	y = 3
	def execfunc():
		print y
	execfunc()

if __name__ == '__main__':
	main()

In addition, if code IS on the module level, its variables 
go in globals().  So this works too:

y = 3
def execfunc():
	print y
execfunc()

However, (here's the inconsistency) the following code 
fails, saying that y is undefined:

def main():
	s = """
y = 3
def execfunc():
	print y
execfunc()
"""
	d = {}
	e = {}
	exec s in d, e

if __name__ == '__main__':
	main()

In this case, the code in s is treated like it's on the 
module level, and the nested scope treatment of y 
doesn't occur.  BUT, unlike normal code on the module 
level, y doesn't go in globals().  I think globals() is 
locked or something?


Conclusion:

The latter piece of code should work; that is, y should 
be nested and therefore recognized by execfunc().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991196&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 01:50:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 01:50:37 2004
Subject: [ python-Bugs-991258 ] Cookie.py loses 'secure' attribute
Message-ID: <E1BktWE-000053-00@sc8-sf-web2.sourceforge.net>

Bugs item #991258, was opened at 2004-07-15 09:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991258&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cookie.py loses 'secure' attribute

Initial Comment:
SimpleCookie.load() happily parses a string with the 'secure' 
attribute, but loses it

>>> c = SimpleCookie()
>>> c['foo'] = 'bar'
>>> c['foo']['secure'] = True
>>> str(c)
'Set-Cookie: foo=bar; secure;'
>>> c = SimpleCookie(str(c))
>>> str(c)
'Set-Cookie: foo=bar;'
>>> c['foo']['secure']
''



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991258&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 02:17:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 02:17:08 2004
Subject: [ python-Bugs-991266 ] Cookie.py does not correctly quote Morsels
Message-ID: <E1Bktvs-00011D-00@sc8-sf-web3.sourceforge.net>

Bugs item #991266, was opened at 2004-07-15 10:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991266&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cookie.py does not correctly quote Morsels

Initial Comment:
The quoting works fine for cookie values, but doesn't kick in for 
attributes like Comment. 

>>> c = SimpleCookie()
>>> c['foo'] = u'\N{COPYRIGHT SIGN}'.encode('UTF8')
>>> print str(c)
Set-Cookie: foo="\302\251";
>>> c['foo']['comment'] = u'\N{BIOHAZARD SIGN}'.encode('UTF8')
>>> print str(c)
Set-Cookie: foo="\302\251"; Comment=?;
>>> str(c)
'Set-Cookie: foo="\302\251"; Comment=\xe2\x98\xa3;'
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991266&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 03:05:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 03:05:46 2004
Subject: [ python-Bugs-991258 ] Cookie.py loses 'secure' attribute
Message-ID: <E1Bkugq-0006HO-00@sc8-sf-web1.sourceforge.net>

Bugs item #991258, was opened at 2004-07-15 09:50
Message generated for change (Comment added) made by zenzen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991258&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cookie.py loses 'secure' attribute

Initial Comment:
SimpleCookie.load() happily parses a string with the 'secure' 
attribute, but loses it

>>> c = SimpleCookie()
>>> c['foo'] = 'bar'
>>> c['foo']['secure'] = True
>>> str(c)
'Set-Cookie: foo=bar; secure;'
>>> c = SimpleCookie(str(c))
>>> str(c)
'Set-Cookie: foo=bar;'
>>> c['foo']['secure']
''



----------------------------------------------------------------------

>Comment By: Stuart Bishop (zenzen)
Date: 2004-07-15 11:05

Message:
Logged In: YES 
user_id=46639

I think this is my misunderstanding - load() is designed to parse Cookie: 
headers from the client, and 'secure' only ever appears in Set-Cookie: 
headers from the server.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991258&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 03:31:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 03:31:30 2004
Subject: [ python-Bugs-990954 ] IDLE displays wrong help pages on Windows
Message-ID: <E1Bkv5p-0003ED-00@sc8-sf-web3.sourceforge.net>

Bugs item #990954, was opened at 2004-07-14 10:47
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990954&group_id=5470

Category: IDLE
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: Thomas Heller (theller)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE displays wrong help pages on Windows

Initial Comment:
In 2.4a1, installed from the MSI installer, IDLE
doesn't open the CHM file to display the Python help
pages, instead it opens a browser which displays
http://www.python.org/doc/current.

I have no idea if this is related to the MSI installer
or not.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-07-14 20:31

Message:
Logged In: YES 
user_id=149084

If IDLE can't find the .chm files it will use the website.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990954&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 04:28:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 04:28:17 2004
Subject: [ python-Bugs-989273 ] Python-2.4.0a1 test_strptime.py fails on
	HP-UX11i
Message-ID: <E1Bkvyk-0004sZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #989273, was opened at 2004-07-12 01:41
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Brett Cannon (bcannon)
Summary: Python-2.4.0a1 test_strptime.py fails on HP-UX11i

Initial Comment:
Built Python-2.4.0a1 on HP-UX11i and test_strptime.py 
fails.

See attached file test_strptime.txt



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-14 00:18

Message:
Logged In: YES 
user_id=200117

I made the change and the test now runs without errors.

Thanks for fixing this - I'm glad I could help with the testing.




----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-13 17:49

Message:
Logged In: YES 
user_id=357491

OK, so I screwed the patch up by using the line ``tz_name.lower() in 
("UTC", "GMT")``.  Notice how everything is in caps in the tuple but I call 
str.lower()?  Nice way to guarantee that the test is never true.

Sorry about that stupid mistake, Richard.  If you happen to still have the 
last patch applied, either just apply the new patch or fix line 283 yourself 
since it is just a single word change.  That should fix it.  At least my 
blind reasoning over what could be causing the failure was correct.

Thanks for putting up with this.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-13 00:27

Message:
Logged In: YES 
user_id=200117

Brett, test_strptime.py still gives an error after I applied your 
patch - see attached file strptime_err.txt

Here are the variable settings from the time module:
    accept2dyear = 1
    altzone = -3600
    daylight = 0
    timezone = 0
    tzname = ('GMT', '')



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2004-07-12 12:33

Message:
Logged In: YES 
user_id=200117

Hi Brett,

I will test your patch when I return to work tomorrow (UK time).

FYI our HP workstations are set to GMT throughout the year.

regards,
Richard


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 12:16

Message:
Logged In: YES 
user_id=357491

Well, I thought I did.  This little test is slowly turning into my personal 
Python hell for the week.

OK, so I may have a blind fix for this (if time.tzname[0] turns out to be 
UTC or GMT; realized this was a possibility).  And if that doesn't work the 
patch 
I am attaching should give us more information on what the test is 
dealing with.

Richard, can you apply the attached patch and let me know if it fixes 
things for you?  
If not please attach another traceback to the bug report.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 11:55

Message:
Logged In: YES 
user_id=31435

Brett, are you sure we understand this one?  It's the same 
test failing in the same way as I reported on Python-Dev, 
*but* Richard is seeing test_strptime fail in isolation (look at 
his attachment).  The failure I saw was due to interactions 
with test___all__ and test_site too -- test_strptime did not 
fail in isolation for me, but is failing in isolation for Richard.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 11:36

Message:
Logged In: YES 
user_id=357491

Thanks for the bug report, Richard.  We have isolated why the test fails 
(the test is at fault, not the code it is testing) and should have it fixed 
within a day or so.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989273&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 05:33:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 05:33:38 2004
Subject: [ python-Bugs-990941 ] Uninstall Python shortcut does not work
Message-ID: <E1Bkwzy-00060b-00@sc8-sf-web4.sourceforge.net>

Bugs item #990941, was opened at 2004-07-14 11:27
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: Uninstall Python shortcut does not work

Initial Comment:
I get a box 'This action is only valid for products
which are currently installed'.
Uninstalling with Control Panel -> Add/Remove works fine.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-14 23:33

Message:
Logged In: YES 
user_id=31435

Thomas, do yourself a favor and Google on "Raymond Chen 
add remove" -- you'll find an hilarious/depressing weblog 
about *why*add/remove is so slow to come up in modern 
Windows.  Believe it or not, there are impossible-to-fix 
reasons for it!

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-14 15:04

Message:
Logged In: YES 
user_id=21627

There was a bug in the script that would use different
product codes for an alpha (i.e. the "final" product code)
for uninstall. I have fixed this in my CVS sandbox before
the release of 2.4a0, but not yet committed - will do so
tomorrow.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-14 14:07

Message:
Logged In: YES 
user_id=11105

Hm, it works for Martin's MSI (the one downloaded from
python.org), but not for those created myself from the CVS tree.

Using the menu entry is much faster for people testing the
installers (Add/Remove take a long time to open on my
machine).  Normal users shouldn't uninstall Python anyway ;-)

[5 minutes later]

I guess he has set 'alpha = 0' in the msi.py script he used
to build the installer.  The 'alpha' version seems to use
two conflicting product codes for the MSI: one hardcoded, at
the top of the script, the other created by
msilib.gen_uuid() at line 81.

I'll try it out again, and report back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-14 11:59

Message:
Logged In: YES 
user_id=31435

Curious!  The Uninstall Start Menu entry for 2.4a1 worked fine 
for me, WinXP Pro.

If it's a "deep" problem, I expect we could just toss the 
Uninstall menu entry -- all versions of Windows I care about 
<wink> have the Add/Remove gimmick, which most Windows 
users expect to use for uninstallation anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 06:40:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 06:40:17 2004
Subject: [ python-Bugs-870382 ] Mingw needs to use the same MSVC runtime as
	Python
Message-ID: <E1Bky2L-0003oB-00@sc8-sf-web1.sourceforge.net>

Bugs item #870382, was opened at 2004-01-05 03:55
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470

Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: Mingw needs to use the same MSVC runtime as Python

Initial Comment:
Python 2.4 is now built with MSVC 7.1, which uses a 
new MSVC runtime library.

Extension DLLs should be built to use the same runtime 
DLL as Python itself (although it has not been possible 
to find a real-world example where not doing so causes 
a problem...)

The attached patch adds the appropriate -l flag to the 
link, based on the MSVC version reported in sys.version. 
(This has only been tested with a Python built with 
MSVC 7.1, the version number used for MSVC 7.0 is 
based on verbal reports only).

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-07-15 16:40

Message:
Logged In: YES 
user_id=552329

FWIW, this patch works for me, and I'd definitely like to
see it in 2.4a2.  If the MSVC version isn't 1300 or 1310
(the theoretical 1400, for example), then it doesn't do
anything different to what 2.4a1 does, so it's hard to see
why that would be a problem (and with the patch applied,
there's a clear fix, just adding in the appropriate elif and
link - it's not like new versions come along all the time).

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-09 23:17

Message:
Logged In: YES 
user_id=113328

This is still an issue with 2.4a1. I'm not sure what the 
autodetection buys given that currently it's not possible to 
build extensions with 2.4a1 using mingw which are compatible 
with the stock python.org binary.

Can I suggest that this patch be applied, and issues around 
autodetection be deferred until there is a demonstrated need?

I've uploaded a revised patch for 2.4a1 (tested against the 
python.org supplied MSI).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-06 10:30

Message:
Logged In: YES 
user_id=21627

I'm primarily concerned about future
(unreleased-as-of-today) MSC versions; they likely have
version numbers like "1400"; linking msvcr71 to binaries
built with that compiler is likely wrong.

Not adding anything for gcc-built python versions is fine.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-05 12:01

Message:
Logged In: YES 
user_id=113328

What about Python built with mingw? I don't think that's 
possible right now, but I'd expect people to work on it. And 
I've no idea what sys.version for that would be.

The only real cases are likely to be MSVC 7.1 (Python 2.4, 
binary dist), MSVC 6 (Python <= 2.3, binary dist) and hand-
built Python versions. The patch does the right thing for all 
the binary distributions, which are the ones where the user 
can't be assumed to know how to hack things to make them 
work.

For hand-built versions, the user can do "python setup.py 
build_ext --compiler=mingw32 -l msvcr71" (or whatever) to 
manually specify the runtime to use. Leaving the default as 
msvcrt (the CRT that comes with the OS, and is default for 
mingw) seems right - and better than aborting (particularly as 
I'm not sure how to check whether there's an -l option for 
the CRT specified by the user).

The best I could do is effectively to force build_ext to fail 
unless Python was built with MSVC, which seems unhelpful...

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-05 04:03

Message:
Logged In: YES 
user_id=21627

Could you add some kind of assertion to detect the case that
an entirely different compiler version is used? It would be
best if it gets the case of using MSVC6 right, and gives up
if some other compiler version is detected (I can't
determine os.version for the VC6 case right now, but Python
2.3 is built with it).

Apart from that, the patch looks good.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 07:01:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 07:01:38 2004
Subject: [ python-Bugs-900580 ] IDLE docs broken on OSX
Message-ID: <E1BkyND-0008EM-00@sc8-sf-web2.sourceforge.net>

Bugs item #900580, was opened at 2004-02-19 14:59
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900580&group_id=5470

Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jonathan Brandmeyer (jbrandmeyer)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE docs broken on OSX

Initial Comment:
Under Apple's OSX operating system, the variable
sys.platform is named'darwin'.  In at least one place,
idle makes a test to see if thecurrent platform is MS
Windows by checking for the substring 'win'
insys.platform, which leads to incorrect behavior on
the Mac.

In particular, in
lib/python2.3/idlelib/EditorWindow.py, member function
EditorWindow.python_docs() behaves incorrectly on OS X.
 I believe that if the test for MS Windows is
completely removed that you will get correct behavior
on all platforms, based on my reading of the webbrowser
module source.

Please change that function to the following (near line
313):    

>>>    def python_docs(self, event=None):
>>>        webbrowser.open(self.help_url)
>>>        return "break"


----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-07-15 00:01

Message:
Logged In: YES 
user_id=149084

EditorWindow.py 1.60
configHelpSourceEdit.py 1.7
Backport candidate.

Please test on Mac.

----------------------------------------------------------------------

Comment By: Jonathan Brandmeyer (jbrandmeyer)
Date: 2004-03-02 14:06

Message:
Logged In: YES 
user_id=676765

There are a series of changes related to the one I mentioned
before.  In addition, Safari requires the full URI to local
files when started via the webbrowser module (or via several
other methods) even though it automatically prepends that
string when entered in the address bar.  So, I have an
additional patch that makes appropriate modifications for
file:/// prefixed paths.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900580&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 07:38:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 07:39:08 2004
Subject: [ python-Bugs-990749 ] os constants missing
Message-ID: <E1BkyxP-0001Dm-00@sc8-sf-web3.sourceforge.net>

Bugs item #990749, was opened at 2004-07-14 05:18
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990749&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: os constants missing

Initial Comment:

Some constants are missing from the os module on Windows.

http://docs.python.org/lib/os-fd-ops.html falsely
claims that the following O_ constants are present on
Windows:

os.O_NDELAY
os.O_NONBLOCK
os.O_DSYNC
os.O_RSYNC
os.O_SYNC
os.O_NOCTTY

None of these constants are defined in module os on
Windows.

These constants allow file locking (via os.open). 
Currently, there is no cross platform way to lock a
file in Python.

I originally became interested in these constants
because of the following quote from module fcntl:

"The os.open function supports locking flags and is
available on a wider variety of platforms than the
fcntl.lockf and fcntl.flock functions, providing a more
platform-independent file locking facility."


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-15 01:38

Message:
Logged In: YES 
user_id=31435

Weird -- a *comment* in the LaTeX source already notes 
that those 6 constants aren't supported on Windows.  Heh.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 01:35

Message:
Logged In: YES 
user_id=31435

Changed category to Documentation, since this is a doc bug.  
The O_XXX constants listed here aren't available on Windows 
because Windows itself doesn't support them (and never 
will), so that part of the docs should change.

That doesn't change that these constants may be more 
portable than fcntl gimmicks (are they?  don't know).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990749&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 07:35:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 07:39:34 2004
Subject: [ python-Bugs-990749 ] os constants missing
Message-ID: <E1BkyuT-00017s-00@sc8-sf-web3.sourceforge.net>

Bugs item #990749, was opened at 2004-07-14 05:18
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990749&group_id=5470

>Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: os constants missing

Initial Comment:

Some constants are missing from the os module on Windows.

http://docs.python.org/lib/os-fd-ops.html falsely
claims that the following O_ constants are present on
Windows:

os.O_NDELAY
os.O_NONBLOCK
os.O_DSYNC
os.O_RSYNC
os.O_SYNC
os.O_NOCTTY

None of these constants are defined in module os on
Windows.

These constants allow file locking (via os.open). 
Currently, there is no cross platform way to lock a
file in Python.

I originally became interested in these constants
because of the following quote from module fcntl:

"The os.open function supports locking flags and is
available on a wider variety of platforms than the
fcntl.lockf and fcntl.flock functions, providing a more
platform-independent file locking facility."


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-15 01:35

Message:
Logged In: YES 
user_id=31435

Changed category to Documentation, since this is a doc bug.  
The O_XXX constants listed here aren't available on Windows 
because Windows itself doesn't support them (and never 
will), so that part of the docs should change.

That doesn't change that these constants may be more 
portable than fcntl gimmicks (are they?  don't know).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990749&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 07:49:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 07:49:17 2004
Subject: [ python-Bugs-990749 ] os constants missing
Message-ID: <E1Bkz7I-00017F-00@sc8-sf-web2.sourceforge.net>

Bugs item #990749, was opened at 2004-07-14 05:18
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990749&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: os constants missing

Initial Comment:

Some constants are missing from the os module on Windows.

http://docs.python.org/lib/os-fd-ops.html falsely
claims that the following O_ constants are present on
Windows:

os.O_NDELAY
os.O_NONBLOCK
os.O_DSYNC
os.O_RSYNC
os.O_SYNC
os.O_NOCTTY

None of these constants are defined in module os on
Windows.

These constants allow file locking (via os.open). 
Currently, there is no cross platform way to lock a
file in Python.

I originally became interested in these constants
because of the following quote from module fcntl:

"The os.open function supports locking flags and is
available on a wider variety of platforms than the
fcntl.lockf and fcntl.flock functions, providing a more
platform-independent file locking facility."


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-15 01:49

Message:
Logged In: YES 
user_id=31435

Split the 6 non-Windows os.O_XXX constants into a different 
table, and removed the LaTeX comment, in Doc/lib/libos.tex 
rev 1.138.

Leaving this open for someone to investigate the doc's claim 
that these things are more portable than the fcntl gimmicks 
(offhand, doesn't seem likely to me).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 01:38

Message:
Logged In: YES 
user_id=31435

Weird -- a *comment* in the LaTeX source already notes 
that those 6 constants aren't supported on Windows.  Heh.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 01:35

Message:
Logged In: YES 
user_id=31435

Changed category to Documentation, since this is a doc bug.  
The O_XXX constants listed here aren't available on Windows 
because Windows itself doesn't support them (and never 
will), so that part of the docs should change.

That doesn't change that these constants may be more 
portable than fcntl gimmicks (are they?  don't know).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990749&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 08:35:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 08:35:07 2004
Subject: [ python-Bugs-933068 ] Different behaviour using super() and
	explicit base class.
Message-ID: <E1Bkzpf-0002bU-00@sc8-sf-web2.sourceforge.net>

Bugs item #933068, was opened at 2004-04-11 05:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933068&group_id=5470

Category: Threads
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Lawrence Allan Jones (lajones)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different behaviour using super() and explicit base class.

Initial Comment:
I created a child class of threading.Thread. To invoke 
the parent __init__ method, I called super(C, 
self).__init__().

When called at run-time, Python threw an assertion 
exception informing me that the group parameter must 
be None. (The detailed error message was assert group 
is None, "group argument must be None for now".) I had 
not changed this parameter.

I created a similar class and explicitly called 
threading.Thread.__init__(). This call did not exhibit the 
fault at run-time.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 08:35

Message:
Logged In: YES 
user_id=21627

The analysis is correct. This is not a bug in Python;
closing the report.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-05-10 11:52

Message:
Logged In: YES 
user_id=1038590

This looks like a usage problem to me - the call to 
super() returns an already bound method object, hence 
'self' does not need to be supplied as an argument to the 
__init__ call. 
 
That is, the correct call to fix the 'Broken' class is: 
 
super(Broken, self).__init__() 
 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933068&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 09:00:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 09:00:45 2004
Subject: [ python-Bugs-968245 ] Python Logging filename & file number 
Message-ID: <E1Bl0ES-0003W5-00@sc8-sf-web2.sourceforge.net>

Bugs item #968245, was opened at 2004-06-07 15:49
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Ryan (superleo303)
Assigned to: Vinay Sajip (vsajip)
Summary: Python Logging filename & file number 

Initial Comment:
I use Freebsd and redhat 9.0 linus at work.

Using Python Logging filename & file number on freebsd
works fine.
When i print a log statement, and have my config
formatter section set like:
[formatter_default]
format=%(asctime)s <%(levelname)s>
<%(module)s:%(lineno)s> %(message)s
datefmt=

On bsd my logs look like:
<INFO> <propmancmd:95> stateOnly is: DE
<INFO> <propmancmd:105>  MEssages .........
<INFO> <propmancmd:107> collecting datasource: 1011
<INFO> <propman:98>   Collectors overwrite existing
pickle files: 0
<INFO> <propman:99>           Collectors run in
multiple threads: 4
<DEBUG> <propman:528> sql is:
...

See, the filename and file number get displayed with
each logging call,

Now, The same exact code run on the same exact version
of python on a linux machine yiedls the lines:

<INFO> <__init__:988> stateOnly is: DE
<INFO> <__init__:988>  MEssages
<INFO> <__init__:988> collecting datasource: 1011
<INFO> <__init__:988>   Collectors overwrite existing
pickle files: 0
<INFO> <__init__:988>           Collectors run in
multiple threads: 4
<DEBUG> <__init__:988> sql is: 
...

So i opened up ./python2.3/logging/__init__.py  line
988 and it seems to be where the problem is.

Can someone take a look at this asap?   I have to run
all my code on linux machines, so now i cant see which
file and which line is making the logging.

To reproduce, get a freebsd and linux machine,
then run a simple script that uses logging config files
and use the above example as your formatter in the
logging confrig file,

BSD should show the filenames and numbers, linux should
show __init__ 988 instead.


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-15 07:00

Message:
Logged In: YES 
user_id=308438

I tried this on Mandrake Linux 10 (it's a Red Hat variant) 
which has Python 2.3.3, with the expected result:

2004-07-15 07:45:58,258 <INFO> <test:9> This is a inof call.
2004-07-15 07:45:58,282 <WARNING> <test:10> This is a 
warn call.
2004-07-15 07:45:58,282 <ERROR> <test:11> This is a error 
call.

Might there be a problem with your Red Hat or Python 
installation? Have you tried it on several Red Hat boxes?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 15:40

Message:
Logged In: YES 
user_id=1058618

Also,
Here are the versions of python i am using

$ python
Python 2.3.3 (#2, Jan 21 2004, 07:27:38)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>>

$ python
Python 2.3.4 (#2, Jul 12 2004, 09:19:42)
[GCC 3.3.3 [FreeBSD] 20031106] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>>

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 15:31

Message:
Logged In: YES 
user_id=1058618

Hi ,
I have attached a script to reproduce the error, jsut run
./test.py in the folder.

This is what freebsd produces:
$ python ./test.py
2004-07-14 11:29:47,067 <INFO> <test:9> This is a inof call.
2004-07-14 11:29:47,069 <WARNING> <test:10> This is a warn call.
2004-07-14 11:29:47,069 <ERROR> <test:11> This is a error call.

This is what redhat produces:
$ python ./test.py
2004-07-14 11:28:24,812 <INFO> <__init__:988> This is a info
call.
2004-07-14 11:28:24,812 <WARNING> <__init__:988> This is a
warn call.
2004-07-14 11:28:24,812 <ERROR> <__init__:988> This is a
error call.

As you can see, the filename:fileno attributes are different.



----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-12 13:35

Message:
Logged In: YES 
user_id=1058618

Sorry, no , i just have been very busy and havent had time
to reproduce the error, 
i promise by tomorrow ill have a small set of scripts  to
reproduce the error.
All the linux boxes, which is 4 of them, are red hat 9.0, so
maybe its only a problem with red hat?
Ill be posting the scripts tomorrow.
Thanks for checking into this 

-Ryan

ps - i wasnt able to send you an email, it said:

<vsajip@users.sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said:
    550 Administrative prohibition

<vsajip@sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said: 550
    Administrative prohibition


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-05 12:06

Message:
Logged In: YES 
user_id=308438

I'm not able to reproduce these problems under Linux - I only 
have access to Mandrake 10.0 (a Red Hat variant).

Can you upload a script or set of scripts which demonstrates 
the problem?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-06-10 17:18

Message:
Logged In: YES 
user_id=1058618

vsajip, i tested on both machines, both machines returned
the same results:

STACKWALKER RESULTS RUN ON LINUX RED HAT 9.0

[rsmith@marge]:~/ned$ cd bin/testing/stackwalk/
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw1.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw2.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw3.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw4.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python getcaller.py
/home/rsmith/ned/bin/testing/stackwalk/sw1.py(4)
/home/rsmith/ned/bin/testing/stackwalk/sw2.py(5)
/home/rsmith/ned/bin/testing/stackwalk/sw3.py(6)
/home/rsmith/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[rsmith@marge]:~/ned/bin/testing/stackwalk$


-------------------------------------------------------------------------

STACKWALKER RESULTS RUN ON FREEBSD 5.2.1-RELEASE-p8

[ryan@dev2]:~/ned$ cd bin/testing/stackwalk/
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw1.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw2.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw3.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw4.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python getcaller.py
/usr/home/ryan/ned/bin/testing/stackwalk/sw1.py(4)
/usr/home/ryan/ned/bin/testing/stackwalk/sw2.py(5)
/usr/home/ryan/ned/bin/testing/stackwalk/sw3.py(6)
/usr/home/ryan/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[ryan@dev2]:~/ned/bin/testing/stackwalk$

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 09:26

Message:
Logged In: YES 
user_id=308438

The problem appears to be related to some underlying 
problem with sys._getframe(). Can you please download the 
attached stackwalk.tar.gz and run it on both FreeBSD and 
Linux? Please post your findings here, thanks. Note that the 
stackwalk stuff contains no calls to the logging package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 11:39:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 11:39:54 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bl2iU-0005i6-00@sc8-sf-web1.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 11:39

Message:
Logged In: YES 
user_id=38388

Hye-Shik, the patch only includes the move to unicodedata, but
not the full implementation of the EAW as per the TR. I would
much prefer to have the east_asian_width() function return
the strings defined in the TR because this allows users of the
function to read the information and implement their own 
interpretation of "width".

The new function should work very much like 
unicodedata.category().

It would also be wise to move the data itself over to the
unicode
database - that way the extra data does not affect Python
programs that don't use the function.

Thanks.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-14 17:15

Message:
Logged In: YES 
user_id=55188

Marc-Andre, here's a patch written as you've suggested.
Can you please give a review on this?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 21:41

Message:
Logged In: YES 
user_id=38388

Thanks for your descriptions, Hye-Shik.

Since the application space is very much targetted at East
Asian scripts, I would like the implementation to be moved
into unicodedata where all the other special Unicode
features are implemented. The .width() method should be removed.

Now that I understand better what the EAW is about, I would
also like to see the function be renamed to
east_asian_width() since that's what the function is based on.

If possible, I'd also rather like to see the full width
mapping implemented (as defined in the TR). The reduction to
narrow vs. wide seems to be oversimplified. The
east_asian_width() function should return the characters:
"N", "A", "H", "W", "F", "Na" and let the user decide how to
map these to character or string widths. We have followed
the same methodology for the other Unicode database
properties and this has not only given us much more
flexibility, it also is standards compliant and you can get
good documentation on these features.

Matthew, I suggest you write your own implementation of what
you think is right. In the face of ambiguity, there's no
such thing as the right approach to a certain problem.

Thanks.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 18:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 17:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 17:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 16:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 16:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 15:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 13:06:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 13:07:06 2004
Subject: [ python-Bugs-902628 ] doctest confused by super-instances in
	class-dicts
Message-ID: <E1Bl44n-0000WK-00@sc8-sf-web1.sourceforge.net>

Bugs item #902628, was opened at 2004-02-23 12:10
Message generated for change (Settings changed) made by tanzer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902628&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Tanzer (tanzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest confused by super-instances in class-dicts

Initial Comment:
In Python 2.3.3, doctest chokes on classes which
contain an attribute of type super: 

Traceback (most recent call last):
  File "/ttt/private/tanzer/temp/confuse_doctest.py",
line 14, in ?
    import doctest, confuse_doctest
  File
"/Node/tttprime/ttt/private/tanzer/temp/confuse_doctest.py",
line 15, in ?
    doctest.testmod(confuse_doctest)
  File "/usr/lib/python2.3/doctest.py", line 1148, in
testmod
    f, t = tester.rundict(m.__dict__, name, m)
  File "/usr/lib/python2.3/doctest.py", line 908, in
rundict
    f2, t2 = self.__runone(value, name + "." + thisname)
  File "/usr/lib/python2.3/doctest.py", line 1069, in
__runone
    return self.rundoc(target, name)
  File "/usr/lib/python2.3/doctest.py", line 828, in rundoc
    f2, t2 = self.run__test__(d, name)
  File "/usr/lib/python2.3/doctest.py", line 937, in
run__test__
    raise TypeError("Tester.run__test__: values in "
TypeError: Tester.run__test__: values in dict must be
strings, functions, methods, or classes; <super: <class
'A'>, NULL>

A simple example triggering the bug is attached.

Python 2.3.3 (#2, Jan 13 2004, 00:47:05) 
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2



----------------------------------------------------------------------

Comment By: Christian Tanzer (tanzer)
Date: 2004-02-23 12:15

Message:
Logged In: YES 
user_id=2402

I patched doctest.py to avoid the traceback (see attached
patch-file). I'm not sure if this is the right place to fix
the bug, though. Maybe inspect.classify_class_attrs should
be changed instead?

The second chunk of the patch improves the traceback given
by doctest by giving the name of the offending dict-item.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902628&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 13:48:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 13:48:17 2004
Subject: [ python-Bugs-990941 ] Uninstall Python shortcut does not work
Message-ID: <E1Bl4if-0004gt-00@sc8-sf-web4.sourceforge.net>

Bugs item #990941, was opened at 2004-07-14 17:27
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470

Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: Uninstall Python shortcut does not work

Initial Comment:
I get a box 'This action is only valid for products
which are currently installed'.
Uninstalling with Control Panel -> Add/Remove works fine.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-15 13:48

Message:
Logged In: YES 
user_id=11105

Tim, I already know and read from time to time Raymond's
weblog - but it is a useful pointer for the casual reader of
Python's bug reports.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 05:33

Message:
Logged In: YES 
user_id=31435

Thomas, do yourself a favor and Google on "Raymond Chen 
add remove" -- you'll find an hilarious/depressing weblog 
about *why*add/remove is so slow to come up in modern 
Windows.  Believe it or not, there are impossible-to-fix 
reasons for it!

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-14 21:04

Message:
Logged In: YES 
user_id=21627

There was a bug in the script that would use different
product codes for an alpha (i.e. the "final" product code)
for uninstall. I have fixed this in my CVS sandbox before
the release of 2.4a0, but not yet committed - will do so
tomorrow.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-14 20:07

Message:
Logged In: YES 
user_id=11105

Hm, it works for Martin's MSI (the one downloaded from
python.org), but not for those created myself from the CVS tree.

Using the menu entry is much faster for people testing the
installers (Add/Remove take a long time to open on my
machine).  Normal users shouldn't uninstall Python anyway ;-)

[5 minutes later]

I guess he has set 'alpha = 0' in the msi.py script he used
to build the installer.  The 'alpha' version seems to use
two conflicting product codes for the MSI: one hardcoded, at
the top of the script, the other created by
msilib.gen_uuid() at line 81.

I'll try it out again, and report back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-14 17:59

Message:
Logged In: YES 
user_id=31435

Curious!  The Uninstall Start Menu entry for 2.4a1 worked fine 
for me, WinXP Pro.

If it's a "deep" problem, I expect we could just toss the 
Uninstall menu entry -- all versions of Windows I care about 
<wink> have the Add/Remove gimmick, which most Windows 
users expect to use for uninstallation anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 14:55:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 14:55:17 2004
Subject: [ python-Bugs-968245 ] Python Logging filename & file number 
Message-ID: <E1Bl5lW-0000YX-00@sc8-sf-web3.sourceforge.net>

Bugs item #968245, was opened at 2004-06-07 10:49
Message generated for change (Comment added) made by superleo303
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Ryan (superleo303)
Assigned to: Vinay Sajip (vsajip)
Summary: Python Logging filename & file number 

Initial Comment:
I use Freebsd and redhat 9.0 linus at work.

Using Python Logging filename & file number on freebsd
works fine.
When i print a log statement, and have my config
formatter section set like:
[formatter_default]
format=%(asctime)s <%(levelname)s>
<%(module)s:%(lineno)s> %(message)s
datefmt=

On bsd my logs look like:
<INFO> <propmancmd:95> stateOnly is: DE
<INFO> <propmancmd:105>  MEssages .........
<INFO> <propmancmd:107> collecting datasource: 1011
<INFO> <propman:98>   Collectors overwrite existing
pickle files: 0
<INFO> <propman:99>           Collectors run in
multiple threads: 4
<DEBUG> <propman:528> sql is:
...

See, the filename and file number get displayed with
each logging call,

Now, The same exact code run on the same exact version
of python on a linux machine yiedls the lines:

<INFO> <__init__:988> stateOnly is: DE
<INFO> <__init__:988>  MEssages
<INFO> <__init__:988> collecting datasource: 1011
<INFO> <__init__:988>   Collectors overwrite existing
pickle files: 0
<INFO> <__init__:988>           Collectors run in
multiple threads: 4
<DEBUG> <__init__:988> sql is: 
...

So i opened up ./python2.3/logging/__init__.py  line
988 and it seems to be where the problem is.

Can someone take a look at this asap?   I have to run
all my code on linux machines, so now i cant see which
file and which line is making the logging.

To reproduce, get a freebsd and linux machine,
then run a simple script that uses logging config files
and use the above example as your formatter in the
logging confrig file,

BSD should show the filenames and numbers, linux should
show __init__ 988 instead.


----------------------------------------------------------------------

>Comment By: Ryan (superleo303)
Date: 2004-07-15 07:55

Message:
Logged In: YES 
user_id=1058618

I have tried this on 3 red hat boxes, all the same version
of red hat, and im pretty sure its all the same version of
python, my sys admin builds a python package and installs
that way, ill ask him to install python from source on one
of the machines and see if that helps, if it doesnt, would
you be willing to log into our machine here and test it,
maybe there is something (obvious) you can see that is wrong?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-15 02:00

Message:
Logged In: YES 
user_id=308438

I tried this on Mandrake Linux 10 (it's a Red Hat variant) 
which has Python 2.3.3, with the expected result:

2004-07-15 07:45:58,258 <INFO> <test:9> This is a inof call.
2004-07-15 07:45:58,282 <WARNING> <test:10> This is a 
warn call.
2004-07-15 07:45:58,282 <ERROR> <test:11> This is a error 
call.

Might there be a problem with your Red Hat or Python 
installation? Have you tried it on several Red Hat boxes?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 10:40

Message:
Logged In: YES 
user_id=1058618

Also,
Here are the versions of python i am using

$ python
Python 2.3.3 (#2, Jan 21 2004, 07:27:38)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>>

$ python
Python 2.3.4 (#2, Jul 12 2004, 09:19:42)
[GCC 3.3.3 [FreeBSD] 20031106] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>>

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 10:31

Message:
Logged In: YES 
user_id=1058618

Hi ,
I have attached a script to reproduce the error, jsut run
./test.py in the folder.

This is what freebsd produces:
$ python ./test.py
2004-07-14 11:29:47,067 <INFO> <test:9> This is a inof call.
2004-07-14 11:29:47,069 <WARNING> <test:10> This is a warn call.
2004-07-14 11:29:47,069 <ERROR> <test:11> This is a error call.

This is what redhat produces:
$ python ./test.py
2004-07-14 11:28:24,812 <INFO> <__init__:988> This is a info
call.
2004-07-14 11:28:24,812 <WARNING> <__init__:988> This is a
warn call.
2004-07-14 11:28:24,812 <ERROR> <__init__:988> This is a
error call.

As you can see, the filename:fileno attributes are different.



----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-12 08:35

Message:
Logged In: YES 
user_id=1058618

Sorry, no , i just have been very busy and havent had time
to reproduce the error, 
i promise by tomorrow ill have a small set of scripts  to
reproduce the error.
All the linux boxes, which is 4 of them, are red hat 9.0, so
maybe its only a problem with red hat?
Ill be posting the scripts tomorrow.
Thanks for checking into this 

-Ryan

ps - i wasnt able to send you an email, it said:

<vsajip@users.sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said:
    550 Administrative prohibition

<vsajip@sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said: 550
    Administrative prohibition


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-05 07:06

Message:
Logged In: YES 
user_id=308438

I'm not able to reproduce these problems under Linux - I only 
have access to Mandrake 10.0 (a Red Hat variant).

Can you upload a script or set of scripts which demonstrates 
the problem?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-06-10 12:18

Message:
Logged In: YES 
user_id=1058618

vsajip, i tested on both machines, both machines returned
the same results:

STACKWALKER RESULTS RUN ON LINUX RED HAT 9.0

[rsmith@marge]:~/ned$ cd bin/testing/stackwalk/
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw1.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw2.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw3.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw4.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python getcaller.py
/home/rsmith/ned/bin/testing/stackwalk/sw1.py(4)
/home/rsmith/ned/bin/testing/stackwalk/sw2.py(5)
/home/rsmith/ned/bin/testing/stackwalk/sw3.py(6)
/home/rsmith/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[rsmith@marge]:~/ned/bin/testing/stackwalk$


-------------------------------------------------------------------------

STACKWALKER RESULTS RUN ON FREEBSD 5.2.1-RELEASE-p8

[ryan@dev2]:~/ned$ cd bin/testing/stackwalk/
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw1.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw2.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw3.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw4.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python getcaller.py
/usr/home/ryan/ned/bin/testing/stackwalk/sw1.py(4)
/usr/home/ryan/ned/bin/testing/stackwalk/sw2.py(5)
/usr/home/ryan/ned/bin/testing/stackwalk/sw3.py(6)
/usr/home/ryan/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[ryan@dev2]:~/ned/bin/testing/stackwalk$

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 04:26

Message:
Logged In: YES 
user_id=308438

The problem appears to be related to some underlying 
problem with sys._getframe(). Can you please download the 
attached stackwalk.tar.gz and run it on both FreeBSD and 
Linux? Please post your findings here, thanks. Note that the 
stackwalk stuff contains no calls to the logging package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 15:22:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 15:22:42 2004
Subject: [ python-Bugs-884085 ] OSATerminology is broken
Message-ID: <E1Bl6C5-0005nH-00@sc8-sf-web1.sourceforge.net>

Bugs item #884085, was opened at 2004-01-25 12:32
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=884085&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: OSATerminology is broken

Initial Comment:
the terminologyID is actually not supposed to come from the 
current dialect.  Since Apple doesn't really support non-
English dialects anymore anyway (as far as I can tell), I'm 
just going to keep it as zero.

Here's a patch (that just comments that stuff out, so it can 
be further tested).

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 15:22

Message:
Logged In: YES 
user_id=45365

Fixed in rev. 1.5 and 1.2.14.1.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-04-02 22:49

Message:
Logged In: YES 
user_id=45365

This whole bit of code is a silly misunderstanding. I'll rip it out.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=884085&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 15:32:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 15:32:47 2004
Subject: [ python-Bugs-978662 ] can't compile _localemodule.c w/o
	--enable-toolbox-glue
Message-ID: <E1Bl6Ls-0001LB-00@sc8-sf-web2.sourceforge.net>

Bugs item #978662, was opened at 2004-06-24 03:56
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978662&group_id=5470

Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
>Assigned to: Brett Cannon (bcannon)
Summary: can't compile _localemodule.c w/o --enable-toolbox-glue

Initial Comment:
Line 412 of Modules/_localemodule.c calls PyMac_getscript() which 
is within a ``#if defined(__APPLE__)`` block.  Trouble is that the 
code is in Python/mactoolboxglue.c which is not compiled if --
disable-toolbox-glue is a compile option (which it was on my OS X 
10.3.4 box).  Probably shouldn't have a compile failure thanks to ld 
not finding the symbol; should probably either just not compile the 
module, change the #if block, or change the function.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 15:32

Message:
Logged In: YES 
user_id=45365

Ok, I've checked in the changes. I'm assigning to you so you can check 
that a --disable-toolbox-glue build still works, please close this report if 
it does.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-26 05:41

Message:
Logged In: YES 
user_id=357491

grep agrees with you, Jack:

drifty@Bretts-Computer>grep -rl PyMac_getscript *
Include/pymactoolbox.h
Modules/_localemodule.c
Python/mactoolboxglue.c

So we could just copy and paste it (and fix the spelling of Fredrik's last 
name  =).  But will those CF* functions be linked properly w/o a 
framework build?

I didn't see any macro definitions or anything to signal when a toolbox 
glue build was being done, but it would not hurt to define that.  I get a 
ton of linking errors for any module that has Carbon with this ``--
disable-framework --disable-toolbox-glue`` build that I have been 
fiddling with.  Should we try to make it so that those modules are built 
only if some flag is set somewhere signifying that the proper OS X-
specific build options are not turned off?

Or am I just being so totally non-standard with these build options (only 
done to try to build faster on my old iBook) that it is not worth the 
hassle?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-06-25 13:56

Message:
Logged In: YES 
user_id=45365

There are two solutions:
1) Move PyMac_getscript() to _localemodule.
2) Copy PyMac_getscript() to _localemodule.
3) #ifdef PyLocale_getdefaultlocale in _localemodule on something set by 
enable_toolbox_module_glue.

1) means we can't really put the external declaration in macglue.h any 
more (_localemodule needn't be configured), but I don't think it's used by 
anything but localemodule, so it's probably the best solution.

Still, this is an incompatible change, so we shouldn't backport it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978662&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 16:26:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 16:26:09 2004
Subject: [ python-Bugs-915942 ] CFStringGetUnicode() returns null-terminated
	unicode string
Message-ID: <E1Bl7BV-0000c1-00@sc8-sf-web1.sourceforge.net>

Bugs item #915942, was opened at 2004-03-14 11:22
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=915942&group_id=5470

Category: Macintosh
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: has (hhas)
Assigned to: Jack Jansen (jackjansen)
Summary: CFStringGetUnicode() returns null-terminated unicode string

Initial Comment:
Carbon.CoreFoundation CFStringGetUnicode() wrapper returns a 
null-terminated unicode string. Example:

#######

#!/usr/local/bin/pythonw

import Carbon.CoreFoundation as CF
from appscript import LaunchServices

path = 'TextEdit.app'

fURL = LaunchServices.LSFindApplicationForInfo ('????', None, 
path)[1]

print [c for c in 
(fURL.CFURLCopyFileSystemPath(CF.kCFURLPOSIXPathStyle).CFSt
ringGetUnicode())]

--> [u'/', u'A', u'p', u'p', u'l', u'i', u'c', u'a', u't', u'i', u'o', u'n', u's', 
u'/', u'T', u'e', u'x', u't', u'E', u'd', u'i', u't', u'.', u'a', u'p', u'p', u'x00'] -- why is last character 0x00???

#######

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 16:26

Message:
Logged In: YES 
user_id=45365

Fixed, both for 2.4 and 2.3.X.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=915942&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 16:56:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 16:56:07 2004
Subject: [ python-Bugs-781433 ] MacOS module doesn't compile on 10.1
Message-ID: <E1Bl7eT-0004mE-00@sc8-sf-web4.sourceforge.net>

Bugs item #781433, was opened at 2003-08-01 14:00
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781433&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacOS module doesn't compile on 10.1

Initial Comment:
The MacOS module (Mac/Modules/macosmodule.c) doesn't compile on OSX 10.1. A patch is attached.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 16:56

Message:
Logged In: YES 
user_id=45365

Fixed in 1.66.12.1 and 1.71.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781433&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 17:06:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 17:06:37 2004
Subject: [ python-Bugs-870997 ] bgenlocationscustomize: per-user
	configuration of bgen
Message-ID: <E1Bl7oe-0006Dd-00@sc8-sf-web2.sourceforge.net>

Bugs item #870997, was opened at 2004-01-05 16:50
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870997&group_id=5470

Category: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: bgenlocationscustomize: per-user configuration of bgen

Initial Comment:
bgen requires manual editing of bgenlocations on a per-
python-source-tree basis when building Python's wrappers.  
It also contains several hard-coded paths very likely to be 
different for people other than Jack :)

Integrating a bgenlocationscustomize phase would make this 
easy to configure per-user (or per build tree if you change 
the environment prior to building).  Of course, by 
r"bgenlocations(customize)?", I mean an analog to 
r"site(customize)?".

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 17:06

Message:
Logged In: YES 
user_id=45365

Implemented in bgenlocations.py rev 1.7.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870997&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 17:08:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 17:08:26 2004
Subject: [ python-Bugs-870972 ] Standardize on systemwide bgenlocations
	INCLUDEDIR
Message-ID: <E1Bl7qP-0006Lv-00@sc8-sf-web2.sourceforge.net>

Bugs item #870972, was opened at 2004-01-05 16:25
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870972&group_id=5470

Category: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Standardize on systemwide bgenlocations INCLUDEDIR

Initial Comment:
I propose that the bgenlocations.py INCLUDEDIR should be 
changed to /Developer/Universal/Interfaces/
CIncludes

This is not an Apple endorsed location, but it makes more 
sense than /Users/jack/src/Universal/Interfaces/CIncludes

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 17:08

Message:
Logged In: YES 
user_id=45365

I've rejected this one in favor of #870997, which allows users to use any 
pathname they want.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870972&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 17:09:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 17:09:26 2004
Subject: [ python-Bugs-779151 ] bgenlocations.py only works for OS9 users
	and jack ; )
Message-ID: <E1Bl7rN-0006QH-00@sc8-sf-web2.sourceforge.net>

Bugs item #779151, was opened at 2003-07-28 22:35
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779151&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: bgenlocations.py only works for OS9 users and jack ;)

Initial Comment:
--- I'm inlining snippets of code from plat-mac/
bgenlocations.py ---
if sys.platform == 'mac':
    # For MacPython we know where it is
    def _pardir(p): return os.path.split(p)[0]
    BGENDIR=os.path.join(sys.prefix, &quot;Tools&quot;, &quot;bgen&quot;, 
&quot;bgen&quot;)
else:
    # for unix-Python we don't know, please set it yourself.
    BGENDIR=&quot;/Users/jack/src/python/Tools/bgen/bgen&quot;

With unix python using Jack's 2.3rc2 installer, BGENDIR 
should be /Applications/MacPython-2.3/Extras/Tools/bgen

#
# Where to put the python definitions files. Note that, on 
unix-Python,
# if you want to commit your changes to the CVS repository 
this should refer to
# your source directory, not your installed directory.
#
if sys.platform == 'mac':
    TOOLBOXDIR=os.path.join(sys.prefix, &quot;Lib&quot;, &quot;plat-mac&quot;, 
&quot;Carbon&quot;)
else:
    TOOLBOXDIR=&quot;/Users/jack/src/python/Lib/plat-mac/
Carbon&quot;

TOOLBOXDIR should point somewhere reasonable.  maybe 
os.path.expanduser('~/src/python/')... You should be able to 
override this without editing your python installation.  For 
example, it could print a warning instead of raising an 
exception.. look somewhere in sys.path for an override file, 
etc.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 17:09

Message:
Logged In: YES 
user_id=45365

Sort-of a duplicate of #870997.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779151&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 17:10:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 17:10:33 2004
Subject: [ python-Bugs-740424 ] MacPython-OS9 distutils breaks on OSX
Message-ID: <E1Bl7sS-0006VM-00@sc8-sf-web2.sourceforge.net>

Bugs item #740424, was opened at 2003-05-20 14:38
Message generated for change (Settings changed) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython-OS9 distutils breaks on OSX

Initial Comment:
MacPython-OS9 distutils (or actually the underlying mkcwproject 
package) does not always work on OSX. The problem is that 
references to the GUSI source tree are relative pathnames to the 
Python sourcetree with :: in them, and CW (at least CW7) doesn't 
understand this when running on OSX. 

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-06-06 14:39

Message:
Logged In: YES 
user_id=92689

It appears to be a bug in CW8: the paths are correct in the 
generated XML, and they are correctly marked as formatted for 
MacOS.

However, if I manually tweak the paths in the XML file, I get lots 
of other errors, so I'm tempted to punt, and forget about distutils 
for CW 8 :-(. I'm so fedup with CW.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-06-06 12:11

Message:
Logged In: YES 
user_id=92689

I have attached a screenshot which illustrates the problem 
(access paths are OS9-style but with OSX separator). This 
is with OS9MacPython 2.2.3 as posted today. Do you have any 
tips on where to look? I'm not familiar with the distutils CW back 
end at all.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-05-23 16:31

Message:
Logged In: YES 
user_id=92689

I didn't do a _lot_ of testing, but it sure looked like it simply doesn't work at 
all.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-05-23 16:11

Message:
Logged In: YES 
user_id=45365

Just: do you mean that *no* distutils-based packages build correctly with 
MacPython-OS9 on OSX with CW8 because of the incorrect pathnames?

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-05-20 18:18

Message:
Logged In: YES 
user_id=92689

I've observed that (at least with CW8) _all_ pathnames are wrong: they do use 
/, but the paths are constructed as if they are OS9 paths, ie. the start with 
the volume name ( /MyHD/rest/of/path )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740424&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 17:11:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 17:11:22 2004
Subject: [ python-Bugs-729871 ] MacPython-OS9 eats CPU while waiting for I/O
Message-ID: <E1Bl7tF-0006Y7-00@sc8-sf-web2.sourceforge.net>

Bugs item #729871, was opened at 2003-04-29 23:42
Message generated for change (Settings changed) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729871&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython-OS9 eats CPU while waiting for I/O

Initial Comment:
MacPython-OS9 gobbles up CPU cycles while it is idle waiting for I/O 
(at least for user input to the terminal). On OS9 this has not much 
effect, because of the other scheduling tricks involved, but on OSX it 
is a real nuisance.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729871&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 17:11:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 17:11:56 2004
Subject: [ python-Bugs-757567 ] Mac/OSX/README outdated
Message-ID: <E1Bl7tl-0006Zs-00@sc8-sf-web2.sourceforge.net>

Bugs item #757567, was opened at 2003-06-20 00:43
Message generated for change (Settings changed) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757567&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: Mac/OSX/README outdated

Initial Comment:
Mac/OSX/README needs work. Some pathnames are 
wrong, and the section on how to build a binary installer is 
incorrect.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 17:15

Message:
Logged In: YES 
user_id=45365

I think it is fine again now. I'm assigning to you for testing, could 
you please close it if you agree?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757567&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 17:12:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 17:13:01 2004
Subject: [ python-Bugs-762147 ] PackMan needs to be able to install outside
	site-packages
Message-ID: <E1Bl7uq-0006dM-00@sc8-sf-web2.sourceforge.net>

Bugs item #762147, was opened at 2003-06-28 00:26
Message generated for change (Settings changed) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762147&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PackMan needs to be able to install outside site-packages

Initial Comment:
PackMan needs to be able to install system-wide packages 
in /Library/Python/2.3/site-packages, in the event that the 
normal $prefix/lib/python2.3/site-packages is not writeable. 
That directory also needs to be put on sys.path (for 
framework OSX builds only) if it exists, similarly to ~/
Library/Python/2.3/site-packages.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-29 01:28

Message:
Logged In: YES 
user_id=45365

It turns out this is less of a problem than I feared: site-packages 
is a symlink to a place that is writable. There is still a problem 
when a distutils-based package tries to install extra header files, 
but that will have to be solved after 2.3b2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762147&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 17:24:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 17:24:34 2004
Subject: [ python-Bugs-883283 ] bundlebuilder --lib mishandles frameworks
Message-ID: <E1Bl861-0003UL-00@sc8-sf-web1.sourceforge.net>

Bugs item #883283, was opened at 2004-01-23 21:44
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883283&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder --lib mishandles frameworks

Initial Comment:
The bundlebuilder command-line argument --lib is supposed to be able to include frameworks in the resulting Mac app. Unfortunately, the aliases in the resulting framework copy are all broken.

For an example of this, use --lib to include Tcl.framework and then look through the framework in the resulting application package. Frameworks normally have quite a few handy aliases (such as .../Versions/Current) and all the aliases I tried were broken.

I'm not entirely sure if this actually breaks anything. The one app I've managed to build with standalone=True and use of --lib to include the Tk and Tcl frameworks runs fine on my Mac (which has Python, Tcl and Tk frameworks installed) but fails with "True undefined" on another Mac running Jaguar that I happened to have handy.

This 2nd problem may be a separate bug or user error on my part. I'm not yet sure.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 17:24

Message:
Logged In: YES 
user_id=45365

I cannot repeat this, neither with 2.4a1 nor with 2.3: I always get 
symlinks where they are expected. I tried the following command line 
(with test.py being a simple hello world script), on MacOS 10.3.4 with 
apple-installed Python:

/usr/bin/python /System/Library/Frameworks/Python.framework/
Versions/2.3/lib/python2.3/plat-mac/bundlebuilder.py -m test.py --lib /
Library/Frameworks/Tcl.framework build

and I got symlinks just fine. Feel free to reopen the bug report if you 
have more info.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883283&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 18:36:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 18:36:16 2004
Subject: [ python-Bugs-991708 ] test_imp failure
Message-ID: <E1Bl9DR-0006l4-00@sc8-sf-web1.sourceforge.net>

Bugs item #991708, was opened at 2004-07-15 16:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991708&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_imp failure

Initial Comment:
With threads disabled under fedore core 1

uname -r
2.4.22-1.2188.nptlsmp

./python -E -tt ./Lib/test/regrtest.py -vv test_imp
test_imp
test test_imp failed -- expected imp.lock_held() to be True
1 test failed:
    test_imp

Looks shallow. :)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991708&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 18:37:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 18:37:56 2004
Subject: [ python-Bugs-990953 ] 2.4 msi installer installs too many files
Message-ID: <E1Bl9F0-0000pv-00@sc8-sf-web4.sourceforge.net>

Bugs item #990953, was opened at 2004-07-14 17:44
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990953&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: 2.4 msi installer installs too many files

Initial Comment:
The msi installer installs the directory
Lib/distutils/test/build and it's subdirs, at least if
they are present on the system where the msi is built.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 18:37

Message:
Logged In: YES 
user_id=21627

Why would there be any directories in test/build? The
installer picks up all directories in Lib, except for
directories named CVS or starting with plat-. This
simplifies maintenance, as it removes the need to explicitly
change the installer every time a new Python packages is
added to Lib.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990953&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 18:53:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 18:53:28 2004
Subject: [ python-Bugs-990941 ] Uninstall Python shortcut does not work
Message-ID: <E1Bl9Tz-0001OD-00@sc8-sf-web4.sourceforge.net>

Bugs item #990941, was opened at 2004-07-14 17:27
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: Uninstall Python shortcut does not work

Initial Comment:
I get a box 'This action is only valid for products
which are currently installed'.
Uninstalling with Control Panel -> Add/Remove works fine.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 18:53

Message:
Logged In: YES 
user_id=21627

This is now fixed in msi.py 1.13.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 13:48

Message:
Logged In: YES 
user_id=11105

Tim, I already know and read from time to time Raymond's
weblog - but it is a useful pointer for the casual reader of
Python's bug reports.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 05:33

Message:
Logged In: YES 
user_id=31435

Thomas, do yourself a favor and Google on "Raymond Chen 
add remove" -- you'll find an hilarious/depressing weblog 
about *why*add/remove is so slow to come up in modern 
Windows.  Believe it or not, there are impossible-to-fix 
reasons for it!

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-14 21:04

Message:
Logged In: YES 
user_id=21627

There was a bug in the script that would use different
product codes for an alpha (i.e. the "final" product code)
for uninstall. I have fixed this in my CVS sandbox before
the release of 2.4a0, but not yet committed - will do so
tomorrow.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-14 20:07

Message:
Logged In: YES 
user_id=11105

Hm, it works for Martin's MSI (the one downloaded from
python.org), but not for those created myself from the CVS tree.

Using the menu entry is much faster for people testing the
installers (Add/Remove take a long time to open on my
machine).  Normal users shouldn't uninstall Python anyway ;-)

[5 minutes later]

I guess he has set 'alpha = 0' in the msi.py script he used
to build the installer.  The 'alpha' version seems to use
two conflicting product codes for the MSI: one hardcoded, at
the top of the script, the other created by
msilib.gen_uuid() at line 81.

I'll try it out again, and report back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-14 17:59

Message:
Logged In: YES 
user_id=31435

Curious!  The Uninstall Start Menu entry for 2.4a1 worked fine 
for me, WinXP Pro.

If it's a "deep" problem, I expect we could just toss the 
Uninstall menu entry -- all versions of Windows I care about 
<wink> have the Add/Remove gimmick, which most Windows 
users expect to use for uninstallation anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990941&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 18:55:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 18:55:22 2004
Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k
Message-ID: <E1Bl9Vu-0001Ta-00@sc8-sf-web4.sourceforge.net>

Bugs item #989338, was opened at 2004-07-12 13:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_unicode_file fails on win2k

Initial Comment:
>>> test_support.verbose = 1
>>> test_unicode_file.test_main()
test_directories
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_single_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR

======================================================================
ERROR: test_directories
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
178, in test_directories
    self._do_directory(TESTFN_ENCODED+ext,
TESTFN_ENCODED+ext, True)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
112, in _do_directory
    os.mkdir(make_name)
OSError: [Errno 22] Invalid argument: '@test-??.dir'

======================================================================
ERROR: test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
170, in test_equivalent_files
    self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
154, in _test_equivalent
    f = file(filename1, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

======================================================================
ERROR: test_single_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
164, in test_single_files
    self._test_single(TESTFN_ENCODED)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
136, in _test_single
    f = file(filename, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

----------------------------------------------------------------------
Ran 3 tests in 0.061s

FAILED (errors=3)

Traceback (most recent call last):
  File "<pyshell#21>", line 1, in -toplevel-
    test_unicode_file.test_main()
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
191, in test_main
    run_suite(suite)
  File "C:\apps\Python24\lib\test\test_support.py",
line 274, in run_suite
    raise TestFailed(msg)
TestFailed: errors occurred; run in verbose mode for
details
>>> 

This is Python2.4a1 on win2k pro

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 18:55

Message:
Logged In: YES 
user_id=21627

Are you using a FAT partition?

What precise version string do you get in winver.exe?

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-07-13 08:10

Message:
Logged In: YES 
user_id=358087

Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro.
Any other data I can send?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 18:35

Message:
Logged In: YES 
user_id=31435

Peculiar -- it works fine on WinXP Pro, which ought to work 
the same as Win2K here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 19:08:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 19:08:06 2004
Subject: [ python-Bugs-991735 ] os.access reports true for read-only
	directories
Message-ID: <E1Bl9iD-0001xb-00@sc8-sf-web4.sourceforge.net>

Bugs item #991735, was opened at 2004-07-15 13:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
Assigned to: Thomas Heller (theller)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 19:24:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 19:24:36 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bl9y8-0000GP-00@sc8-sf-web1.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 19:24

Message:
Logged In: YES 
user_id=21627

I still think a function is useful which computes the number
of Ems that a conventional application would expect. That
function should raise an exception for a neutral character -
the example of the combining characters shows that such
characters should *not* be treated as narrow "for all
practical purposes".

Whether or not it is useful to include the entire UAX#11
classification in the database I don't know - it seems the
only application of the data would be computation of the
width, anyway.

It would not be wise to move the data to the unicode
database, as the extra data currently don't affect Python
programs that don't use the function, anyway - the data does
not consume any additional space.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 11:39

Message:
Logged In: YES 
user_id=38388

Hye-Shik, the patch only includes the move to unicodedata, but
not the full implementation of the EAW as per the TR. I would
much prefer to have the east_asian_width() function return
the strings defined in the TR because this allows users of the
function to read the information and implement their own 
interpretation of "width".

The new function should work very much like 
unicodedata.category().

It would also be wise to move the data itself over to the
unicode
database - that way the extra data does not affect Python
programs that don't use the function.

Thanks.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-14 17:15

Message:
Logged In: YES 
user_id=55188

Marc-Andre, here's a patch written as you've suggested.
Can you please give a review on this?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 21:41

Message:
Logged In: YES 
user_id=38388

Thanks for your descriptions, Hye-Shik.

Since the application space is very much targetted at East
Asian scripts, I would like the implementation to be moved
into unicodedata where all the other special Unicode
features are implemented. The .width() method should be removed.

Now that I understand better what the EAW is about, I would
also like to see the function be renamed to
east_asian_width() since that's what the function is based on.

If possible, I'd also rather like to see the full width
mapping implemented (as defined in the TR). The reduction to
narrow vs. wide seems to be oversimplified. The
east_asian_width() function should return the characters:
"N", "A", "H", "W", "F", "Na" and let the user decide how to
map these to character or string widths. We have followed
the same methodology for the other Unicode database
properties and this has not only given us much more
flexibility, it also is standards compliant and you can get
good documentation on these features.

Matthew, I suggest you write your own implementation of what
you think is right. In the face of ambiguity, there's no
such thing as the right approach to a certain problem.

Thanks.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 18:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 17:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 17:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 16:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 16:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 15:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 19:27:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 19:27:18 2004
Subject: [ python-Bugs-991754 ] _bsddb segfault
Message-ID: <E1BlA0o-0003Fv-00@sc8-sf-web3.sourceforge.net>

Bugs item #991754, was opened at 2004-07-15 17:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: _bsddb segfault

Initial Comment:
I have to remove the _bsddb extension to run the Python
tests. Otherwise I get a segfault when test_anydbm is
run. I also get a segfault running test_bsddb

uname -r
2.4.22-1.2188.nptlsmp

rpm -q db4
db4-4.1.25-14


gdb ./python
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as
"i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r -E -tt ./Lib/test/regrtest.py -vv test_bsddb
Starting program:
/home/jim/src/python/cvs2/dist/src/python -E -tt
./Lib/test/regrtest.py -vv test_bsddb
[Thread debugging using libthread_db enabled]
[New Thread -1084317568 (LWP 19122)]
test_bsddb
test__no_deadlock_first (test.test_bsddb.TestBTree) ...
ERROR

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1084317568 (LWP 19122)]
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
(gdb) r -E -tt ./Lib/test/regrtest.py -vv test_anydbm
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program:
/home/jim/src/python/cvs2/dist/src/python -E -tt
./Lib/test/regrtest.py -vv test_anydbm
[Thread debugging using libthread_db enabled]
[New Thread -1084645248 (LWP 19132)]
test_anydbm
test_anydbm_creation (test.test_anydbm.AnyDBMTestCase)
... ERROR

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1084645248 (LWP 19132)]
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 19:36:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 19:36:39 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1BlA9r-0003Ey-00@sc8-sf-web4.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 19:36

Message:
Logged In: YES 
user_id=38388

Martin, you can code such a function in your application
based on the information you'd get from
unicodedata.east_asian_width(). As we've seen, there is no
generally sound way to define such a function.

As for the location of the data: the unicodedata module is
the place where any extra information related to Unicode
should go. unicodectype.c is reserved for data needed at C
level by the Python Unicode C API.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 19:24

Message:
Logged In: YES 
user_id=21627

I still think a function is useful which computes the number
of Ems that a conventional application would expect. That
function should raise an exception for a neutral character -
the example of the combining characters shows that such
characters should *not* be treated as narrow "for all
practical purposes".

Whether or not it is useful to include the entire UAX#11
classification in the database I don't know - it seems the
only application of the data would be computation of the
width, anyway.

It would not be wise to move the data to the unicode
database, as the extra data currently don't affect Python
programs that don't use the function, anyway - the data does
not consume any additional space.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 11:39

Message:
Logged In: YES 
user_id=38388

Hye-Shik, the patch only includes the move to unicodedata, but
not the full implementation of the EAW as per the TR. I would
much prefer to have the east_asian_width() function return
the strings defined in the TR because this allows users of the
function to read the information and implement their own 
interpretation of "width".

The new function should work very much like 
unicodedata.category().

It would also be wise to move the data itself over to the
unicode
database - that way the extra data does not affect Python
programs that don't use the function.

Thanks.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-14 17:15

Message:
Logged In: YES 
user_id=55188

Marc-Andre, here's a patch written as you've suggested.
Can you please give a review on this?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 21:41

Message:
Logged In: YES 
user_id=38388

Thanks for your descriptions, Hye-Shik.

Since the application space is very much targetted at East
Asian scripts, I would like the implementation to be moved
into unicodedata where all the other special Unicode
features are implemented. The .width() method should be removed.

Now that I understand better what the EAW is about, I would
also like to see the function be renamed to
east_asian_width() since that's what the function is based on.

If possible, I'd also rather like to see the full width
mapping implemented (as defined in the TR). The reduction to
narrow vs. wide seems to be oversimplified. The
east_asian_width() function should return the characters:
"N", "A", "H", "W", "F", "Na" and let the user decide how to
map these to character or string widths. We have followed
the same methodology for the other Unicode database
properties and this has not only given us much more
flexibility, it also is standards compliant and you can get
good documentation on these features.

Matthew, I suggest you write your own implementation of what
you think is right. In the face of ambiguity, there's no
such thing as the right approach to a certain problem.

Thanks.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 18:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 17:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 17:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 16:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 16:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 15:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 19:37:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 19:37:51 2004
Subject: [ python-Bugs-988784 ] Windows installer missing test files
Message-ID: <E1BlAB2-00015Z-00@sc8-sf-web1.sourceforge.net>

Bugs item #988784, was opened at 2004-07-11 07:37
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988784&group_id=5470

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. L?wis (loewis)
Summary: Windows installer missing test files

Initial Comment:
The 2.4a1 Windows installer doesn't include the test file 
cfgparser.1, so test_cfgparser gets three errors in an 
installed Python on Windows:

==========================================
============================
FAIL: test_read_returns_file_list 
(__main__.ConfigParserTestCase)
------------------------------------------------------
----------------
Traceback (most recent call last):
  File "lib\test\test_cfgparser.py", line 250, in 
test_read_returns_file_list
    self.assertEqual(parsed_files, [file1])
AssertionError: [] != ['cfgparser.1']

==========================================
============================
FAIL: test_read_returns_file_list 
(__main__.RawConfigParserTestCase)
------------------------------------------------------
----------------
Traceback (most recent call last):
  File "lib\test\test_cfgparser.py", line 250, in 
test_read_returns_file_list
    self.assertEqual(parsed_files, [file1])
AssertionError: [] != ['cfgparser.1']

==========================================
============================
FAIL: test_read_returns_file_list 
(__main__.SafeConfigParserTestCase)
------------------------------------------------------
----------------
Traceback (most recent call last):
  File "lib\test\test_cfgparser.py", line 250, in 
test_read_returns_file_list
    self.assertEqual(parsed_files, [file1])
AssertionError: [] != ['cfgparser.1']

------------------------------------------------------
----------------
Ran 39 tests in 0.031s

FAILED (failures=3)

I think test files for the new decimal module are missing 
too, although I believe you won't notice this unless you 
pass "-u decimal" to regrtest.py, or run test_decimal.py 
directly.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 19:37

Message:
Logged In: YES 
user_id=21627

This is fixed in msi.py 1.14.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988784&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 20:05:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 20:05:10 2004
Subject: [ python-Bugs-968245 ] Python Logging filename & file number 
Message-ID: <E1BlAbO-0004Jh-00@sc8-sf-web3.sourceforge.net>

Bugs item #968245, was opened at 2004-06-07 10:49
Message generated for change (Comment added) made by superleo303
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Ryan (superleo303)
Assigned to: Vinay Sajip (vsajip)
Summary: Python Logging filename & file number 

Initial Comment:
I use Freebsd and redhat 9.0 linus at work.

Using Python Logging filename & file number on freebsd
works fine.
When i print a log statement, and have my config
formatter section set like:
[formatter_default]
format=%(asctime)s <%(levelname)s>
<%(module)s:%(lineno)s> %(message)s
datefmt=

On bsd my logs look like:
<INFO> <propmancmd:95> stateOnly is: DE
<INFO> <propmancmd:105>  MEssages .........
<INFO> <propmancmd:107> collecting datasource: 1011
<INFO> <propman:98>   Collectors overwrite existing
pickle files: 0
<INFO> <propman:99>           Collectors run in
multiple threads: 4
<DEBUG> <propman:528> sql is:
...

See, the filename and file number get displayed with
each logging call,

Now, The same exact code run on the same exact version
of python on a linux machine yiedls the lines:

<INFO> <__init__:988> stateOnly is: DE
<INFO> <__init__:988>  MEssages
<INFO> <__init__:988> collecting datasource: 1011
<INFO> <__init__:988>   Collectors overwrite existing
pickle files: 0
<INFO> <__init__:988>           Collectors run in
multiple threads: 4
<DEBUG> <__init__:988> sql is: 
...

So i opened up ./python2.3/logging/__init__.py  line
988 and it seems to be where the problem is.

Can someone take a look at this asap?   I have to run
all my code on linux machines, so now i cant see which
file and which line is making the logging.

To reproduce, get a freebsd and linux machine,
then run a simple script that uses logging config files
and use the above example as your formatter in the
logging confrig file,

BSD should show the filenames and numbers, linux should
show __init__ 988 instead.


----------------------------------------------------------------------

>Comment By: Ryan (superleo303)
Date: 2004-07-15 13:05

Message:
Logged In: YES 
user_id=1058618

Bug is solved. Probably due to the fact that the our sys
admin builds packages and doesnt install python from source,
the package had pyc and pyo files in it for logging/__inti__.py*
once those were deleted, and as root, ran python -O, the
problem was fixed.  Sorry to waste time with a non-bug   :)
This issue is solved.

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-15 07:55

Message:
Logged In: YES 
user_id=1058618

I have tried this on 3 red hat boxes, all the same version
of red hat, and im pretty sure its all the same version of
python, my sys admin builds a python package and installs
that way, ill ask him to install python from source on one
of the machines and see if that helps, if it doesnt, would
you be willing to log into our machine here and test it,
maybe there is something (obvious) you can see that is wrong?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-15 02:00

Message:
Logged In: YES 
user_id=308438

I tried this on Mandrake Linux 10 (it's a Red Hat variant) 
which has Python 2.3.3, with the expected result:

2004-07-15 07:45:58,258 <INFO> <test:9> This is a inof call.
2004-07-15 07:45:58,282 <WARNING> <test:10> This is a 
warn call.
2004-07-15 07:45:58,282 <ERROR> <test:11> This is a error 
call.

Might there be a problem with your Red Hat or Python 
installation? Have you tried it on several Red Hat boxes?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 10:40

Message:
Logged In: YES 
user_id=1058618

Also,
Here are the versions of python i am using

$ python
Python 2.3.3 (#2, Jan 21 2004, 07:27:38)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>>

$ python
Python 2.3.4 (#2, Jul 12 2004, 09:19:42)
[GCC 3.3.3 [FreeBSD] 20031106] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>>

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 10:31

Message:
Logged In: YES 
user_id=1058618

Hi ,
I have attached a script to reproduce the error, jsut run
./test.py in the folder.

This is what freebsd produces:
$ python ./test.py
2004-07-14 11:29:47,067 <INFO> <test:9> This is a inof call.
2004-07-14 11:29:47,069 <WARNING> <test:10> This is a warn call.
2004-07-14 11:29:47,069 <ERROR> <test:11> This is a error call.

This is what redhat produces:
$ python ./test.py
2004-07-14 11:28:24,812 <INFO> <__init__:988> This is a info
call.
2004-07-14 11:28:24,812 <WARNING> <__init__:988> This is a
warn call.
2004-07-14 11:28:24,812 <ERROR> <__init__:988> This is a
error call.

As you can see, the filename:fileno attributes are different.



----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-12 08:35

Message:
Logged In: YES 
user_id=1058618

Sorry, no , i just have been very busy and havent had time
to reproduce the error, 
i promise by tomorrow ill have a small set of scripts  to
reproduce the error.
All the linux boxes, which is 4 of them, are red hat 9.0, so
maybe its only a problem with red hat?
Ill be posting the scripts tomorrow.
Thanks for checking into this 

-Ryan

ps - i wasnt able to send you an email, it said:

<vsajip@users.sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said:
    550 Administrative prohibition

<vsajip@sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said: 550
    Administrative prohibition


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-05 07:06

Message:
Logged In: YES 
user_id=308438

I'm not able to reproduce these problems under Linux - I only 
have access to Mandrake 10.0 (a Red Hat variant).

Can you upload a script or set of scripts which demonstrates 
the problem?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-06-10 12:18

Message:
Logged In: YES 
user_id=1058618

vsajip, i tested on both machines, both machines returned
the same results:

STACKWALKER RESULTS RUN ON LINUX RED HAT 9.0

[rsmith@marge]:~/ned$ cd bin/testing/stackwalk/
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw1.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw2.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw3.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw4.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python getcaller.py
/home/rsmith/ned/bin/testing/stackwalk/sw1.py(4)
/home/rsmith/ned/bin/testing/stackwalk/sw2.py(5)
/home/rsmith/ned/bin/testing/stackwalk/sw3.py(6)
/home/rsmith/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[rsmith@marge]:~/ned/bin/testing/stackwalk$


-------------------------------------------------------------------------

STACKWALKER RESULTS RUN ON FREEBSD 5.2.1-RELEASE-p8

[ryan@dev2]:~/ned$ cd bin/testing/stackwalk/
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw1.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw2.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw3.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw4.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python getcaller.py
/usr/home/ryan/ned/bin/testing/stackwalk/sw1.py(4)
/usr/home/ryan/ned/bin/testing/stackwalk/sw2.py(5)
/usr/home/ryan/ned/bin/testing/stackwalk/sw3.py(6)
/usr/home/ryan/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[ryan@dev2]:~/ned/bin/testing/stackwalk$

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 04:26

Message:
Logged In: YES 
user_id=308438

The problem appears to be related to some underlying 
problem with sys._getframe(). Can you please download the 
attached stackwalk.tar.gz and run it on both FreeBSD and 
Linux? Please post your findings here, thanks. Note that the 
stackwalk stuff contains no calls to the logging package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 20:37:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 20:37:16 2004
Subject: [ python-Bugs-991805 ] Documentation of DOMImplmentation lacking
Message-ID: <E1BlB6X-0005iu-00@sc8-sf-web4.sourceforge.net>

Bugs item #991805, was opened at 2004-07-15 14:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991805&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert M. Zigweid (rzigweid)
Assigned to: Nobody/Anonymous (nobody)
Summary: Documentation of DOMImplmentation lacking

Initial Comment:
The documentation for DOMImplementation is lacking.  While I 
realize that there are several possible DOMImplementations, the 
default one seems to have no documentation.  

If it is documented, a cross reference needs to be made on the 
minidom documentation (Section 13.7), where 
DOMImplementation.createDocument is referenced.  I want to know 
what the arguments are supposed to be.  Examples are great, but 
they don't replace documentation.




p.s. Barry made me do it. :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991805&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 20:37:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 20:38:25 2004
Subject: [ python-Bugs-991805 ] Documentation of DOMImplmentation lacking
Message-ID: <E1BlB6w-0005Rj-00@sc8-sf-web3.sourceforge.net>

Bugs item #991805, was opened at 2004-07-15 14:37
Message generated for change (Settings changed) made by rzigweid
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991805&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert M. Zigweid (rzigweid)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Documentation of DOMImplmentation lacking

Initial Comment:
The documentation for DOMImplementation is lacking.  While I 
realize that there are several possible DOMImplementations, the 
default one seems to have no documentation.  

If it is documented, a cross reference needs to be made on the 
minidom documentation (Section 13.7), where 
DOMImplementation.createDocument is referenced.  I want to know 
what the arguments are supposed to be.  Examples are great, but 
they don't replace documentation.




p.s. Barry made me do it. :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991805&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 20:41:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 20:41:16 2004
Subject: [ python-Bugs-991735 ] os.access reports true for read-only
	directories
Message-ID: <E1BlBAK-0005Up-00@sc8-sf-web3.sourceforge.net>

Bugs item #991735, was opened at 2004-07-15 19:08
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
>Assigned to: Nobody/Anonymous (nobody)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-15 20:41

Message:
Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 20:45:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 20:45:55 2004
Subject: [ python-Bugs-991812 ] PyArg_ParseTuple can miss errors with
	warnings as exceptions
Message-ID: <E1BlBEu-0004KR-00@sc8-sf-web1.sourceforge.net>

Bugs item #991812, was opened at 2004-07-15 11:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991812&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: mssf (mssf)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTuple can miss errors with warnings as exceptions

Initial Comment:
in getargs.c, the convertsimple function returns NULL
if a float warning raised an exception, for example
passing a float to an int conversion.

NULL is interpreted by the caller, converttupple, as a
NON-error

The result is that PyArg_ParseTuple returns TRUE even
though it has left the float unconverted (and the
receiving integer variable containing whatever garbage
it contained before the call)

changing the return on the float error from NULL to
"converterr("integer<i>", arg, msgbuf, bufsize);", as
is done with every other error in this function,
corrects the problem.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991812&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 20:56:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 20:57:02 2004
Subject: [ python-Bugs-991735 ] os.access reports true for read-only
	directories
Message-ID: <E1BlBPb-0006W5-00@sc8-sf-web4.sourceforge.net>

Bugs item #991735, was opened at 2004-07-15 13:08
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-15 14:56

Message:
Logged In: YES 
user_id=31435

The tracker was set to auto-assign Windows reports to you, 
Thomas.  I disabled that (and Windows reports will be 
assigned to None by default now).

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 14:41

Message:
Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 21:20:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 21:20:46 2004
Subject: [ python-Bugs-991735 ] os.access reports true for read-only
	directories
Message-ID: <E1BlBmY-0005mV-00@sc8-sf-web1.sourceforge.net>

Bugs item #991735, was opened at 2004-07-15 19:08
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-15 21:20

Message:
Logged In: YES 
user_id=11105

Tim: I didn't know that.  Thanks for disabling it.

Mark: Sorry, it wasn't your fault.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 20:56

Message:
Logged In: YES 
user_id=31435

The tracker was set to auto-assign Windows reports to you, 
Thomas.  I disabled that (and Windows reports will be 
assigned to None by default now).

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 20:41

Message:
Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 21:25:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 21:26:03 2004
Subject: [ python-Bugs-991735 ] os.access reports true for read-only
	directories
Message-ID: <E1BlBrh-0007I4-00@sc8-sf-web3.sourceforge.net>

Bugs item #991735, was opened at 2004-07-15 13:08
Message generated for change (Comment added) made by mmoales
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

----------------------------------------------------------------------

>Comment By: Mark Moales (mmoales)
Date: 2004-07-15 15:25

Message:
Logged In: YES 
user_id=565165

This may not be a bug afterall.  I think it has to do with 
Window's ACLs.  I believe os.access is just looking at access 
bits.  For example, I can create a directory and leave it as 
writable, but prevent access to it via an ACL.  In this case, 
os.access reports true, but any operation you try to perform 
on the dictionary get's a permission error.  It might just need 
to be mentioned in the os.access doc.

Thomas: no problem

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 15:20

Message:
Logged In: YES 
user_id=11105

Tim: I didn't know that.  Thanks for disabling it.

Mark: Sorry, it wasn't your fault.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 14:56

Message:
Logged In: YES 
user_id=31435

The tracker was set to auto-assign Windows reports to you, 
Thomas.  I disabled that (and Windows reports will be 
assigned to None by default now).

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 14:41

Message:
Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 21:27:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 21:27:05 2004
Subject: [ python-Bugs-991834 ] Warning in cjkcodecs/iso2022common.h
Message-ID: <E1BlBsj-0000sx-00@sc8-sf-web2.sourceforge.net>

Bugs item #991834, was opened at 2004-07-15 21:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991834&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Hye-Shik Chang (perky)
Summary: Warning in cjkcodecs/iso2022common.h

Initial Comment:
I get a warning (MacOSX 10.3, gcc 3.3) in cjkcodecs/
iso2022common.h about an uninitialized variable, and it looks 
bona-fide:

/Users/jack/src/python/Modules/cjkcodecs/codecentry.h: In 
function `iso2022processesc':
/Users/jack/src/python/Modules/cjkcodecs/iso2022common.h:186: 
warning: `esclen' might be used uninitialized in this function


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991834&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 21:31:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 21:31:13 2004
Subject: [ python-Bugs-990953 ] 2.4 msi installer installs too many files
Message-ID: <E1BlBwg-0007SW-00@sc8-sf-web3.sourceforge.net>

Bugs item #990953, was opened at 2004-07-14 17:44
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990953&group_id=5470

Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: 2.4 msi installer installs too many files

Initial Comment:
The msi installer installs the directory
Lib/distutils/test/build and it's subdirs, at least if
they are present on the system where the msi is built.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-15 21:31

Message:
Logged In: YES 
user_id=11105

Maybe the distutils/build directory was created because I
ran the tests in it, or maybe by other things.

I'm lazy and normally build releases from the sandbox where
I usually work in, instead of  from a fresh checkout.

Closing as won't fix.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 18:37

Message:
Logged In: YES 
user_id=21627

Why would there be any directories in test/build? The
installer picks up all directories in Lib, except for
directories named CVS or starting with plat-. This
simplifies maintenance, as it removes the need to explicitly
change the installer every time a new Python packages is
added to Lib.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990953&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 22:40:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 22:40:30 2004
Subject: [ python-Bugs-991883 ] PyObject_CallMethod docs unclear (with
	dangerous results)
Message-ID: <E1BlD1n-0001kv-00@sc8-sf-web4.sourceforge.net>

Bugs item #991883, was opened at 2004-07-15 16:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991883&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyObject_CallMethod docs unclear (with dangerous results)

Initial Comment:
PyObject_CallMethod doesn't make clear that passing a
tuple of args is the correct way to use it. While it
does work when you don't pass a tuple, this causes
memory leak - the objects passed in get extra incref,
AFAICT, so it's worth emphasizing the correct API.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991883&group_id=5470
From noreply at sourceforge.net  Thu Jul 15 22:59:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 15 22:59:29 2004
Subject: [ python-Bugs-991735 ] os.access reports true for read-only
	directories
Message-ID: <E1BlDK3-0004DK-00@sc8-sf-web2.sourceforge.net>

Bugs item #991735, was opened at 2004-07-15 13:08
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-15 16:59

Message:
Logged In: YES 
user_id=31435

Heh -- I didn't know it either, Thomas.  But I've also noticed 
how many new Windows bugs get assigned to you, and got 
curious enough to dig into it.

----------------------------------------------------------------------

Comment By: Mark Moales (mmoales)
Date: 2004-07-15 15:25

Message:
Logged In: YES 
user_id=565165

This may not be a bug afterall.  I think it has to do with 
Window's ACLs.  I believe os.access is just looking at access 
bits.  For example, I can create a directory and leave it as 
writable, but prevent access to it via an ACL.  In this case, 
os.access reports true, but any operation you try to perform 
on the dictionary get's a permission error.  It might just need 
to be mentioned in the os.access doc.

Thomas: no problem

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 15:20

Message:
Logged In: YES 
user_id=11105

Tim: I didn't know that.  Thanks for disabling it.

Mark: Sorry, it wasn't your fault.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 14:56

Message:
Logged In: YES 
user_id=31435

The tracker was set to auto-assign Windows reports to you, 
Thomas.  I disabled that (and Windows reports will be 
assigned to None by default now).

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 14:41

Message:
Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:07:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:07:35 2004
Subject: [ python-Bugs-856407 ] Framework Info.plist is out of date
Message-ID: <E1BlEO2-0004lc-00@sc8-sf-web3.sourceforge.net>

Bugs item #856407, was opened at 2003-12-08 20:40
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856407&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Framework Info.plist is out of date

Initial Comment:
Version 2.3.0 through CVS HEAD of Python still has 
CFBundleShortVersionString and CFBundleVersion of 2.2 in 
python/dist/src/Mac/OSXResources/framework/Info.plist.  
Here is a breakdown:

Python 2.3.0 (distrib with OS X 10.3):
  - framework Info.plist : out of date
  - framework version.plist : out of date
  - app version.plist : out of date
  + app Info.plist : correct

Python CVS HEAD (Dec 8 2003, anon CVS):
  - framework Info.plist : out of date
  - framework version.plist : correct
  + app Info.plist : correct
  ? app version.plist : probably correct?  (I don't have a built 
version, there is not a separate version.plist sitting around in 
CVS)

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 00:07

Message:
Logged In: YES 
user_id=45365

There is now a script Mac/OSX/fixversions.py that updates the plist files 
to the correct information, and a note in Mac/OSX/README that this 
needs to be done.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-12-08 20:51

Message:
Logged In: YES 
user_id=45365

These should have been fixed in the 2.3maint branch (could you 
check)?

I haven't changed it yet on the head, because I hope to generate 
these files before 2.4final. I did add a note to the readme file 
about updating this version number.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856407&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:14:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:14:16 2004
Subject: [ python-Bugs-711989 ] IDE textwindow scrollbar is over-enthusiastic
Message-ID: <E1BlEUT-0003nu-00@sc8-sf-web1.sourceforge.net>

Bugs item #711989, was opened at 2003-03-30 00:25
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711989&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE textwindow scrollbar is over-enthusiastic

Initial Comment:
In text windows (only in text windows, I think) the scrollbar-repeat is over-enthusiastic in its repeat behavior. At least: under OSX it is. No matter how short I click in the up/down arrows (or the pageup/pagedown areas) I never seem able to scroll only a single line or page, always at least two.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 00:14

Message:
Logged In: YES 
user_id=45365

Jurjen Bos tracked this one down: we pass a tracker function to 
TrackControl, but also call our hit function again at the end of 
TrackControl. Fixed in Wcontrols.py 1.15 and 1.14.14.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711989&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:20:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:20:27 2004
Subject: [ python-Bugs-991962 ] Building with --disable-toolbox-glue fails
Message-ID: <E1BlEaW-0003zv-00@sc8-sf-web1.sourceforge.net>

Bugs item #991962, was opened at 2004-07-16 00:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Building with --disable-toolbox-glue fails

Initial Comment:
Building with --disable-toolbox-glue fails, because setup.py still 
tries to build lots of MacOSX extension modules (which fails).

There's a define USE_TOOLBOX_OBJECT_GLUE in pyconfig.h that 
shows whether we're building with or without toolbox glue, but 
distutils needs to look at that. If it can, otherwise we need a flag in 
the Makefile too.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:21:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:22:03 2004
Subject: [ python-Bugs-856401 ] Definitive way to link to the correct
	Python.framework
Message-ID: <E1BlEc2-00043H-00@sc8-sf-web1.sourceforge.net>

Bugs item #856401, was opened at 2003-12-08 20:31
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470

Category: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Definitive way to link to the correct Python.framework

Initial Comment:
The link target for Python should be specified by 
introspecting the Python framework itself and linking directly 
to the framework dylib, rather than using -framework and 
overriding the framework search path with -F.  Using -F may 
have undesirable side-effects.  

Example:  User has Python at /Library/Frameworks and 
wants to build an extension module that links to ~/Library/
Frameworks/FooFramework.framework.  User also has a /
Library/Frameworks/FooFramework.framework that they do 
not want to link against.

Solution:  Rather than -framework Python, Python should 
link directly to 
NSBundle.bundleWithIdentifier_('org.python.Python.framewor
k').executablePath().  Stock 10.3 has this located at:
u'/System/Library/Frameworks/Python.framework/Python'.  
The value of this is entirely dependent on the current running 
version of Python that the extension module will be linked 
against.  The dylib identifier will of course be expanded to 
the full /System/Library/Frameworks/Python.framework/
Versions/2.3/Python by the linker.

Caveats:  Example requires PyObjC, however these APIs are 
available in CoreFoundation's CFBundle and could easily be 
put into an extension module if PyObjC is not to be 
distributed with the next version of Python.  It will likely 
require a platform specific patch to distutils.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 00:21

Message:
Logged In: YES 
user_id=45365

The dynamic_lookup fix has superseded this.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-12-09 15:49

Message:
Logged In: YES 
user_id=139309

1) Yeah, it's a little academic, but it solves a problem we have 
without changing the normal link order that a user will probably 
expect.  -F can be wrong too, if PYTHONFRAMEWORKPREFIX is 
compile time.

2) Trust me, it doesn't do more than linking against the dylib inside 
the framework.  There is nothing in the mach-o spec it *could* do, 
unless they add framework specific load commands in OS X 10.4+ 
(doubtful).  I know those header files pretty well and have looked 
at bits and pieces of related darwin source (nm, otool, 
install_name_tool, etc).

3) Yeah the current distutils is a pain in the butt.  I don't like the 
easy change to distutils.  Maybe it fails for a user install version of 
Python if PYTHONFRAMEWORKPREFIX is set at compile time?  I'd 
MUCH rather have this dir come from introspection because then it 
will be correct, for example from a 10.3 SDK on 10.4.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-12-09 14:11

Message:
Logged In: YES 
user_id=45365

Bob, I'm not convinced. First, the problem you sketch seems a bit 
academic (the user linking a Python extension against a 
framework for which one system-wide copy and one per-user copy 
exists), and there is a workaround too (the user adds another -F 
just before their own framework).

Second, I'm not convinced that &quot;-framework Python&quot; doesn't do 
more than just linking against the dylib inside the framework, or 
that it may do so in the future.

Finally, with the current distutils we cannot easily use introspection 
to get the real location of the framework that python is running 
from: distutils picks up this value from the Makefile LDSHARED 
variable, so the only thing we can do without distutils surgery is 
replace

LDSHARED=	$(CC) $(LDFLAGS) -bundle -Wl,-
F$(PYTHONFRAMEWORKPREFIX) -framework 
$(PYTHONFRAMEWORK)

with

LDSHARED=	$(CC) $(LDFLAGS) -bundle 
$(PYTHONFRAMEWORKINSTALLDIR)/$(PYTHONFRAMEWORK)

All in all I'm tempted to close this as &quot;won't fix&quot;, but I'll give you 
another couple of days to convince me otherwise:-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856401&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:23:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:23:45 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BlEdi-000477-00@sc8-sf-web1.sourceforge.net>

Bugs item #990569, was opened at 2004-07-13 19:53
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 18:23

Message:
Logged In: YES 
user_id=33168

Can you reproduce the problem from the python interpreter
w/o the database?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 18:22

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:22:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:28:05 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BlEcu-00045H-00@sc8-sf-web1.sourceforge.net>

Bugs item #990569, was opened at 2004-07-13 19:53
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 18:22

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:29:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:29:20 2004
Subject: [ python-Bugs-838140 ] Unloading extension modules not always safe
Message-ID: <E1BlEj5-0004GY-00@sc8-sf-web1.sourceforge.net>

Bugs item #838140, was opened at 2003-11-07 21:44
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Unloading extension modules not always safe

Initial Comment:
I will look into the solution for this, but the &quot;for now&quot; 
solution would be to never try and unlink bundles because 
they may contain ObjC code.  For several reasons, ObjC 
classes can never be unloaded, so bundles containing ObjC 
code can also never be unloaded.  This is more than a 
problem for just PyObjC, because any arbitrary module may 
contain some ObjC code.  We need to detect this before 
running NSUnlinkModule.  I'll try and put together a patch 
sometime soon if nobody else does, but for now see: http://
sourceforge.net/tracker/?
func=detail&amp;aid=832025&amp;group_id=14534&amp;atid=114534

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 00:29

Message:
Logged In: YES 
user_id=45365

Fixed in dynload_next.c 2.15.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2003-12-05 10:41

Message:
Logged In: YES 
user_id=580910

Another, probably more correct, workaround is to stop alling 
NSUnlinkModule. 

This function is only called when an invalid dynamic object is 
loaded, which should not occur during normal operation. The only 
negative effect of not unloading seems to be that the process 
image is larger than really necessary.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2003-11-25 15:36

Message:
Logged In: YES 
user_id=580910

A quick workaround would be to let pydoc check the type of 
module it tries to load, it currently checks if the file is a binary 
module by checking &quot;if info and 'b' in info[2]&quot; (pydoc.py:171). If it 
would check if the filetype is not C_EXTENSION (3) the problem 
would not arise with pydoc (which probably accounts for &gt;99% of 
the problematic load_module calls).

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2003-11-25 15:18

Message:
Logged In: YES 
user_id=580910

Note that the problem doesn't really have anything to do with 
unloading modules, the problem occurs when trying to unload a 
dylib that doesn't contain the proper init function. See bug 
#848907 (sorry about that one, I didn't look for earlier bug 
reports).

What happens:
- pydoc calls imp.load_module('__temp__', open('_objc.so'), ...)
- load_module loads _objc.so
- load_module tries to find init__temp__ in _objc.so
- nothing is found and therefore load_module calls NSUnlinkModule
- NSUnlinkModule aborts the process because _objc.so contains 
Objective-C definitions

No code in the extension module has any change to fix things 
because the init function is never called.

BTW. The problem also exists in a vanilla Python 2.3 installation on 
Panther, I cleared /Library/Python2.3 and ran 'pydoc -k hello' and 
this also crashed.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-11-14 11:40

Message:
Logged In: YES 
user_id=45365

I think that either the module itself, or the package responsible for 
the module, should forestall unloading (by tucking away an extra 
reference somewhere).

The root of the problem is that the Python refcount doesn't reflect 
the all references to the module: ObjC keeps references too.

OTOH: if all modules containing ObjC code have this problem, and 
it is easy to detect whether a module contains ObjC code then 
adding a safety net to the import code might be a prudent course 
of action.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-11-11 16:16

Message:
Logged In: YES 
user_id=45365

I'm surprised that it does the unload:-)

I think the correct solution would be for the module itself (or 
someone close to it) to stash away a reference. As this is only a 
problem for some modules (those containing ObjC code) I don't 
think a general change is in order.

The real problem is that the &quot;last reference&quot; as Python sees it isn't 
really the last reference: the ObjC runtime also has references to 
stuff in there.


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2003-11-11 15:20

Message:
Logged In: YES 
user_id=139309

it does if you del sys.modules['somemodule'] and somemodule's 
reference count goes to zero.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-11-11 11:51

Message:
Logged In: YES 
user_id=45365

Bob, I'm confused. As far as I know Python never unloads 
extension modules...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:32:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:32:09 2004
Subject: [ python-Bugs-848907 ] pydoc crash on MacOS X
Message-ID: <E1BlElp-0004M8-00@sc8-sf-web1.sourceforge.net>

Bugs item #848907, was opened at 2003-11-25 13:50
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848907&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: pydoc crash on MacOS X

Initial Comment:
pydoc will crash the python interpreter on MacOS X if an 
extension module defines an Objective-C class or category.

The attached tarball contains an example of this, if you build 
the extension module and then run dotest.py the interpreter 
will crash.

The cause for this is the call to 'imp.load_module' in 
pydoc.py. This will load the extension module with __temp__ 
as it's name. load_module will load the executable image, 
search for the init__temp__ function and will then try to 
unload the image because that function is not found. 
Unloading the image (using NSUnloadModule, see 
dynload_next.c) will cause the crash because it is impossible 
to unload executable images that contain an Objective-C 
class or category.

A real world example: install PyObjC and run 'pydoc -k 
hello'.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 00:32

Message:
Logged In: YES 
user_id=45365

This is a duplicate of #838140, so it should be fixed (for 2.4 at least). 
Please give it a try, and reopen the report if the problem still exists.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-11-25 15:06

Message:
Logged In: YES 
user_id=45365

This is a duplicate of &lt;https://sourceforge.net/tracker/?
func=detail&amp;aid=838140&amp;group_id=5470&amp;atid=105470&gt;, but I'm 
leaving it in for the moment as it has a real-life example of when 
modules are unloaded.

Ronald: could you you see whether you agree with my suggestions 
over there that PyObjC modules should solve this themselves (as 
opposed to disabling unloading in general)?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848907&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:38:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:38:58 2004
Subject: [ python-Bugs-795649 ] Recommend TeachText in OSX documentation
Message-ID: <E1BlEsH-0005u9-00@sc8-sf-web4.sourceforge.net>

Bugs item #795649, was opened at 2003-08-27 00:10
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=795649&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Peter Sint (psint)
Assigned to: Jack Jansen (jackjansen)
Summary: Recommend TeachText in OSX documentation

Initial Comment:
http://www.auth.gr/mirrors/python/doc/current/mac/
node5.html

TeachText (MacOSX,certainly in 10.2, probably also 10.1) 
may not be an  optimal editor but it allows to save scripts 
as text only: you may chose &quot;New Document 
Attributes=plain text&quot; in the Preferences.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 00:38

Message:
Logged In: YES 
user_id=45365

Fixed in Doc/mac/using.tex rev. 1.11.

----------------------------------------------------------------------

Comment By: Nicholas Riley (nriley)
Date: 2003-08-31 23:43

Message:
Logged In: YES 
user_id=34933

I think you mean TextEdit, not TeachText... but yes, it can save 
files in plain text, though not by default.

----------------------------------------------------------------------

Comment By: Peter Sint (psint)
Date: 2003-08-29 00:04

Message:
Logged In: YES 
user_id=418324

Sorry: This concerns really TextEdit
(mentioned in above node 5  Macintosh Library Modules  1.1.1 
How to run a Python script ) which allows PlainText by prefs. The 
first versions on OS-10.0 probably did not (or I realized it only 
later). Problems with line endings should be solved in 2.3

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-08-27 10:22

Message:
Logged In: YES 
user_id=45365

I don't seem to have TeachText (on 10.2), are you sure it is part 
of the basic installation?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=795649&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 00:59:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 00:59:55 2004
Subject: [ python-Bugs-976878 ] PDB: unreliable breakpoints on functions
Message-ID: <E1BlFCd-0006bA-00@sc8-sf-web4.sourceforge.net>

Bugs item #976878, was opened at 2004-06-21 09:56
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=976878&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Postponed
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
Assigned to: Nobody/Anonymous (nobody)
Summary: PDB: unreliable breakpoints on functions

Initial Comment:
Breakpoints set on functions are unreliable because 
"pdb.Pdb.checkline" thinks lines inside a 
multi-column docstring were adequate lines for 
breakpoints. 
 
Of course, such breakpoints are ignored during 
execution. 

----------------------------------------------------------------------

Comment By: Ilya Sandler (isandler)
Date: 2004-07-15 15:59

Message:
Logged In: YES 
user_id=971153

I'd like to add that this bug is probably related (but not
identical) to:

bug#926369 &
bug#875404

which are also caused by pdb.checkline()

it might be a good idea to fix all three bugs at once...


----------------------------------------------------------------------

Comment By: Dieter Maurer (dmaurer)
Date: 2004-06-21 09:58

Message:
Logged In: YES 
user_id=265829

Patch attached 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=976878&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 01:20:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 01:20:55 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BlFWg-0005ld-00@sc8-sf-web1.sourceforge.net>

Bugs item #990569, was opened at 2004-07-13 16:53
Message generated for change (Comment added) made by jmuir
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

>Comment By: Justin (jmuir)
Date: 2004-07-15 16:20

Message:
Logged In: YES 
user_id=1083084

Hello,

Damn, I've already changed the default date in my db...hang
on, I'll do it again and send the file....

btw - I tried to reproduce the error in the interpreter by
instantiating a date and a datetime object with that date.
No crash. I wonder if it's something to do with what Access
is passing to Python?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 15:23

Message:
Logged In: YES 
user_id=33168

Can you reproduce the problem from the python interpreter
w/o the database?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 15:22

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 01:56:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 01:56:09 2004
Subject: [ python-Bugs-992017 ] code that generates a segfault on Python
	2.1-2.3
Message-ID: <E1BlG58-0007x5-00@sc8-sf-web4.sourceforge.net>

Bugs item #992017, was opened at 2004-07-15 23:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ted Bach (bachtor)
Assigned to: Nobody/Anonymous (nobody)
Summary: code that generates a segfault on Python 2.1-2.3

Initial Comment:
On a Redhat Linux 9 based system, the following causes
a segfault:


""" In python, you can call any expression.
"""

class foo:
  def __init__(s,times=1):
     s.times = times
  def __call__(s): print s.times
  def __mul__(s,o): return foo(o)
  def __coerce__(s,o):
    if isinstance(o,int):
      return o,s


(foo(3)*10)()   # no segfault
 
(10*foo(3))()   # segfaults
# prints 10

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 01:58:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 02:01:36 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BlG7L-0001Ps-00@sc8-sf-web2.sourceforge.net>

Bugs item #990569, was opened at 2004-07-13 16:53
Message generated for change (Comment added) made by jmuir
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

>Comment By: Justin (jmuir)
Date: 2004-07-15 16:58

Message:
Logged In: YES 
user_id=1083084

Ok, I've attached the file now. 

Hope it helps!


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 16:20

Message:
Logged In: YES 
user_id=1083084

Hello,

Damn, I've already changed the default date in my db...hang
on, I'll do it again and send the file....

btw - I tried to reproduce the error in the interpreter by
instantiating a date and a datetime object with that date.
No crash. I wonder if it's something to do with what Access
is passing to Python?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 15:23

Message:
Logged In: YES 
user_id=33168

Can you reproduce the problem from the python interpreter
w/o the database?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 15:22

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 02:14:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 02:14:44 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BlGN6-0001wW-00@sc8-sf-web2.sourceforge.net>

Bugs item #990569, was opened at 2004-07-13 16:53
Message generated for change (Comment added) made by jmuir
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

>Comment By: Justin (jmuir)
Date: 2004-07-15 17:14

Message:
Logged In: YES 
user_id=1083084

Doh! 

Here's how I reproduced the bug:

1. Started Access 
2. Changed a single date field to 31-Dec-55.
3. Close Access
4. Ran python script to print records...and presto! Crash.


As I look at that date I can't help wondering if it's being
passed back to Python as 2055?


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 16:58

Message:
Logged In: YES 
user_id=1083084

Ok, I've attached the file now. 

Hope it helps!


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 16:20

Message:
Logged In: YES 
user_id=1083084

Hello,

Damn, I've already changed the default date in my db...hang
on, I'll do it again and send the file....

btw - I tried to reproduce the error in the interpreter by
instantiating a date and a datetime object with that date.
No crash. I wonder if it's something to do with what Access
is passing to Python?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 15:23

Message:
Logged In: YES 
user_id=33168

Can you reproduce the problem from the python interpreter
w/o the database?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 15:22

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 02:41:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 02:41:22 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BlGmp-0000dV-00@sc8-sf-web4.sourceforge.net>

Bugs item #990569, was opened at 2004-07-13 19:53
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 20:41

Message:
Logged In: YES 
user_id=33168

It doesn't help me, but I'm not a windows guy anyways. :-)

Is there an extention module for Access?  It seems like the
problem may be there or perhaps it's general to windows. 
You could try contacting whoever distributes the module. 
Hopefully someone else can help.  If you can give me a test
example that demonstrates the problem in the interpreter, I
can try to look into this. 

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 20:14

Message:
Logged In: YES 
user_id=1083084

Doh! 

Here's how I reproduced the bug:

1. Started Access 
2. Changed a single date field to 31-Dec-55.
3. Close Access
4. Ran python script to print records...and presto! Crash.


As I look at that date I can't help wondering if it's being
passed back to Python as 2055?


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 19:58

Message:
Logged In: YES 
user_id=1083084

Ok, I've attached the file now. 

Hope it helps!


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 19:20

Message:
Logged In: YES 
user_id=1083084

Hello,

Damn, I've already changed the default date in my db...hang
on, I'll do it again and send the file....

btw - I tried to reproduce the error in the interpreter by
instantiating a date and a datetime object with that date.
No crash. I wonder if it's something to do with what Access
is passing to Python?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 18:23

Message:
Logged In: YES 
user_id=33168

Can you reproduce the problem from the python interpreter
w/o the database?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 18:22

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 02:50:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 02:50:10 2004
Subject: [ python-Bugs-986795 ] New mandatory 2nd argument to
	site.addsitedir breaks compat
Message-ID: <E1BlGvN-0002zo-00@sc8-sf-web2.sourceforge.net>

Bugs item #986795, was opened at 2004-07-07 14:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Brett Cannon (bcannon)
Summary: New mandatory 2nd argument to site.addsitedir breaks compat

Initial Comment:

  Old .pth files now raise a TypeError, which site.py
does not catch, which causes the import of site.py to fail.

  The new required parameter is also undocumented and,
on a cursory inspection, it is unclear to me what its
purpose is.

  This comes up because Debian allows for a version
neutral site-packages directory, /usr/lib/site-python/,
into which .pth files can be placed.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 20:50

Message:
Logged In: YES 
user_id=33168

Brett, didn't you fix this?  Can it be closed?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-09 19:35

Message:
Logged In: YES 
user_id=357491

Yes, it is my change, but the one call to the function has the argument 
and the function is undocumented so I didn't worry about it.  As for its 
use, it allowed me to get rid of the nasty global variable that every 
function assumed was there for basic sys.path duplication checks.

I have gone ahead and made it optional.

As for the .pth errors, the test suite tests .pth files and the test passes.  
Do you have an example .pth file, JP, that I can test against?  How about 
the traceback of the exception?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:30

Message:
Logged In: YES 
user_id=33168

Brett, did this happen from your changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 04:17:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 04:17:34 2004
Subject: [ python-Bugs-992078 ] test_format fails 2.4a1
Message-ID: <E1BlIHz-00038p-00@sc8-sf-web4.sourceforge.net>

Bugs item #992078, was opened at 2004-07-16 14:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992078&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: roadkill (dharma_roadkill)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_format fails 2.4a1

Initial Comment:

uname -a
OSF1 pikachu.****.com V5.1 2650 alpha
(HP alpha box running Tru64 V5.1B)

Python-2.4a1

make test:
test test_format produced unexpected output:
******************************************
****************************
*** line 2 of actual output doesn't appear in expected 
output after line 1:
+ u'%f' % (1.0,) == u'1,000000' != '1.000000'
******************************************
****************************
no fancy configure options
no locale env variables set


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992078&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 04:23:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 04:23:17 2004
Subject: [ python-Bugs-992081 ] test_unicode fails 2.4a1
Message-ID: <E1BlINV-0003Gg-00@sc8-sf-web4.sourceforge.net>

Bugs item #992081, was opened at 2004-07-16 14:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992081&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: roadkill (dharma_roadkill)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_unicode fails 2.4a1

Initial Comment:

uname -a
OSF1 pikachu.****.com V5.1 2650 alpha
(HP alpha box running Tru64 V5.1B)

Python 2.4a1

make test:
test test_unicode failed -- Traceback (most recent call 
last):
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/test_unicode.py", line 358,
in test_formatting
    
string_tests.MixinStrUnicodeUserStringTest.test_formatti
ng(self)
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/string_tests.py", line 615,
in test_formatting
    self.checkequal('0042.00', '%07.2f', '__mod__', 42)
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/string_tests.py", line 56, i
n checkequal
    realresult
AssertionError: u'0042.00' != u'0042,00'

no fancy env or locale variables set

note: test_format also fails in make test.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992081&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 07:45:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 07:45:47 2004
Subject: [ python-Bugs-968245 ] Python Logging filename & file number 
Message-ID: <E1BlLXS-0007MN-00@sc8-sf-web1.sourceforge.net>

Bugs item #968245, was opened at 2004-06-07 15:49
Message generated for change (Settings changed) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Ryan (superleo303)
Assigned to: Vinay Sajip (vsajip)
Summary: Python Logging filename & file number 

Initial Comment:
I use Freebsd and redhat 9.0 linus at work.

Using Python Logging filename & file number on freebsd
works fine.
When i print a log statement, and have my config
formatter section set like:
[formatter_default]
format=%(asctime)s <%(levelname)s>
<%(module)s:%(lineno)s> %(message)s
datefmt=

On bsd my logs look like:
<INFO> <propmancmd:95> stateOnly is: DE
<INFO> <propmancmd:105>  MEssages .........
<INFO> <propmancmd:107> collecting datasource: 1011
<INFO> <propman:98>   Collectors overwrite existing
pickle files: 0
<INFO> <propman:99>           Collectors run in
multiple threads: 4
<DEBUG> <propman:528> sql is:
...

See, the filename and file number get displayed with
each logging call,

Now, The same exact code run on the same exact version
of python on a linux machine yiedls the lines:

<INFO> <__init__:988> stateOnly is: DE
<INFO> <__init__:988>  MEssages
<INFO> <__init__:988> collecting datasource: 1011
<INFO> <__init__:988>   Collectors overwrite existing
pickle files: 0
<INFO> <__init__:988>           Collectors run in
multiple threads: 4
<DEBUG> <__init__:988> sql is: 
...

So i opened up ./python2.3/logging/__init__.py  line
988 and it seems to be where the problem is.

Can someone take a look at this asap?   I have to run
all my code on linux machines, so now i cant see which
file and which line is making the logging.

To reproduce, get a freebsd and linux machine,
then run a simple script that uses logging config files
and use the above example as your formatter in the
logging confrig file,

BSD should show the filenames and numbers, linux should
show __init__ 988 instead.


----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-15 18:05

Message:
Logged In: YES 
user_id=1058618

Bug is solved. Probably due to the fact that the our sys
admin builds packages and doesnt install python from source,
the package had pyc and pyo files in it for logging/__inti__.py*
once those were deleted, and as root, ran python -O, the
problem was fixed.  Sorry to waste time with a non-bug   :)
This issue is solved.

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-15 12:55

Message:
Logged In: YES 
user_id=1058618

I have tried this on 3 red hat boxes, all the same version
of red hat, and im pretty sure its all the same version of
python, my sys admin builds a python package and installs
that way, ill ask him to install python from source on one
of the machines and see if that helps, if it doesnt, would
you be willing to log into our machine here and test it,
maybe there is something (obvious) you can see that is wrong?

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-15 07:00

Message:
Logged In: YES 
user_id=308438

I tried this on Mandrake Linux 10 (it's a Red Hat variant) 
which has Python 2.3.3, with the expected result:

2004-07-15 07:45:58,258 <INFO> <test:9> This is a inof call.
2004-07-15 07:45:58,282 <WARNING> <test:10> This is a 
warn call.
2004-07-15 07:45:58,282 <ERROR> <test:11> This is a error 
call.

Might there be a problem with your Red Hat or Python 
installation? Have you tried it on several Red Hat boxes?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 15:40

Message:
Logged In: YES 
user_id=1058618

Also,
Here are the versions of python i am using

$ python
Python 2.3.3 (#2, Jan 21 2004, 07:27:38)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>>

$ python
Python 2.3.4 (#2, Jul 12 2004, 09:19:42)
[GCC 3.3.3 [FreeBSD] 20031106] on freebsd5
Type "help", "copyright", "credits" or "license" for more
information.
>>>

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-14 15:31

Message:
Logged In: YES 
user_id=1058618

Hi ,
I have attached a script to reproduce the error, jsut run
./test.py in the folder.

This is what freebsd produces:
$ python ./test.py
2004-07-14 11:29:47,067 <INFO> <test:9> This is a inof call.
2004-07-14 11:29:47,069 <WARNING> <test:10> This is a warn call.
2004-07-14 11:29:47,069 <ERROR> <test:11> This is a error call.

This is what redhat produces:
$ python ./test.py
2004-07-14 11:28:24,812 <INFO> <__init__:988> This is a info
call.
2004-07-14 11:28:24,812 <WARNING> <__init__:988> This is a
warn call.
2004-07-14 11:28:24,812 <ERROR> <__init__:988> This is a
error call.

As you can see, the filename:fileno attributes are different.



----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-07-12 13:35

Message:
Logged In: YES 
user_id=1058618

Sorry, no , i just have been very busy and havent had time
to reproduce the error, 
i promise by tomorrow ill have a small set of scripts  to
reproduce the error.
All the linux boxes, which is 4 of them, are red hat 9.0, so
maybe its only a problem with red hat?
Ill be posting the scripts tomorrow.
Thanks for checking into this 

-Ryan

ps - i wasnt able to send you an email, it said:

<vsajip@users.sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said:
    550 Administrative prohibition

<vsajip@sourceforge.net>: host
mail.sourceforge.net[66.35.250.206] said: 550
    Administrative prohibition


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-05 12:06

Message:
Logged In: YES 
user_id=308438

I'm not able to reproduce these problems under Linux - I only 
have access to Mandrake 10.0 (a Red Hat variant).

Can you upload a script or set of scripts which demonstrates 
the problem?

----------------------------------------------------------------------

Comment By: Ryan (superleo303)
Date: 2004-06-10 17:18

Message:
Logged In: YES 
user_id=1058618

vsajip, i tested on both machines, both machines returned
the same results:

STACKWALKER RESULTS RUN ON LINUX RED HAT 9.0

[rsmith@marge]:~/ned$ cd bin/testing/stackwalk/
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw1.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw2.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw3.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python sw4.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[rsmith@marge]:~/ned/bin/testing/stackwalk$ python getcaller.py
/home/rsmith/ned/bin/testing/stackwalk/sw1.py(4)
/home/rsmith/ned/bin/testing/stackwalk/sw2.py(5)
/home/rsmith/ned/bin/testing/stackwalk/sw3.py(6)
/home/rsmith/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[rsmith@marge]:~/ned/bin/testing/stackwalk$


-------------------------------------------------------------------------

STACKWALKER RESULTS RUN ON FREEBSD 5.2.1-RELEASE-p8

[ryan@dev2]:~/ned$ cd bin/testing/stackwalk/
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw1.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw2.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw3.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python sw4.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python stackwalk.py
[ryan@dev2]:~/ned/bin/testing/stackwalk$ python getcaller.py
/usr/home/ryan/ned/bin/testing/stackwalk/sw1.py(4)
/usr/home/ryan/ned/bin/testing/stackwalk/sw2.py(5)
/usr/home/ryan/ned/bin/testing/stackwalk/sw3.py(6)
/usr/home/ryan/ned/bin/testing/stackwalk/sw4.py(7)
getcaller.py(3)
[ryan@dev2]:~/ned/bin/testing/stackwalk$

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-06-09 09:26

Message:
Logged In: YES 
user_id=308438

The problem appears to be related to some underlying 
problem with sys._getframe(). Can you please download the 
attached stackwalk.tar.gz and run it on both FreeBSD and 
Linux? Please post your findings here, thanks. Note that the 
stackwalk stuff contains no calls to the logging package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968245&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 07:49:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 07:49:41 2004
Subject: [ python-Bugs-986795 ] New mandatory 2nd argument to
	site.addsitedir breaks compat
Message-ID: <E1BlLbF-00009b-00@sc8-sf-web3.sourceforge.net>

Bugs item #986795, was opened at 2004-07-07 11:56
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Brett Cannon (bcannon)
Summary: New mandatory 2nd argument to site.addsitedir breaks compat

Initial Comment:

  Old .pth files now raise a TypeError, which site.py
does not catch, which causes the import of site.py to fail.

  The new required parameter is also undocumented and,
on a cursory inspection, it is unclear to me what its
purpose is.

  This comes up because Debian allows for a version
neutral site-packages directory, /usr/lib/site-python/,
into which .pth files can be placed.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-15 22:49

Message:
Logged In: YES 
user_id=357491

I fixed the argument requirement, but I was waiting to here from JP 
about the TypeError issue since I have no clue where that is coming from 
(tests I have in test_site haven't shown any issue).

If you could double-check my test for .pth files in test_site and say they 
look good I will go ahead and close this.  Otherwise I want to wait a little 
while to give JP a chance to upload a .pth file that is causing trouble.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 17:50

Message:
Logged In: YES 
user_id=33168

Brett, didn't you fix this?  Can it be closed?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-09 16:35

Message:
Logged In: YES 
user_id=357491

Yes, it is my change, but the one call to the function has the argument 
and the function is undocumented so I didn't worry about it.  As for its 
use, it allowed me to get rid of the nasty global variable that every 
function assumed was there for basic sys.path duplication checks.

I have gone ahead and made it optional.

As for the .pth errors, the test suite tests .pth files and the test passes.  
Do you have an example .pth file, JP, that I can test against?  How about 
the traceback of the exception?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 18:30

Message:
Logged In: YES 
user_id=33168

Brett, did this happen from your changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 07:57:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 07:57:28 2004
Subject: [ python-Bugs-988300 ] Compiler warnings for
	Modules/readline.c:flex_complete()
Message-ID: <E1BlLim-0002Kz-00@sc8-sf-web2.sourceforge.net>

Bugs item #988300, was opened at 2004-07-09 16:53
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 3
Submitted By: Brett Cannon (bcannon)
>Assigned to: Brett Cannon (bcannon)
Summary: Compiler warnings for Modules/readline.c:flex_complete()

Initial Comment:
When I compile on my OS X 10.3.4 with Fink's readline 4.3-25 I get 
the following two warnings:

/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c: In 
function `flex_complete':
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: implicit declaration of function `completion_matches'
/Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: 
warning: return makes pointer from integer without a cast

Now, although I have a version greater than 4.2, this only makes 
sense if HAVE_RL_COMPLETION_MATCHES is undefined and thus 
the completion_matches() macro is not being defined (although I 
checked and the headers have a prototype for 
rl_completion_matches() and my readline seems to compile and 
work well enough).

Would a #else statement that defines completion_matches() fit in 
there?  Problem would be the return type for flex_complete() 
might need to be covered as well unless a clever macro can be 
created that returns a char **.

Initially assigned to Michael since he seems to always deal with the 
readline stuff.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-15 22:57

Message:
Logged In: YES 
user_id=357491

OK, that seemed to solve it.  I will fire off a quick email to python-dev to 
see if anyone feels we should try to deal with this or add a mention in 
the README.

Reassigning to myself.  Thanks, Michael, for the help.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-14 03:59

Message:
Logged In: YES 
user_id=6656

Hmm.  Does running 

LDFLAGS=-L/sw/lib ./configure

acheive anything interesting?

Speaking for myself, I'd prefer it if python's build process ignored 
/sw/ entirely by default...

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 12:31

Message:
Logged In: YES 
user_id=357491

Sounds like the right solution.  But unfortunately I don't know how to 
implement the fix either.  Ask on python-dev?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 11:56

Message:
Logged In: YES 
user_id=6656

So I'm guessing that the answer to this is to teach the
configure test to look in /sw/lib, then.  Not sure how to do
that...

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-12 11:46

Message:
Logged In: YES 
user_id=357491

> Oh, er, "good".

If I was wrong to assign it to you feel free to unassign it.

I don't know when it was introduced; it might be old.  I just decided to go 
through my make output and look for any warnings before a1 when out 
the door.  I tend to compile with ``--without-toolbox-glue`` and that 
leads to a ton of output from modules wanting Carbon stuff and throwing 
a fit that they can't link so it just didn't catch my eye.

As for RL_COMPLETION_MATCHES, pyconfig.h has it commented out and 
config.log has test code fail at compilation because it can't find code for 
-lreadline::

configure:17625: checking for rl_completion_matches in -lreadline
configure:17656: gcc -o conftest -g -O2   conftest.c -lreadline -ltermcap 
-ldl  >        &5
ld: can't locate file for: -lreadline

so I end up with::

``ac_cv_lib_readline_rl_completion_matches=no``.

in config.log .

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-12 05:23

Message:
Logged In: YES 
user_id=6656

> Initially assigned to Michael since he seems to always 
> deal with the readline stuff.

Oh, er, "good".

I'm a little confused.  Is this a new thing?  As in, introduced by my 
changes just before 2.4a1?  *Why* is 
HAVE_RL_COMPLETION_MATCHES undefined?  What do config.log 
and pyconfig.h have to say on the matter?

> Would a #else statement that defines completion_matches()
> fit in there?

Not unless we can work out why it's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 10:47:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 10:47:06 2004
Subject: [ python-Bugs-992185 ] test_macostools fails when running from
	source
Message-ID: <E1BlOMw-0003uU-00@sc8-sf-web1.sourceforge.net>

Bugs item #992185, was opened at 2004-07-16 10:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992185&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: test_macostools fails when running from source

Initial Comment:
Test_macos fails when running from source, and possibly only 
when running from source the first time.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992185&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 11:20:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 11:20:14 2004
Subject: [ python-Bugs-765603 ] IDE has dirty sys.argv
Message-ID: <E1BlOsy-0008Fd-00@sc8-sf-web2.sourceforge.net>

Bugs item #765603, was opened at 2003-07-03 23:08
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765603&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE has dirty sys.argv

Initial Comment:
The IDE has a dirty sys.argv, basically what the Finder gave 
it:
&gt;&gt;&gt; import sys
&gt;&gt;&gt; sys.argv
['/Applications/MacPython-2.3/PythonIDE.app/Contents/
Resources/PythonIDE.py', '-psn_0_4456449']
&gt;&gt;&gt; 

This is unexpected to Python users and will make things that 
expect commandline argument (such as &quot;import 
test.autotest&quot;) fail.

The -psn option definitely has to go. Whether we keep 
sys.argv[0] I'm not sure.

Assign back to me if you don't have time.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 11:20

Message:
Logged In: YES 
user_id=45365

This appears to have been fixed at some point.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765603&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 11:21:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 11:21:45 2004
Subject: [ python-Bugs-992207 ] exec statement balks at CR/LF
Message-ID: <E1BlOuU-0005Yr-00@sc8-sf-web1.sourceforge.net>

Bugs item #992207, was opened at 2004-07-16 09:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992207&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec statement balks at CR/LF

Initial Comment:
Under Linux and MacOS (no others tested), if "foo.py" is a DOS/
Windows style Python file (CR/LF line endings), then

  python foo.py

will work, as will

  execfile("foo.py")

and

  exec file("foo.py")

from inside Python. However,

   exec file("foo.py").read()

will report a syntax error. In other words, the parser seems to 
accept CR/LF only if the source of the data is a file, not a string.

When running under Linux and MacOS (no others tested), the exec 
statement reports a syntax error. I didn't find anything about this 
in the documentation, so I don't know if it's a bug or a feature. If 
it's a feature, it is not a useful one!



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992207&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 11:32:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 11:32:27 2004
Subject: [ python-Bugs-696527 ] Carbon.CF module needs new style classes
Message-ID: <E1BlP4p-0006hY-00@sc8-sf-web3.sourceforge.net>

Bugs item #696527, was opened at 2003-03-03 14:01
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696527&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.CF module needs new style classes

Initial Comment:
Carbon.CF is the only Mac toolbox module that hasn't been converted to new-style classes yet, even though it is probably the one that would benefit most.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 11:32

Message:
Logged In: YES 
user_id=45365

Fixed for 2.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=696527&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 12:44:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 12:44:09 2004
Subject: [ python-Bugs-653871 ] Investigate weak linking
Message-ID: <E1BlQCD-00019k-00@sc8-sf-web3.sourceforge.net>

Bugs item #653871, was opened at 2002-12-14 23:24
Message generated for change (Settings changed) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653871&group_id=5470

Category: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Out of Date
Priority: 2
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Investigate weak linking

Initial Comment:
We should investigate weak linking (Apple technote 2064) as a way to make a binary Python distribution compatible with older MacOSX releases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653871&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 12:48:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 12:48:51 2004
Subject: [ python-Bugs-766210 ] Mac/OSX/Makefile assumes case-insensitive
	build
Message-ID: <E1BlQGl-0000kd-00@sc8-sf-web4.sourceforge.net>

Bugs item #766210, was opened at 2003-07-05 01:33
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766210&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Mac/OSX/Makefile assumes case-insensitive build

Initial Comment:
Mac/OSX/Makefile doesn't work on a case-sensitive 
filesystem, because it assumes that python.exe exists. 
Here's a fragment of an email conversation on the topic:
----------------
1) In the top level Makefile, BUILDEXE is set depending on 
whether the filesystem is case insensitive or not.  However, 
Mac/OSX/Makefile always assumes case-insensitivity, so 
there can be a conflict if python is built under Mac OS X on 
UFS or NFS.

This is unintentional. But: I don't have a UFS file system 
handy right now, and visual inspection
of Mac/OSX/Makefile hasn't revealed any obvious things. 
Could you elaborate? If all else fails send me the diff, after 
going through the release process.

Sorry I wasn't more clear.  It is the following line in Mac/
OSX/Makefile that is the problem:

BUILDPYTHON=$(builddir)/python.exe

This expects the top level Makefile to have added a .exe 
suffix, which would only happen if a case-insensitive 
filesystem was detected.
--------------

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 12:48

Message:
Logged In: YES 
user_id=45365

Tried a build on a UFS filesystems and there were no problems: the 
toplevel Makefile communicates the correct BUILDPYTHON to Mac/OSX/
Makefile.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-21 23:45

Message:
Logged In: YES 
user_id=45365

I am at loss to why this problem still exists. On inspection it 
seems to be a duplicate of #677753, which was fixed 6 months 
ago, so the problem shouldn't have showed up in 2.3b2.

I will not fix this bug for 2.3, and try to find out what is going on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766210&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 13:19:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 13:20:00 2004
Subject: [ python-Bugs-870382 ] Mingw needs to use the same MSVC runtime as
	Python
Message-ID: <E1BlQkp-0004Wv-00@sc8-sf-web2.sourceforge.net>

Bugs item #870382, was opened at 2004-01-04 15:55
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470

Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: Mingw needs to use the same MSVC runtime as Python

Initial Comment:
Python 2.4 is now built with MSVC 7.1, which uses a 
new MSVC runtime library.

Extension DLLs should be built to use the same runtime 
DLL as Python itself (although it has not been possible 
to find a real-world example where not doing so causes 
a problem...)

The attached patch adds the appropriate -l flag to the 
link, based on the MSVC version reported in sys.version. 
(This has only been tested with a Python built with 
MSVC 7.1, the version number used for MSVC 7.0 is 
based on verbal reports only).

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-16 13:19

Message:
Logged In: YES 
user_id=11105

In principle, it would be possible to examine the import
table of pythonxy.dll, to find out to which msvcrXX.dll it
is linked to.


----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-07-15 06:40

Message:
Logged In: YES 
user_id=552329

FWIW, this patch works for me, and I'd definitely like to
see it in 2.4a2.  If the MSVC version isn't 1300 or 1310
(the theoretical 1400, for example), then it doesn't do
anything different to what 2.4a1 does, so it's hard to see
why that would be a problem (and with the patch applied,
there's a clear fix, just adding in the appropriate elif and
link - it's not like new versions come along all the time).

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-09 13:17

Message:
Logged In: YES 
user_id=113328

This is still an issue with 2.4a1. I'm not sure what the 
autodetection buys given that currently it's not possible to 
build extensions with 2.4a1 using mingw which are compatible 
with the stock python.org binary.

Can I suggest that this patch be applied, and issues around 
autodetection be deferred until there is a demonstrated need?

I've uploaded a revised patch for 2.4a1 (tested against the 
python.org supplied MSI).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-05 22:30

Message:
Logged In: YES 
user_id=21627

I'm primarily concerned about future
(unreleased-as-of-today) MSC versions; they likely have
version numbers like "1400"; linking msvcr71 to binaries
built with that compiler is likely wrong.

Not adding anything for gcc-built python versions is fine.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-05 00:01

Message:
Logged In: YES 
user_id=113328

What about Python built with mingw? I don't think that's 
possible right now, but I'd expect people to work on it. And 
I've no idea what sys.version for that would be.

The only real cases are likely to be MSVC 7.1 (Python 2.4, 
binary dist), MSVC 6 (Python <= 2.3, binary dist) and hand-
built Python versions. The patch does the right thing for all 
the binary distributions, which are the ones where the user 
can't be assumed to know how to hack things to make them 
work.

For hand-built versions, the user can do "python setup.py 
build_ext --compiler=mingw32 -l msvcr71" (or whatever) to 
manually specify the runtime to use. Leaving the default as 
msvcrt (the CRT that comes with the OS, and is default for 
mingw) seems right - and better than aborting (particularly as 
I'm not sure how to check whether there's an -l option for 
the CRT specified by the user).

The best I could do is effectively to force build_ext to fail 
unless Python was built with MSVC, which seems unhelpful...

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-04 16:03

Message:
Logged In: YES 
user_id=21627

Could you add some kind of assertion to detect the case that
an entirely different compiler version is used? It would be
best if it gets the case of using MSVC6 right, and gives up
if some other compiler version is detected (I can't
determine os.version for the VC6 case right now, but Python
2.3 is built with it).

Apart from that, the patch looks good.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 13:25:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 13:25:35 2004
Subject: [ python-Bugs-839865 ] MacPython installer: disk image does not
	mount from NFS
Message-ID: <E1BlQqJ-0002H9-00@sc8-sf-web4.sourceforge.net>

Bugs item #839865, was opened at 2003-11-11 12:21
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839865&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: MacPython installer: disk image does not mount from NFS

Initial Comment:
Bill Janssen reports that the MacPython installer disk images 
(.dmg files) fail to mount, with error -199. It turns out his 
home directory is NFS-mounted. Other dmg files pose no 
problems.

It could be that this has to do with the fact that we use our 
own tool to create the dmg images in stead of Apple's tools.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 13:25

Message:
Logged In: YES 
user_id=45365

Just tried it with the current installer and everything seems to work fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839865&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 13:45:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 13:45:28 2004
Subject: [ python-Bugs-779167 ] urllib proxy handling incomplete for MacOSX
Message-ID: <E1BlR9T-0002ll-00@sc8-sf-web1.sourceforge.net>

Bugs item #779167, was opened at 2003-07-28 23:10
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779167&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: urllib proxy handling incomplete for MacOSX

Initial Comment:
Urllib has code to handle both unix-style environment-based 
proxy definitions and mac-style Internet Config based ones 
(along with some others), but on MacOSX only the 
environment-style ones are enabled.

It needs to use the IC-based ones too, as this is the way to 
access the settings made by the user through the System 
Preferences application.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 13:45

Message:
Logged In: YES 
user_id=45365

Fixed in urllib 1.163.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779167&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 14:36:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 14:36:39 2004
Subject: [ python-Bugs-775878 ] PythonLauncher has empty popup for
	interpreters
Message-ID: <E1BlRx4-0005jU-00@sc8-sf-web3.sourceforge.net>

Bugs item #775878, was opened at 2003-07-22 22:59
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775878&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PythonLauncher has empty popup for interpreters

Initial Comment:
The PythonLauncher preferences window has a popup which 
allows you to select the interpreter to use for the various 
file types. This popup is empty, however. The default is set, 
though, so this isn't a critical error.

Discovered on Panther, so it could be a problem there only. 
But I vaguely remember that I never actually wrote the 
code:-)

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 14:36

Message:
Logged In: YES 
user_id=45365

Fixed in PreferencesWindowController.m rev. 1.6

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775878&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 14:41:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 14:41:08 2004
Subject: [ python-Bugs-765903 ] bundlebuilder Info.plist files.
Message-ID: <E1BlS1N-0005ti-00@sc8-sf-web3.sourceforge.net>

Bugs item #765903, was opened at 2003-07-04 14:11
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: bundlebuilder Info.plist files.

Initial Comment:
Spotted by Edward Moy:
-----------
8) In BuildApplet.app/Contents/Info.plist, the 
CFBundleIdentifier needs to be a reverse-dns format 
(org.python.BuildApplet; in the WWDC preview, I have 
accidentally made it com.apple.BuildApplet).  It also needs a 
CFBundleShortVersionString entry (I just used 1.0 for the 
WWDC preview).
------------

This needs a couple of changes, really:
- bundlebuilder needs a way to specify these, plus sensible 
defaults.
- the same for BuildApplet, when it calls bundlebuilder
- Mac/OSX/Makefile needs to be adapted to use the new 
options.

If you don't have the time to fix all of these please go as far 
as you can and reassign back to me.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 14:41

Message:
Logged In: YES 
user_id=45365

It appears this is all fixed.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-07 12:08

Message:
Logged In: YES 
user_id=45365

Yes, I guess you're right. bundlebuilder should put valid default 
values in the plist files and that's it. Our applets will just have to 
come with their own plist files. So I'd say rip out the bundle_id 
option but put in a valid bundle ID and version number, and please 
either create plist files for our applets (and use these in Mac/OSX/
Makefile) or put in a bug report to that effect on my name.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-07-04 18:24

Message:
Logged In: YES 
user_id=92689

Oops, you're right, I was too fast: I indeed didn't do BuildApplet or 
CFBundleShortVersionString.

I'm worried about bundlebuilder feature-bloat, though: the net --
bundle-id flag is only a convenience to avoid creating an explicit 
plist. BuildApplet could easily create the plist &quot;manually&quot;, and that 
would in fact be the more general solution, so I'm tempted to rip 
--bundle-id out again.

Do all bundles *have* to specify CFBundleShortVersionString? If 
so, should bundlebuilder simply use &quot;1.0&quot; if it's not specified in the 
plist?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-04 17:29

Message:
Logged In: YES 
user_id=45365

I got the impression that you only did step 1 (bundlebuilder), not 
BuildApplet and Mac/OSX/Makefile, right? Also, did you do the 
CFBundleShortVersionString bit too?

Again, reassign to me if you don't feel like hacking this.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-07-04 16:22

Message:
Logged In: YES 
user_id=92689

Done, except they're named bundle_id and --bundle-id.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-07-04 15:28

Message:
Logged In: YES 
user_id=92689

IMO the sensible default is what we have now (and what a _lot_ of 
commercial apps do as well, just have a look at ~/Library/
Preferences/*.plist). For the applets shipping with Python it would 
indeed be much better if the bundle id started with &quot;org.python.&quot;. I 
suggest to add a --bundle-identifier switch (and a bundle_identifier 
kwarg). I will do this unless you disagree.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 15:45:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 15:45:15 2004
Subject: [ python-Bugs-992017 ] code that generates a segfault on Python
	2.1-2.3
Message-ID: <E1BlT1R-0002JS-00@sc8-sf-web2.sourceforge.net>

Bugs item #992017, was opened at 2004-07-16 00:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ted Bach (bachtor)
Assigned to: Nobody/Anonymous (nobody)
Summary: code that generates a segfault on Python 2.1-2.3

Initial Comment:
On a Redhat Linux 9 based system, the following causes
a segfault:


""" In python, you can call any expression.
"""

class foo:
  def __init__(s,times=1):
     s.times = times
  def __call__(s): print s.times
  def __mul__(s,o): return foo(o)
  def __coerce__(s,o):
    if isinstance(o,int):
      return o,s


(foo(3)*10)()   # no segfault
 
(10*foo(3))()   # segfaults
# prints 10

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-16 14:45

Message:
Logged In: YES 
user_id=6656

Isn't this likely to be a dup of bug 

[ 980352 ] coercion results used dangerously

?  I haven't thought about either very hard, but both involve 
__coerce__ and core dumps...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 16:48:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 16:48:31 2004
Subject: [ python-Bugs-768391 ] hardcoded python paths
Message-ID: <E1BlU0b-0004u3-00@sc8-sf-web2.sourceforge.net>

Bugs item #768391, was opened at 2003-07-09 13:39
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768391&group_id=5470

Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Tiago Castro Henriques (tiagoh)
Assigned to: Jack Jansen (jackjansen)
Summary: hardcoded python paths

Initial Comment:
I tried to use the new version of idle that is now
integrated into 2.3b2, but I got an error when I tried
to run /usr/local/lib/python2.3/idlelib/idle:

% /usr/local/lib/python2.3/idlelib/idle
Traceback (most recent call last):
  File &quot;./idle&quot;, line 8, in ?
    import PyShell
  File &quot;./PyShell.py&quot;, line 19, in ?
    from Tkinter import *
  File &quot;/usr/lib/python2.2/lib-tk/Tkinter.py&quot;, line 35,
in ?
    import _tkinter # If this fails your Python may not
be configured for Tk
ImportError: No module named _tkinter

I'm using python2.3b2 on MacOSX 10.2.6, compiled from
source with standard options.

Apparently the builtin 2.2 version of Python is being
used, even though $PYTHONHOME is not set (according to
the manpages, this should make it default to
/usr/local, and not /usr as seems to be the case).

This is due to the fact that this executable script
contains a shebang declaration with a hardcoded python
path:

% head -1 /usr/local/lib/python2.3/idlelib/idle
#!/usr/bin/python

This should be replaced by the standard shebang
declaration:
#! /usr/bin/env python

I checked to see if there were any other *.py files in
/usr/local/lib/python2.3 suffering from similar
problems, and found the following files to be affected:

/usr/local/lib/python2.3/cgi.py:
#! /usr/local/bin/python
/usr/local/lib/python2.3/test/test_bz2.py:
#!/usr/bin/python
/usr/local/lib/python2.3/test/test_largefile.py:
#!python
/usr/local/lib/python2.3/test/test_optparse.py:
#!/usr/bin/python

The files /usr/local/bin/idle, /usr/local/bin/pydoc and
/usr/local/bin/pycolor also have a hardcoded python path:
% head -1 idle pycolor pydoc
==&gt; idle &lt;==
#!/usr/local/bin/python

==&gt; pycolor &lt;==
#!/usr/local/bin/python

==&gt; pydoc &lt;==
#!/usr/local/bin/python

These should similarly be changed to #! /usr/bin/env python


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 16:48

Message:
Logged In: YES 
user_id=45365

Idle on MacOSX isn't run from the commandline: you doubleclick the icon 
in the finder. And what gets launched then is an applet, which doesn't 
look at #! paths or anything.

If you want to run idle from the command line you could do that, but you 
would have to use #!/usr/bin/pythonw, not #!/usr/bin/python.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-09-10 05:11

Message:
Logged In: YES 
user_id=149084

Refer to Python Bug 775061 (closed)

idlelib/idle  script has been removed since the
idle script is now in Tools/scripts and at least
the Linux installation is setting the shebang correctly.

Also, the shebang has been removed from idlelib/idle.py.

I don't know how OSX handles the script installation
so I'm referring this to Jack Jansen in case there is
a further problem.  How does IDLE start on OSX 
these days?  Is there any problem backporting the
deletions to 2.3 maint?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768391&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 16:53:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 16:53:38 2004
Subject: [ python-Bugs-768068 ] Explicit interp reference during build fails
Message-ID: <E1BlU5M-0002DM-00@sc8-sf-web1.sourceforge.net>

Bugs item #768068, was opened at 2003-07-08 23:44
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: Explicit interp reference during build fails

Initial Comment:
I think this is MacPython-specific and not just a general
Python build issue.  If I explicitly reference the Python
executable when building an out-of-tree extension module I
get an error building the .so file because it stripped the
dirname() of the python.exe file.

Here's a simple example.  I have a directory with a single
extension module and simple setup.py.  I want to build it
with

    ~/src/python/head/dist/src/build.pg/python.exe 

Compilation works fine.  Linkage bombs.

    % pwd
    /Users/skip/src/PyExtensions1.5/python2.2
    montanaro:python2.2% ls -l
    total 8
    -rw-r--r--    1 skip     staff        1318 Jan 21  2002 
llopmodule.c
    -rw-rw-r--    1 skip     staff         114 Jan 21  2002 
setup.py
    montanaro:python2.2% cat setup.py
    from distutils.core import setup, Extension
    setup(name=&quot;llop&quot;, ext_modules=[Extension(&quot;llop&quot;, 
[&quot;llopmodule.c&quot;])])
    montanaro:python2.2% ~/src/python/head/dist/src/
build.pg/python.exe setup.py build
    running build
    running build_ext
    building 'llop' extension
    creating build
    creating build/temp.darwin-6.6-Power_Macintosh-2.3
    gcc -pg -fno-strict-aliasing -Wno-long-double -no-cpp-
precomp -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/
Users/skip/src/python/head/dist/src/Include -I/Users/skip/
src/python/head/dist/src/build.pg -c llopmodule.c -o build/
temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o
    creating build/lib.darwin-6.6-Power_Macintosh-2.3
    gcc -pg -bundle -bundle_loader python.exe build/
temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o -o 
build/lib.darwin-6.6-Power_Macintosh-2.3/llop.so
    ld: can't open: python.exe (No such file or directory, 
errno = 2)
    error: command 'gcc' failed with exit status 1


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-16 16:53

Message:
Logged In: YES 
user_id=45365

Skip,
I think this problem has gone away as a side-effect of the new way to 
create extension modules, at least if you make sure you have 
MACOSX_TARGET_PLATFORM=10.3 in your environment when configuring 
and building python.

Could you try, please, and close the report if this appears to work for 
you? Otherwise please reassign back to me.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-21 23:00

Message:
Logged In: YES 
user_id=45365

This won't be fixed for 2.3, after discussion on python-dev it 
seems the situation is not so common, so it can wait for 2.3.1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 17:09:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 17:09:37 2004
Subject: [ python-Bugs-992389 ] attribute error after non-from import
Message-ID: <E1BlUL7-0003cc-00@sc8-sf-web3.sourceforge.net>

Bugs item #992389, was opened at 2004-07-16 15:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992389&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: attribute error after non-from import

Initial Comment:
This bug applied to 2.3 and 2.4. It probably applies to
earlier versions, but who cares? :)

Under some circumstances, code like:

  import eek.foo.baz
  y = eek.foo.baz.y

fails with an attribute error for "foo" if foo is still
being imported.

I've attached a zip file of a demo package "eek" that
demonstrates the problem.  If you unzip the package and:

  import eek.foo

you'll get the attribute error described above.

I think the problem is that eek's foo attribute isn't
set until the import of foo is finished.  This is too late.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992389&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 17:12:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 17:12:24 2004
Subject: [ python-Bugs-902628 ] doctest confused by super-instances in
	class-dicts
Message-ID: <E1BlUNk-0005va-00@sc8-sf-web2.sourceforge.net>

Bugs item #902628, was opened at 2004-02-23 07:10
Message generated for change (Comment added) made by edloper
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902628&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Tanzer (tanzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest confused by super-instances in class-dicts

Initial Comment:
In Python 2.3.3, doctest chokes on classes which
contain an attribute of type super: 

Traceback (most recent call last):
  File "/ttt/private/tanzer/temp/confuse_doctest.py",
line 14, in ?
    import doctest, confuse_doctest
  File
"/Node/tttprime/ttt/private/tanzer/temp/confuse_doctest.py",
line 15, in ?
    doctest.testmod(confuse_doctest)
  File "/usr/lib/python2.3/doctest.py", line 1148, in
testmod
    f, t = tester.rundict(m.__dict__, name, m)
  File "/usr/lib/python2.3/doctest.py", line 908, in
rundict
    f2, t2 = self.__runone(value, name + "." + thisname)
  File "/usr/lib/python2.3/doctest.py", line 1069, in
__runone
    return self.rundoc(target, name)
  File "/usr/lib/python2.3/doctest.py", line 828, in rundoc
    f2, t2 = self.run__test__(d, name)
  File "/usr/lib/python2.3/doctest.py", line 937, in
run__test__
    raise TypeError("Tester.run__test__: values in "
TypeError: Tester.run__test__: values in dict must be
strings, functions, methods, or classes; <super: <class
'A'>, NULL>

A simple example triggering the bug is attached.

Python 2.3.3 (#2, Jan 13 2004, 00:47:05) 
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2



----------------------------------------------------------------------

Comment By: Edward Loper (edloper)
Date: 2004-07-16 11:12

Message:
Logged In: YES 
user_id=195958

The problem is that inspect.get_class_attrs()'s "method" 
classification is a bit hetergeneous: it contains methods, 
and any method descriptors *except* classmethod and 
staticmethod.  The proposed patch will fix behavior for 
super(), but not for any other method descriptors.  So 
perhaps it would be better to explicitly test "_isfunction(v) 
or _ismethod(v)" rather than "not isinstance(value, 
super)".


----------------------------------------------------------------------

Comment By: Christian Tanzer (tanzer)
Date: 2004-02-23 07:15

Message:
Logged In: YES 
user_id=2402

I patched doctest.py to avoid the traceback (see attached
patch-file). I'm not sure if this is the right place to fix
the bug, though. Maybe inspect.classify_class_attrs should
be changed instead?

The second chunk of the patch improves the traceback given
by doctest by giving the name of the offending dict-item.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902628&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 17:18:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 17:18:48 2004
Subject: [ python-Bugs-992397 ] variable reuse in the logging module
Message-ID: <E1BlUU2-00044F-00@sc8-sf-web3.sourceforge.net>

Bugs item #992397, was opened at 2004-07-16 17:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992397&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gintautas Miliauskas (gintautasm)
Assigned to: Nobody/Anonymous (nobody)
Summary: variable reuse in the logging module

Initial Comment:
I accidentally tried to pass logging levels as strings
to Logger.log() instead of numbers. The result was that
%(levelname)s produced the number of the level
specified and %(levelno)s produced the name... I
assumed that passing strings was valid, because if you
passed an unregistered level name, the %(levelname)s
would just say 'Level XYZ' instead of 'XYZ'.

The culprit is this dict in logging/__init__.py:

_levelNames = {
    CRITICAL : 'CRITICAL',
    ERROR : 'ERROR',
    WARNING : 'WARNING',
    INFO : 'INFO',
    DEBUG : 'DEBUG',
    NOTSET : 'NOTSET',
    'CRITICAL' : CRITICAL,
    'ERROR' : ERROR,
    'WARN' : WARNING,
    'WARNING' : WARNING,
    'INFO' : INFO,
    'DEBUG' : DEBUG,
    'NOTSET' : NOTSET,
}

I think it would be a good idea to split this dict into
two, so that such confusion doesn't result. Also, it
should be explicitly stated (in the docs and maybe in
code too) if a name of the level as a string argument
to Logger.log() is valid or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992397&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 17:19:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 17:19:37 2004
Subject: [ python-Bugs-992397 ] variable reuse in the logging module
Message-ID: <E1BlUUn-00046t-00@sc8-sf-web3.sourceforge.net>

Bugs item #992397, was opened at 2004-07-16 17:18
Message generated for change (Settings changed) made by gintautasm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992397&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 1
Submitted By: Gintautas Miliauskas (gintautasm)
Assigned to: Nobody/Anonymous (nobody)
Summary: variable reuse in the logging module

Initial Comment:
I accidentally tried to pass logging levels as strings
to Logger.log() instead of numbers. The result was that
%(levelname)s produced the number of the level
specified and %(levelno)s produced the name... I
assumed that passing strings was valid, because if you
passed an unregistered level name, the %(levelname)s
would just say 'Level XYZ' instead of 'XYZ'.

The culprit is this dict in logging/__init__.py:

_levelNames = {
    CRITICAL : 'CRITICAL',
    ERROR : 'ERROR',
    WARNING : 'WARNING',
    INFO : 'INFO',
    DEBUG : 'DEBUG',
    NOTSET : 'NOTSET',
    'CRITICAL' : CRITICAL,
    'ERROR' : ERROR,
    'WARN' : WARNING,
    'WARNING' : WARNING,
    'INFO' : INFO,
    'DEBUG' : DEBUG,
    'NOTSET' : NOTSET,
}

I think it would be a good idea to split this dict into
two, so that such confusion doesn't result. Also, it
should be explicitly stated (in the docs and maybe in
code too) if a name of the level as a string argument
to Logger.log() is valid or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992397&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 18:24:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 18:25:00 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BlVVL-0005ud-00@sc8-sf-web1.sourceforge.net>

Bugs item #990569, was opened at 2004-07-13 16:53
Message generated for change (Comment added) made by jmuir
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

>Comment By: Justin (jmuir)
Date: 2004-07-16 09:24

Message:
Logged In: YES 
user_id=1083084

Mornin'!


Well, I'm thinking that it may be simpler to send you a copy
of the table/db and the offending code. Do you have access
to a M$ platform?

Justin

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 17:41

Message:
Logged In: YES 
user_id=33168

It doesn't help me, but I'm not a windows guy anyways. :-)

Is there an extention module for Access?  It seems like the
problem may be there or perhaps it's general to windows. 
You could try contacting whoever distributes the module. 
Hopefully someone else can help.  If you can give me a test
example that demonstrates the problem in the interpreter, I
can try to look into this. 

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 17:14

Message:
Logged In: YES 
user_id=1083084

Doh! 

Here's how I reproduced the bug:

1. Started Access 
2. Changed a single date field to 31-Dec-55.
3. Close Access
4. Ran python script to print records...and presto! Crash.


As I look at that date I can't help wondering if it's being
passed back to Python as 2055?


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 16:58

Message:
Logged In: YES 
user_id=1083084

Ok, I've attached the file now. 

Hope it helps!


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-15 16:20

Message:
Logged In: YES 
user_id=1083084

Hello,

Damn, I've already changed the default date in my db...hang
on, I'll do it again and send the file....

btw - I tried to reproduce the error in the interpreter by
instantiating a date and a datetime object with that date.
No crash. I wonder if it's something to do with what Access
is passing to Python?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 15:23

Message:
Logged In: YES 
user_id=33168

Can you reproduce the problem from the python interpreter
w/o the database?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 15:22

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 18:45:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 18:45:59 2004
Subject: [ python-Bugs-883283 ] bundlebuilder --lib mishandles frameworks
Message-ID: <E1BlVqH-0001J9-00@sc8-sf-web2.sourceforge.net>

Bugs item #883283, was opened at 2004-01-23 12:44
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883283&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder --lib mishandles frameworks

Initial Comment:
The bundlebuilder command-line argument --lib is supposed to be able to include frameworks in the resulting Mac app. Unfortunately, the aliases in the resulting framework copy are all broken.

For an example of this, use --lib to include Tcl.framework and then look through the framework in the resulting application package. Frameworks normally have quite a few handy aliases (such as .../Versions/Current) and all the aliases I tried were broken.

I'm not entirely sure if this actually breaks anything. The one app I've managed to build with standalone=True and use of --lib to include the Tk and Tcl frameworks runs fine on my Mac (which has Python, Tcl and Tk frameworks installed) but fails with "True undefined" on another Mac running Jaguar that I happened to have handy.

This 2nd problem may be a separate bug or user error on my part. I'm not yet sure.

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-07-16 09:45

Message:
Logged In: YES 
user_id=431773

I see. I also can follow the links using the unix command line. However, I 
cannot follow them using Finder. The links in the original packages *can* be 
followed in Finder, which is why I thought things were seriously broken.

So there is a bug in bundlebuilder (or it is exposing a bug in Finder), but its 
more cosmetic than functional. Still...it'd be nice to have normal Finder 
navigation work if the problem is fixable.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 08:24

Message:
Logged In: YES 
user_id=45365

I cannot repeat this, neither with 2.4a1 nor with 2.3: I always get 
symlinks where they are expected. I tried the following command line 
(with test.py being a simple hello world script), on MacOS 10.3.4 with 
apple-installed Python:

/usr/bin/python /System/Library/Frameworks/Python.framework/
Versions/2.3/lib/python2.3/plat-mac/bundlebuilder.py -m test.py --lib /
Library/Frameworks/Tcl.framework build

and I got symlinks just fine. Feel free to reopen the bug report if you 
have more info.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883283&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 21:20:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 21:20:30 2004
Subject: [ python-Bugs-992078 ] test_format fails 2.4a1
Message-ID: <E1BlYFp-0004ud-00@sc8-sf-web1.sourceforge.net>

Bugs item #992078, was opened at 2004-07-16 04:17
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992078&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: roadkill (dharma_roadkill)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_format fails 2.4a1

Initial Comment:

uname -a
OSF1 pikachu.****.com V5.1 2650 alpha
(HP alpha box running Tru64 V5.1B)

Python-2.4a1

make test:
test test_format produced unexpected output:
******************************************
****************************
*** line 2 of actual output doesn't appear in expected 
output after line 1:
+ u'%f' % (1.0,) == u'1,000000' != '1.000000'
******************************************
****************************
no fancy configure options
no locale env variables set


----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-07-16 21:20

Message:
Logged In: YES 
user_id=129426

I can confirm this. It is caused by test__locale that is
executed before test_format (and also, test_unicode fails
likewise). See:

Not only test_format but also test_unicode fail on my
Mandrake 10 box.
My default locale is nl_NL. Behold:

[irmen@atlantis Python-2.4a1]$ cat testcases.in
test__locale
test_format
test_unicode

[irmen@atlantis Python-2.4a1]$ ./python Lib/test/regrtest.py
-f testcases.in
test__locale
test_format
test test_format produced unexpected output:
**********************************************************************
*** line 2 of actual output doesn't appear in expected
output after line 1:
+ u'%f' % (1.0,) == u'1,000000' != '1.000000'
**********************************************************************
test_unicode
test test_unicode failed -- Traceback (most recent call last):
  File
"/home/irmen/BUILD/Python-2.4a1/Lib/test/test_unicode.py",
line 358, in test_formatt             ing
   
string_tests.MixinStrUnicodeUserStringTest.test_formatting(self)
  File
"/home/irmen/BUILD/Python-2.4a1/Lib/test/string_tests.py",
line 615, in test_formatt             ing
    self.checkequal('0042.00', '%07.2f', '__mod__', 42)
  File
"/home/irmen/BUILD/Python-2.4a1/Lib/test/string_tests.py",
line 56, in checkequal
    realresult
AssertionError: u'0042.00' != u'0042,00'

1 test OK.
2 tests failed:
    test_format test_unicode
[irmen@atlantis Python-2.4a1]$


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992078&group_id=5470
From noreply at sourceforge.net  Fri Jul 16 21:21:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 16 21:21:59 2004
Subject: [ python-Bugs-992081 ] test_unicode fails 2.4a1
Message-ID: <E1BlYHL-0004yF-00@sc8-sf-web1.sourceforge.net>

Bugs item #992081, was opened at 2004-07-16 04:23
Message generated for change (Comment added) made by irmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992081&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: roadkill (dharma_roadkill)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_unicode fails 2.4a1

Initial Comment:

uname -a
OSF1 pikachu.****.com V5.1 2650 alpha
(HP alpha box running Tru64 V5.1B)

Python 2.4a1

make test:
test test_unicode failed -- Traceback (most recent call 
last):
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/test_unicode.py", line 358,
in test_formatting
    
string_tests.MixinStrUnicodeUserStringTest.test_formatti
ng(self)
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/string_tests.py", line 615,
in test_formatting
    self.checkequal('0042.00', '%07.2f', '__mod__', 42)
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/string_tests.py", line 56, i
n checkequal
    realresult
AssertionError: u'0042.00' != u'0042,00'

no fancy env or locale variables set

note: test_format also fails in make test.



----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-07-16 21:21

Message:
Logged In: YES 
user_id=129426

I can confirm this.
It is caused by test__locale that is executed before this
test. This also causes test_format to fail.
Additional details in my comment on the test_format
bugreport #992078 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992081&group_id=5470
From noreply at sourceforge.net  Sat Jul 17 00:19:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 17 00:19:28 2004
Subject: [ python-Bugs-992081 ] test_unicode fails 2.4a1
Message-ID: <E1Blb34-0001vA-00@sc8-sf-web4.sourceforge.net>

Bugs item #992081, was opened at 2004-07-16 04:23
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992081&group_id=5470

Category: Build
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: roadkill (dharma_roadkill)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_unicode fails 2.4a1

Initial Comment:

uname -a
OSF1 pikachu.****.com V5.1 2650 alpha
(HP alpha box running Tru64 V5.1B)

Python 2.4a1

make test:
test test_unicode failed -- Traceback (most recent call 
last):
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/test_unicode.py", line 358,
in test_formatting
    
string_tests.MixinStrUnicodeUserStringTest.test_formatti
ng(self)
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/string_tests.py", line 615,
in test_formatting
    self.checkequal('0042.00', '%07.2f', '__mod__', 42)
  File "/u13/home/doug/python/Python-
2.4a1/Lib/test/string_tests.py", line 56, i
n checkequal
    realresult
AssertionError: u'0042.00' != u'0042,00'

no fancy env or locale variables set

note: test_format also fails in make test.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-17 00:19

Message:
Logged In: YES 
user_id=21627

Closed as a duplicate of 992078.

----------------------------------------------------------------------

Comment By: Irmen de Jong (irmen)
Date: 2004-07-16 21:21

Message:
Logged In: YES 
user_id=129426

I can confirm this.
It is caused by test__locale that is executed before this
test. This also causes test_format to fail.
Additional details in my comment on the test_format
bugreport #992078 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992081&group_id=5470
From noreply at sourceforge.net  Sat Jul 17 00:55:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 17 00:55:42 2004
Subject: [ python-Bugs-883283 ] bundlebuilder --lib mishandles frameworks
Message-ID: <E1BlbcA-0006Ia-00@sc8-sf-web2.sourceforge.net>

Bugs item #883283, was opened at 2004-01-23 21:44
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883283&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder --lib mishandles frameworks

Initial Comment:
The bundlebuilder command-line argument --lib is supposed to be able to include frameworks in the resulting Mac app. Unfortunately, the aliases in the resulting framework copy are all broken.

For an example of this, use --lib to include Tcl.framework and then look through the framework in the resulting application package. Frameworks normally have quite a few handy aliases (such as .../Versions/Current) and all the aliases I tried were broken.

I'm not entirely sure if this actually breaks anything. The one app I've managed to build with standalone=True and use of --lib to include the Tk and Tcl frameworks runs fine on my Mac (which has Python, Tcl and Tk frameworks installed) but fails with "True undefined" on another Mac running Jaguar that I happened to have handy.

This 2nd problem may be a separate bug or user error on my part. I'm not yet sure.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-17 00:55

Message:
Logged In: YES 
user_id=45365

That's weird... Could it be that the original has symlinks that somehow 
double as aliases (symlinks with a resource fork??!?)?

Any ideas?


----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-07-16 18:45

Message:
Logged In: YES 
user_id=431773

I see. I also can follow the links using the unix command line. However, I 
cannot follow them using Finder. The links in the original packages *can* be 
followed in Finder, which is why I thought things were seriously broken.

So there is a bug in bundlebuilder (or it is exposing a bug in Finder), but its 
more cosmetic than functional. Still...it'd be nice to have normal Finder 
navigation work if the problem is fixable.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 17:24

Message:
Logged In: YES 
user_id=45365

I cannot repeat this, neither with 2.4a1 nor with 2.3: I always get 
symlinks where they are expected. I tried the following command line 
(with test.py being a simple hello world script), on MacOS 10.3.4 with 
apple-installed Python:

/usr/bin/python /System/Library/Frameworks/Python.framework/
Versions/2.3/lib/python2.3/plat-mac/bundlebuilder.py -m test.py --lib /
Library/Frameworks/Tcl.framework build

and I got symlinks just fine. Feel free to reopen the bug report if you 
have more info.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883283&group_id=5470
From noreply at sourceforge.net  Sat Jul 17 11:18:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 17 11:19:00 2004
Subject: [ python-Bugs-987870 ] Windows installer for 2.4a1 shows
	non-standard version
Message-ID: <E1BllLK-0004Lw-00@sc8-sf-web2.sourceforge.net>

Bugs item #987870, was opened at 2004-07-09 13:03
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470

Category: Windows
Group: Python 2.4
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: Windows installer for 2.4a1 shows non-standard version

Initial Comment:
The Windows installer (MSI) for Python 2.4a1 displays 
the Python version as 2.4.0.12607. This is not the 
standard version format, which should show as 2.4a0.

While this is mainly a cosmetic issue, it will make it 
difficult to verify that the version installed matches the 
latest released alpha/beta. (It's not clear whether the 
final number - the 12607 - will be dropped with the 
release, so this may not be an issue for 2.4 final).

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-17 11:18

Message:
Logged In: YES 
user_id=21627

It turned out that the problem was still somewhat different
than I thought it was, so the next alpha should display
2.4a2 everywhere.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-11 15:50

Message:
Logged In: YES 
user_id=113328

I'm closing this myself, as "won't fix". I assume that's OK.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-10 11:31

Message:
Logged In: YES 
user_id=113328

Fair enough. So the final release will show 2.4 (or 2.4.0?).
That's the main thing, I guess.

I'm happy for this to be closed as something that the MSI
format doesn't support. (Can I do that myself...?)

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-09 22:13

Message:
Logged In: YES 
user_id=21627

It is no issue for the final release, which will drop this
number.

The version number must be a number, so it can't be 2.4a1.
The text displayed in the dialogs could be different, of
course - it just would be more work to make it so.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-09 14:15

Message:
Logged In: YES 
user_id=11105

Martin v. Loewis builds the MSI's.  Assigned to him.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=987870&group_id=5470
From noreply at sourceforge.net  Sat Jul 17 14:31:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 17 14:31:27 2004
Subject: [ python-Bugs-979924 ] email.Message.Message.__getitem__ doc string
	wrong
Message-ID: <E1BloLX-0007Ho-00@sc8-sf-web1.sourceforge.net>

Bugs item #979924, was opened at 2004-06-26 03:52
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979924&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Message.Message.__getitem__ doc string wrong

Initial Comment:
The doc string for email.Message.Message.__getitem__
references a "getall" method.  There is no such method.
 It should refer to the "get_all" method instead.


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-07-17 21:31

Message:
Logged In: YES 
user_id=55188

I think this may resolved by Barry. :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979924&group_id=5470
From noreply at sourceforge.net  Sat Jul 17 15:55:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 17 15:55:20 2004
Subject: [ python-Bugs-990497 ] mistyped example
Message-ID: <E1Blpeg-0007iv-00@sc8-sf-web4.sourceforge.net>

Bugs item #990497, was opened at 2004-07-14 06:41
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990497&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Daniel Pezely (pezely)
Assigned to: Nobody/Anonymous (nobody)
Summary: mistyped example

Initial Comment:
>From "What's New in Python 2.4"
http://www.python.org/dev/doc/devel/whatsnew/node7.html


Under "6 Other Language Changes" section:

Bullet item "There is a new built-in function
sorted(iterable) that works..." first example:

>>> L = [9,7,8,3,2,4,1,6,5]
>>> [10+i for i in sorted(L)]       # usable in a list
comprehension
[11, 12, 13, 14, 15, 16, 17, 18, 19]
>>> L = [9,7,8,3,2,4,1,6,5]         # original is left
unchanged
[9,7,8,3,2,4,1,6,5]   



To illustrate the point given in the text, the last 2
lines should be:

>>> L                                   # original is
left unchanged
[9,7,8,3,2,4,1,6,5]

That is, it should be without assignment.


Or perhaps:
>>> L == [9,7,8,3,2,4,1,6,5]         # original is left
unchanged
True



----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-07-17 22:55

Message:
Logged In: YES 
user_id=55188

Fixed in whatsnew24.tex 1.70
Thank you!

(Reviewed by Seo Sanghyeon and me at KLDP CodeFest)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990497&group_id=5470
From noreply at sourceforge.net  Sat Jul 17 16:49:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 17 16:49:40 2004
Subject: [ python-Bugs-969415 ] CJK codecs list incomplete
Message-ID: <E1BlqVI-0002gl-00@sc8-sf-web1.sourceforge.net>

Bugs item #969415, was opened at 2004-06-09 15:54
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969415&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: CJK codecs list incomplete

Initial Comment:
http://www.python.org/dev/doc/devel/whatsnew/node7.
html states that various CJK encodings have been 
added, but the list given there does not match the list 
on 
http://www.python.org/dev/doc/devel/lib/node128.html.

In particular, missing from the latter list are all of the 
aliases with hyphens:

shift-jis, shift-jisx0213, euc-jp, euc-jisx0213, iso-2022-
jp, iso-2022-jp-1, iso-2022-jp-2, iso-2022-jp-3, iso-
2022-jp-ext, euc-kr, iso-2022-kr

Since I successfully ran codecs.lookup() tests on a few 
of the hyphenated aliases, I assume that the omission 
of the hyphenated versions in the docs is merely an 
oversight.

----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-07-17 23:49

Message:
Logged In: YES 
user_id=55188

I changed aliases with _ which are popular as with hyphens than 
underscores in consistency of iso-8859 aliases.

Doc/lib/libcodecs.tex 1.31


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-06-15 05:28

Message:
Logged In: YES 
user_id=21627

Assigning to somebody else without asking for permission is
impolite, IMO; unassigning the report from anybody.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-06-12 21:04

Message:
Logged In: YES 
user_id=38388

I think that it might be a good idea to document of how the
standard search
function of the encodings package work at the top of that
page, namely
to normalize encoding names before doing the lookup:

"""
        Normalization works as follows: all non-alphanumeric
        characters except the dot used for Python package
names are
        collapsed and replaced with a single underscore,
e.g. '  -;#'
        becomes '_'. Leading and trailing underscores are
removed.

        Note that encoding names should be ASCII only; if
they do use
        non-ASCII characters, these must be Latin-1 compatible.
"""

The table should then only list normalized encoding names (which
I think is already the case).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-06-12 20:59

Message:
Logged In: YES 
user_id=21627

Actually, the top of the page does already say

Notice that spelling alternatives that only differ in case
or use a hyphen instead of an underscore are also valid aliases.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-06-12 20:54

Message:
Logged In: YES 
user_id=21627

It is just not feasible to list all recognized aliases. For
example, for
ISO-8859-1, there are trivial 31 aliases, including
Iso_8859-1 and iSO-8859_1. For shift_jisx0213, there are
1023 trivial aliases.

The aliases column in the documentation should only list
non-trivial aliases, and for these, it should list a form
that people are most likely to encounter. So if "s-jis"
would be more common than "s_jis", this is what should be
listed. If s-JIS is even more common, this should be listed.

The top of the page should say that case in encoding names
does not matter, and that _ and - can be freely substituted.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-12 16:05

Message:
Logged In: YES 
user_id=80475

Mark, would you pronounce on this one.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-06-09 17:25

Message:
Logged In: YES 
user_id=371366

I see no reason to omit any aliases that are recognized, 
especially when the aliases in question are, more often than 
not, the IANA's preferred MIME name as shown at 
http://www.iana.org/assignments/character-sets.

I was looking in the docs to see if Python 2.4 was going to 
support 'euc-jp', and was dismayed to see 'euc_jp' and 
variants but no 'euc-jp'. I had to obtain and install 2.4a0 to 
test to find out that it was just a documentation problem.

Please consider listing all realnames and aliases.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-06-09 16:10

Message:
Logged In: YES 
user_id=55188

Reopened to consider the consistence with non-cjk codecs.
All the non-cjk codecs are written with hyphen even if their
realname is with underscore. (eg. iso8859-1 and iso8859_1.py)
Will changing cjk codecs's codec/alias names to use not
underscores but hyphens make docs more friendly?

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-06-09 16:01

Message:
Logged In: YES 
user_id=55188

All hyphens are translated as underscores in encoding lookups.
So we may not need to provide encoding list with hyphens
additionally.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969415&group_id=5470
From noreply at sourceforge.net  Sat Jul 17 20:30:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 17 20:30:12 2004
Subject: [ python-Feature Requests-992967 ] array.array objects should
	support sequences
Message-ID: <E1Bltwn-0000PH-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #992967, was opened at 2004-07-17 14:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: array.array objects should support sequences

Initial Comment:
array objects from the array module have an extend method that 
only takes arrays.  The implementation would be more useful if it 
accepted arbitrary sequences (generators, lists, strings, etc).  
Similarly, the initializer currently only accepts lists and strings, 
but it should also support arbitrary sequences.

>>> from array import array
>>> array('c', iter('1234'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: array initializer must be list or string
>>> array('c').extend('1234')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only extend array with array (not "str")

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470
From noreply at sourceforge.net  Sun Jul 18 08:44:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 18 08:44:03 2004
Subject: [ python-Bugs-989338 ] test_unicode_file fails on win2k
Message-ID: <E1Bm5Oy-0007g8-00@sc8-sf-web3.sourceforge.net>

Bugs item #989338, was opened at 2004-07-12 14:11
Message generated for change (Comment added) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_unicode_file fails on win2k

Initial Comment:
>>> test_support.verbose = 1
>>> test_unicode_file.test_main()
test_directories
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR
test_single_files
(test.test_unicode_file.TestUnicodeFiles) ... ERROR

======================================================================
ERROR: test_directories
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
178, in test_directories
    self._do_directory(TESTFN_ENCODED+ext,
TESTFN_ENCODED+ext, True)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
112, in _do_directory
    os.mkdir(make_name)
OSError: [Errno 22] Invalid argument: '@test-??.dir'

======================================================================
ERROR: test_equivalent_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
170, in test_equivalent_files
    self._test_equivalent(TESTFN_ENCODED, TESTFN_UNICODE)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
154, in _test_equivalent
    f = file(filename1, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

======================================================================
ERROR: test_single_files
(test.test_unicode_file.TestUnicodeFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
164, in test_single_files
    self._test_single(TESTFN_ENCODED)
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
136, in _test_single
    f = file(filename, "w")
IOError: [Errno 2] No such file or directory: '@test-??'

----------------------------------------------------------------------
Ran 3 tests in 0.061s

FAILED (errors=3)

Traceback (most recent call last):
  File "<pyshell#21>", line 1, in -toplevel-
    test_unicode_file.test_main()
  File
"C:\apps\Python24\lib\test\test_unicode_file.py", line
191, in test_main
    run_suite(suite)
  File "C:\apps\Python24\lib\test\test_support.py",
line 274, in run_suite
    raise TestFailed(msg)
TestFailed: errors occurred; run in verbose mode for
details
>>> 

This is Python2.4a1 on win2k pro

----------------------------------------------------------------------

>Comment By: Miki Tebeka (tebeka)
Date: 2004-07-18 09:44

Message:
Logged In: YES 
user_id=358087

File system is NTFS.

winver gives:
Version 5.1 (Build 2600.xpsp2.030422-1633: Service Pack 1)


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 19:55

Message:
Logged In: YES 
user_id=21627

Are you using a FAT partition?

What precise version string do you get in winver.exe?

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2004-07-13 09:10

Message:
Logged In: YES 
user_id=358087

Sorry, I forgot I've upgraded my OS lately. This *is* WinXP Pro.
Any other data I can send?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-12 19:35

Message:
Logged In: YES 
user_id=31435

Peculiar -- it works fine on WinXP Pro, which ought to work 
the same as Win2K here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989338&group_id=5470
From noreply at sourceforge.net  Sun Jul 18 20:31:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 18 20:31:33 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1BmGRd-0001nO-00@sc8-sf-web4.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 14:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Sun Jul 18 21:46:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 18 21:46:22 2004
Subject: [ python-Bugs-989337 ] test_descr fails on win2k
Message-ID: <E1BmHby-0007wa-00@sc8-sf-web1.sourceforge.net>

Bugs item #989337, was opened at 2004-07-12 06:07
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_descr fails on win2k

Initial Comment:
>>> from test import test_descr
>>> test_descr.verbose = 1
>>> test_descr.test_main()
Testing weakref segfault...
Testing SF bug 551412 ...
Testing SF bug 570483...
Testing list operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing dict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking a[b]=c
Testing dict constructor ...
Testing dir() ...
Testing int operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing long operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing float operations...
checking a >= b
checking a - b
checking a > b
checking a ** b
checking a < b
checking a != b
checking a + b
checking a <= b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking int(a)
checking - a
checking float(a)
checking + a
checking long(a)
checking abs(a)
Testing complex operations...
checking a - b
checking a ** b
checking a != b
checking a + b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking - a
checking + a
checking abs(a)
Testing spamlist operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing spamdict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking repr(a)
checking a[b]=c
Testing Python subclass of dict...
pydict stress test ...
Testing Python subclass of list...
Testing __metaclass__...
Testing Python subclass of module...
Testing multiple inheritance...
Testing error messages for MRO disagreement...
Testing multiple inheritance special cases...
Testing ex5 from C3 switch discussion...
Testing MRO monotonicity...
Testing consistentcy with EPG...
Testing object class...
Testing __slots__...
Testing __dict__ and __weakref__ in __slots__...
Testing class attribute propagation...
Testing errors...
Testing class methods...
Testing C-based class methods...
Testing static methods...
Testing C-based static methods...
Testing classic classes...
Testing computed attributes...
Testing __new__ slot override...
Testing mro() and overriding it...
Testing operator overloading...
Testing methods...
Testing special operators...

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in -toplevel-
    test_descr.test_main()
  File "C:\apps\Python24\lib\test\test_descr.py", line
4024, in test_main
    specials()
  File "C:\apps\Python24\lib\test\test_descr.py", line
1875, in specials
    print Letter('w')
PicklingError: Can't pickle <class
'test.test_descr.Letter'>: attribute lookup
test.test_descr.Letter failed
>>> 

This is Python 2.4a1 on win2k pro

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-18 14:46

Message:
Logged In: YES 
user_id=80475

I cannot reproduce this on either WinME or WinXP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 00:16:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 00:16:51 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1BmJxf-0004ei-00@sc8-sf-web2.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 11:31
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 15:16

Message:
Logged In: YES 
user_id=357491

This is just turning into the month of my regression tests breaking, or at 
least my regression tests that decide to play dangeously with 
sys.modules.  =)

I will take a look and see if I can figure this one out this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 03:13:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 03:13:50 2004
Subject: [ python-Bugs-978662 ] can't compile _localemodule.c w/o
	--enable-toolbox-glue
Message-ID: <E1BmMiw-0000bm-00@sc8-sf-web2.sourceforge.net>

Bugs item #978662, was opened at 2004-06-23 18:56
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978662&group_id=5470

Category: Macintosh
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Brett Cannon (bcannon)
Summary: can't compile _localemodule.c w/o --enable-toolbox-glue

Initial Comment:
Line 412 of Modules/_localemodule.c calls PyMac_getscript() which 
is within a ``#if defined(__APPLE__)`` block.  Trouble is that the 
code is in Python/mactoolboxglue.c which is not compiled if --
disable-toolbox-glue is a compile option (which it was on my OS X 
10.3.4 box).  Probably shouldn't have a compile failure thanks to ld 
not finding the symbol; should probably either just not compile the 
module, change the #if block, or change the function.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 18:13

Message:
Logged In: YES 
user_id=357491

OK, all looks good.  Thanks, Jack.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-07-15 06:32

Message:
Logged In: YES 
user_id=45365

Ok, I've checked in the changes. I'm assigning to you so you can check 
that a --disable-toolbox-glue build still works, please close this report if 
it does.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-06-25 20:41

Message:
Logged In: YES 
user_id=357491

grep agrees with you, Jack:

drifty@Bretts-Computer>grep -rl PyMac_getscript *
Include/pymactoolbox.h
Modules/_localemodule.c
Python/mactoolboxglue.c

So we could just copy and paste it (and fix the spelling of Fredrik's last 
name  =).  But will those CF* functions be linked properly w/o a 
framework build?

I didn't see any macro definitions or anything to signal when a toolbox 
glue build was being done, but it would not hurt to define that.  I get a 
ton of linking errors for any module that has Carbon with this ``--
disable-framework --disable-toolbox-glue`` build that I have been 
fiddling with.  Should we try to make it so that those modules are built 
only if some flag is set somewhere signifying that the proper OS X-
specific build options are not turned off?

Or am I just being so totally non-standard with these build options (only 
done to try to build faster on my old iBook) that it is not worth the 
hassle?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-06-25 04:56

Message:
Logged In: YES 
user_id=45365

There are two solutions:
1) Move PyMac_getscript() to _localemodule.
2) Copy PyMac_getscript() to _localemodule.
3) #ifdef PyLocale_getdefaultlocale in _localemodule on something set by 
enable_toolbox_module_glue.

1) means we can't really put the external declaration in macglue.h any 
more (_localemodule needn't be configured), but I don't think it's used by 
anything but localemodule, so it's probably the best solution.

Still, this is an incompatible change, so we shouldn't backport it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978662&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 06:45:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 06:45:29 2004
Subject: [ python-Bugs-993580 ] inspect.findsource does not call
	linecache.checkcache
Message-ID: <E1BmQ1l-0001RQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #993580, was opened at 2004-07-18 21:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Mobarak (jmobarak)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.findsource does not call linecache.checkcache

Initial Comment:
inspect.findsource does not call linecache.checkcache
thus always returns orignal source of an object
regardless of wether it has changed.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 06:53:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 06:53:50 2004
Subject: [ python-Bugs-993580 ] inspect.findsource does not call
	linecache.checkcache
Message-ID: <E1BmQ9q-0001fs-00@sc8-sf-web4.sourceforge.net>

Bugs item #993580, was opened at 2004-07-18 21:45
Message generated for change (Comment added) made by jmobarak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Mobarak (jmobarak)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.findsource does not call linecache.checkcache

Initial Comment:
inspect.findsource does not call linecache.checkcache
thus always returns orignal source of an object
regardless of wether it has changed.



----------------------------------------------------------------------

>Comment By: Jason Mobarak (jmobarak)
Date: 2004-07-18 21:53

Message:
Logged In: YES 
user_id=1041478

Actually, I'm not sure if this is really a bug, seems to
make sense that inspect shouldn't return the new source of
the object unless the object has changed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 07:01:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 07:01:15 2004
Subject: [ python-Bugs-993580 ] inspect.findsource does not call
	linecache.checkcache
Message-ID: <E1BmQH2-0002gN-00@sc8-sf-web3.sourceforge.net>

Bugs item #993580, was opened at 2004-07-18 21:45
Message generated for change (Comment added) made by jmobarak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Mobarak (jmobarak)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.findsource does not call linecache.checkcache

Initial Comment:
inspect.findsource does not call linecache.checkcache
thus always returns orignal source of an object
regardless of wether it has changed.



----------------------------------------------------------------------

>Comment By: Jason Mobarak (jmobarak)
Date: 2004-07-18 22:01

Message:
Logged In: YES 
user_id=1041478

Not to mention there's intermediate steps where an object's
source could change several times, and be reloaded at one of
those intermediate steps... seems like there's no way for
findsource itself to return the correct source for an object
if it's reloaded. Maybe this should be documented...

----------------------------------------------------------------------

Comment By: Jason Mobarak (jmobarak)
Date: 2004-07-18 21:53

Message:
Logged In: YES 
user_id=1041478

Actually, I'm not sure if this is really a bug, seems to
make sense that inspect shouldn't return the new source of
the object unless the object has changed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993580&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 07:09:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 07:09:55 2004
Subject: [ python-Bugs-989337 ] test_descr fails on win2k
Message-ID: <E1BmQPP-00028Z-00@sc8-sf-web4.sourceforge.net>

Bugs item #989337, was opened at 2004-07-12 14:07
Message generated for change (Comment added) made by tebeka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_descr fails on win2k

Initial Comment:
>>> from test import test_descr
>>> test_descr.verbose = 1
>>> test_descr.test_main()
Testing weakref segfault...
Testing SF bug 551412 ...
Testing SF bug 570483...
Testing list operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing dict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking a[b]=c
Testing dict constructor ...
Testing dir() ...
Testing int operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing long operations...
checking a & b
checking a ^ b
checking a >> b
checking a - b
checking a ** b
checking a + b
checking divmod(a, b)
checking a << b
checking a * b
checking a / b
checking cmp(a, b)
checking a | b
checking a % b
checking int(a)
checking - a
checking ~ a
checking float(a)
checking hex(a)
checking + a
checking long(a)
checking abs(a)
checking oct(a)
Testing float operations...
checking a >= b
checking a - b
checking a > b
checking a ** b
checking a < b
checking a != b
checking a + b
checking a <= b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking int(a)
checking - a
checking float(a)
checking + a
checking long(a)
checking abs(a)
Testing complex operations...
checking a - b
checking a ** b
checking a != b
checking a + b
checking divmod(a, b)
checking a * b
checking a / b
checking a == b
checking a % b
checking - a
checking + a
checking abs(a)
Testing spamlist operations...
checking a+b
checking b in a
checking b in a
checking a[b]
checking a[b:c]
checking a+=b
checking a*=b
checking len(a)
checking a*b
checking b*a
checking a[b]=c
checking a[b:c]=d
Testing spamdict operations...
checking cmp(a,b)
checking b in a
checking b in a
checking a[b]
checking len(a)
checking repr(a)
checking a[b]=c
Testing Python subclass of dict...
pydict stress test ...
Testing Python subclass of list...
Testing __metaclass__...
Testing Python subclass of module...
Testing multiple inheritance...
Testing error messages for MRO disagreement...
Testing multiple inheritance special cases...
Testing ex5 from C3 switch discussion...
Testing MRO monotonicity...
Testing consistentcy with EPG...
Testing object class...
Testing __slots__...
Testing __dict__ and __weakref__ in __slots__...
Testing class attribute propagation...
Testing errors...
Testing class methods...
Testing C-based class methods...
Testing static methods...
Testing C-based static methods...
Testing classic classes...
Testing computed attributes...
Testing __new__ slot override...
Testing mro() and overriding it...
Testing operator overloading...
Testing methods...
Testing special operators...

Traceback (most recent call last):
  File "<pyshell#6>", line 1, in -toplevel-
    test_descr.test_main()
  File "C:\apps\Python24\lib\test\test_descr.py", line
4024, in test_main
    specials()
  File "C:\apps\Python24\lib\test\test_descr.py", line
1875, in specials
    print Letter('w')
PicklingError: Can't pickle <class
'test.test_descr.Letter'>: attribute lookup
test.test_descr.Letter failed
>>> 

This is Python 2.4a1 on win2k pro

----------------------------------------------------------------------

>Comment By: Miki Tebeka (tebeka)
Date: 2004-07-19 08:09

Message:
Logged In: YES 
user_id=358087

Sorry, forgot that I've upgraded to winXP the other day.
This *is* winXP pro SP1

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-18 22:46

Message:
Logged In: YES 
user_id=80475

I cannot reproduce this on either WinME or WinXP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989337&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 08:13:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 08:13:45 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1BmRPA-0003kg-00@sc8-sf-web4.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 11:31
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 23:13

Message:
Logged In: YES 
user_id=357491

OK, on the way to figuring this out, I think.

Line 503 of Lib/threading.py has the statement ``assert self is not 
currentThread()``.  Now currentThread() creates an instance of 
_DummyThread for the current thread and inserts it into 
threading._active with the key of threading._get_ident(), which is -1 for 
all dummy_threading Threads.

Problem is that this doesn't happen under -O so threading._active doesn't 
get an entry for -1 like the exit func expects there to be and thus leads 
to an error.  You can uncomment line 645 to see the difference when the 
test is run.

As for it being a new error in 2.4, my CVS checkout for 2.3 has this error 
as well.  Even if I back Lib/threading back to version 1.40 (before I made 
changes for printing the traceback from shutdown errors) and 
dummy_threading before Jim's threading local stuff (which puts it to the 
initial checkin) I still get the error.  So from what I can tell this is old.

Now, it isn't from the tests, that much I am sure.  If you change the 
imported module for _threading to 'threading' the tests pass either way.  
For some reason the initial thread created from the _MainThread() 
creation in 'threading' disappears before the end of execution for the 
test.  Not sure why.  Might have something to do with 
dummy_thread.get_ident() always returning -1.  Going to keep looking 
into it.  If it is from dummy_thread.get_ident() returning -1 then it might 
be a slight pain to try to fix.  Might have to come up with some modified 
dict for _active in dummy_threading for the code to use that just 
consistently has a -1 or somehow communicates with 
dummy_thread.get_ident() to keep everything in sync.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 15:16

Message:
Logged In: YES 
user_id=357491

This is just turning into the month of my regression tests breaking, or at 
least my regression tests that decide to play dangeously with 
sys.modules.  =)

I will take a look and see if I can figure this one out this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 08:30:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 08:30:35 2004
Subject: [ python-Bugs-993601 ] optparse libref documentation missing "ref"
Message-ID: <E1BmRfU-0000MN-00@sc8-sf-web1.sourceforge.net>

Bugs item #993601, was opened at 2004-07-19 16:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse libref documentation missing "ref"

Initial Comment:
The optparse libref documentation, while extensive, 
doesn't actually include an API reference. There's no way 
of knowing the valid parameter set of 
OptionParser.add_option() without going through the 
source. 
 
Please consider adding an API reference page for each of 
OptionParser (including OptionContainer), Values, Option 
(aka make_option) and OptionGroup. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 15:04:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 15:04:05 2004
Subject: [ python-Bugs-993766 ] bdist_dumb and --relative on Windows fails
Message-ID: <E1BmXoH-0006vN-00@sc8-sf-web1.sourceforge.net>

Bugs item #993766, was opened at 2004-07-19 23:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993766&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_dumb and --relative on Windows fails

Initial Comment:
The following setup.py file:
"""
from distutils.core import setup, Extension
setup(name="foo", scripts= ["foo.py"])
"""
(plus any 'foo.py') fails when creating a .zip binary
on windows:

>setup.py bdist_dumb --relative
running bdist_dumb
...
error: build\bdist.win32\dumb\e:src\python-2.3-cvs:
Invalid argument


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993766&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 15:07:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 15:07:06 2004
Subject: [ python-Bugs-990569 ] printing date causes crash
Message-ID: <E1BmXrC-00072w-00@sc8-sf-web1.sourceforge.net>

Bugs item #990569, was opened at 2004-07-14 09:53
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Justin (jmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: printing date causes crash

Initial Comment:
Hi,

I'm using Python 2.3.4 + PythonWin 1.63 to manipulate
some Access databases. It appears that a default date
set in the database is causing python to crash when
attempting to print it. All records which have a
different(relatively current - 2000 onwards) date print
fine. The default date is set to 31-Dec-1955. There's
nothing particular about the date that I cannot change
it, just thought you should know that date was causing
a problem.

C:\Work>python
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>>


I've attached the error file generated by windows.


Justin

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2004-07-19 23:07

Message:
Logged In: YES 
user_id=14198

This should be a bug in the pywin32 project, not Python
itself - however, this has been fixed in recent builds - the
latest is build 202.

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-17 02:24

Message:
Logged In: YES 
user_id=1083084

Mornin'!


Well, I'm thinking that it may be simpler to send you a copy
of the table/db and the offending code. Do you have access
to a M$ platform?

Justin

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-16 10:41

Message:
Logged In: YES 
user_id=33168

It doesn't help me, but I'm not a windows guy anyways. :-)

Is there an extention module for Access?  It seems like the
problem may be there or perhaps it's general to windows. 
You could try contacting whoever distributes the module. 
Hopefully someone else can help.  If you can give me a test
example that demonstrates the problem in the interpreter, I
can try to look into this. 

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-16 10:14

Message:
Logged In: YES 
user_id=1083084

Doh! 

Here's how I reproduced the bug:

1. Started Access 
2. Changed a single date field to 31-Dec-55.
3. Close Access
4. Ran python script to print records...and presto! Crash.


As I look at that date I can't help wondering if it's being
passed back to Python as 2055?


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-16 09:58

Message:
Logged In: YES 
user_id=1083084

Ok, I've attached the file now. 

Hope it helps!


Justin

----------------------------------------------------------------------

Comment By: Justin (jmuir)
Date: 2004-07-16 09:20

Message:
Logged In: YES 
user_id=1083084

Hello,

Damn, I've already changed the default date in my db...hang
on, I'll do it again and send the file....

btw - I tried to reproduce the error in the interpreter by
instantiating a date and a datetime object with that date.
No crash. I wonder if it's something to do with what Access
is passing to Python?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-16 08:23

Message:
Logged In: YES 
user_id=33168

Can you reproduce the problem from the python interpreter
w/o the database?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-16 08:22

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990569&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 17:41:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 17:42:00 2004
Subject: [ python-Bugs-990307 ] cgi.parse_qsl broken
Message-ID: <E1BmaH5-0005al-00@sc8-sf-web2.sourceforge.net>

Bugs item #990307, was opened at 2004-07-13 17:17
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990307&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
>Assigned to: Neil Schemenauer (nascheme)
Summary: cgi.parse_qsl broken

Initial Comment:
The cgi module has been changed so that now
parse_qsl("", keep_blank_values=True) returns [('',
'')].  I think that's wrong.  I thought about changing
it so that items with empty names are skipped but
test_cgi requires that "=a" produce [('', 'a')].  I
also thought about special casing the empty string to
return [] but test_cgi checks that parse_qsl("",
strict_parsing=1) raises ValueError.  That seems wrong
to me but I'm scared to change it since there may be
code out there that depends on this behavior.  OTOH, it
seems highly unlikely that people would find the strict
parsing flag useful (there's too much broken stuff on
the net).

The minimal fix would be to not generate any items that
are equal to ('', '').  Looking for advice.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2004-07-19 15:41

Message:
Logged In: YES 
user_id=35752

After discussing this with coworkers, I've decided on a fix.
 The effect of the change is that an empty key/value pair
will not be returned unless an '=' character appears in the
input.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990307&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 17:56:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 17:56:24 2004
Subject: [ python-Feature Requests-992967 ] array.array objects should
	support sequences
Message-ID: <E1BmaV2-0006FQ-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #992967, was opened at 2004-07-17 19:30
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: array.array objects should support sequences

Initial Comment:
array objects from the array module have an extend method that 
only takes arrays.  The implementation would be more useful if it 
accepted arbitrary sequences (generators, lists, strings, etc).  
Similarly, the initializer currently only accepts lists and strings, 
but it should also support arbitrary sequences.

>>> from array import array
>>> array('c', iter('1234'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: array initializer must be list or string
>>> array('c').extend('1234')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only extend array with array (not "str")

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-19 16:56

Message:
Logged In: YES 
user_id=6656

I agree with your first point.  Should be easy, too.

I'm /slightly/ less enthusiastic about the latter point.  sequence-
>array conversion is sufficiently complex that I'm not sure I want 
it happening automatically.

This is the sort of report that a patch would help immensely, btw 
:-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 18:08:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 18:08:57 2004
Subject: [ python-Bugs-986795 ] New mandatory 2nd argument to
	site.addsitedir breaks compat
Message-ID: <E1BmahB-0001sB-00@sc8-sf-web4.sourceforge.net>

Bugs item #986795, was opened at 2004-07-07 14:56
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Brett Cannon (bcannon)
Summary: New mandatory 2nd argument to site.addsitedir breaks compat

Initial Comment:

  Old .pth files now raise a TypeError, which site.py
does not catch, which causes the import of site.py to fail.

  The new required parameter is also undocumented and,
on a cursory inspection, it is unclear to me what its
purpose is.

  This comes up because Debian allows for a version
neutral site-packages directory, /usr/lib/site-python/,
into which .pth files can be placed.


----------------------------------------------------------------------

>Comment By: Jp Calderone (kuran)
Date: 2004-07-19 12:08

Message:
Logged In: YES 
user_id=366566

userlib.pth attached.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-16 01:49

Message:
Logged In: YES 
user_id=357491

I fixed the argument requirement, but I was waiting to here from JP 
about the TypeError issue since I have no clue where that is coming from 
(tests I have in test_site haven't shown any issue).

If you could double-check my test for .pth files in test_site and say they 
look good I will go ahead and close this.  Otherwise I want to wait a little 
while to give JP a chance to upload a .pth file that is causing trouble.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 20:50

Message:
Logged In: YES 
user_id=33168

Brett, didn't you fix this?  Can it be closed?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-09 19:35

Message:
Logged In: YES 
user_id=357491

Yes, it is my change, but the one call to the function has the argument 
and the function is undocumented so I didn't worry about it.  As for its 
use, it allowed me to get rid of the nasty global variable that every 
function assumed was there for basic sys.path duplication checks.

I have gone ahead and made it optional.

As for the .pth errors, the test suite tests .pth files and the test passes.  
Do you have an example .pth file, JP, that I can test against?  How about 
the traceback of the exception?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 21:30

Message:
Logged In: YES 
user_id=33168

Brett, did this happen from your changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 18:30:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 18:30:51 2004
Subject: [ python-Bugs-966618 ] float_subtype_new() bug
Message-ID: <E1Bmb2F-0002nm-00@sc8-sf-web4.sourceforge.net>

Bugs item #966618, was opened at 2004-06-04 15:39
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=966618&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Neil Schemenauer (nascheme)
Summary: float_subtype_new() bug

Initial Comment:
A rather obsure bug in the subclassing code:

>>> class A:
...   def __float__(self): return 'hello'
...
>>> float(A())
'hello'

>>> class f(float): pass
...
>>> f(A())
-5.7590155905901735e-56

In debug mode, the assert() in float_subtype_new() fails instead.  In non-debug mode, the value we get is the result of typecasting the PyStringObject* to a PyFloatObject*.

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2004-07-19 16:30

Message:
Logged In: YES 
user_id=35752

Checked in as:

Lib/test/test_class.py 1.11
Misc/NEWS 1.1046
Objects/abstract.c 2.130
Objects/intobject.c 2.111
Python/bltinmodule.c 2.312

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2004-06-18 22:07

Message:
Logged In: YES 
user_id=35752

My patch allows nb_int and nb_long to return either long or
int objects.  That means callers of PyNumber_Long need to be
careful too.  I'm uploading a new version of the patch that
adds a test for int/long interchangeability.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-06-17 17:02

Message:
Logged In: YES 
user_id=6380

(BTW, shouldn't it be "convertible"?)

I'm torn. For practical reasons, I'm for the minimal patch
originally proposed. Also because I want to allow __int__
returning a long (and vice versa!).

But according to my post this morning to python-dev, I would
like to ensure that the return type of int(), float(), etc.
can be relied upon by type inferencing engines. It would be
a shame to have to assume that after x = int(y) the type of
x could be anything...

Neil, can you rework your patch to be lenient about int/long
but otherwise be strict? It means callers of PyNumber_Int()
should still be careful, but that's the way of the future
anyway.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2004-06-16 22:23

Message:
Logged In: YES 
user_id=4771

Let's be careful here.  I can imagine that some __int__() implementations in user code would return a long instead, as it is the behavior of int(something_too_big) already.

As far as I know, the original bug this tracker is for is the only place where it was blindly assumed that a specific conversion method returned an object of a specific type.  I'm fine with just fixing that case.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2004-06-08 02:54

Message:
Logged In: YES 
user_id=35752

Attaching patch.  One outstanding issue is that it may make
sense to search for and remove unnecessary type checks (e.g.
PyNumber_Int followed by PyInt_Check).  Also, this change
only broke one test case but I have no idea how much user
code this might break.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-07 15:37

Message:
Logged In: YES 
user_id=31435

Assigned to Neil, as a reminder to attach his patch.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2004-06-05 21:00

Message:
Logged In: YES 
user_id=35752

I've got an alternative patch.  SF cvs is down at the moment
so I'll have to generate a patch later.  My change makes
CPython match the behavior of Jython.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2004-06-05 19:46

Message:
Logged In: YES 
user_id=35752

I think the right fix is to have PyNumber_Int,
PyNumber_Float, and PyNumber_Long check the return value of
slot function (i.e. nb_int, nb_float).  That matches the
behavior of PyObject_Str and PyObject_Repr.

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 13:13

Message:
Logged In: YES 
user_id=1057404

(ack, spelling error copied from intobject.c)

###
--- floatobject.c-      Sat Jun  5 13:21:07 2004
+++ floatobject.c       Sat Jun  5 13:23:00 2004
@@ -765,7 +765,13 @@
        tmp = float_new(&PyFloat_Type, args, kwds);
        if (tmp == NULL)
                return NULL;
-       assert(PyFloat_CheckExact(tmp));
+       if(!PyFloat_CheckExact(tmp)) {
+               PyErr_SetString(PyExc_ValueError,
+                               "value must be convertable
to a float");
+               Py_DECREF(tmp);
+               return NULL;
+       }
+
        new = type->tp_alloc(type, 0);
        if (new == NULL) {
                Py_DECREF(tmp);
###

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 13:11

Message:
Logged In: YES 
user_id=1057404

(Inline, I can't seem to attach things)

###
--- floatobject.c-      Sat Jun  5 13:21:07 2004
+++ floatobject.c       Sat Jun  5 13:23:00 2004
@@ -765,7 +765,13 @@
        tmp = float_new(&PyFloat_Type, args, kwds);
        if (tmp == NULL)
                return NULL;
-       assert(PyFloat_CheckExact(tmp));
+       if(!PyFloat_CheckExact(tmp)) {
+               PyErr_SetString(PyExc_ValueError,
+                               "value must convertable to a
float");
+               Py_DECREF(tmp);
+               return NULL;
+       }
+
        new = type->tp_alloc(type, 0);
        if (new == NULL) {
                Py_DECREF(tmp);
###

----------------------------------------------------------------------

Comment By: Aaron Brady (insomnike)
Date: 2004-06-05 13:01

Message:
Logged In: YES 
user_id=1057404

floatobject.c contains an assertion that the value can be
coerced into a float, but not a runtime if. I've changed it
to be in line with what int_subtype_new() does.

This may not be 100% correct, however, as they both allow a
string to be returned from __int__() and __float__(),
respectively. complex() does not allow this, however, and it
throws TypeError (while int_subtype_new() and
float_subtype_new() throw ValueError).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=966618&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 20:59:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 20:59:11 2004
Subject: [ python-Bugs-994023 ] threads duplicated on fork() prevent child
	from terminating
Message-ID: <E1BmdLw-0005go-00@sc8-sf-web2.sourceforge.net>

Bugs item #994023, was opened at 2004-07-19 11:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994023&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: L.C. (Laurentiu C. Badea) (wotevah)
Assigned to: Nobody/Anonymous (nobody)
Summary: threads duplicated on fork() prevent child from terminating

Initial Comment:

(This is a repost from an older c.l.py submission to
prevent losing track of it)

It looks as if fork() duplicates the entire threads
info structure in the new process. This causes child
processes to attempt to handle or wait for nonexistent
threads and causes them to hang on exit.

Perhaps clearing Python's internal thread info after
the fork() is all that is needed to fix this (the fact
that the threads themselves are not duplicated  seems
to suggest that this was indeed the intention - and
also is POSIXly correct).

Original post with sample code for the problem is here
(also attached for your convenience):

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=e0bf36b5.0306191548.73b7383%40posting.google.com

The "bug" manifests itself by the program not exiting
voluntarily. The two processes created need to be
terminated individually.

Last tested on 2.3.3 (Fedora Core 2), but present since
2.1 I believe.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994023&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 21:23:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 21:24:00 2004
Subject: [ python-Feature Requests-992967 ] array.array objects should
	support sequences
Message-ID: <E1Bmdjt-0001Ir-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #992967, was opened at 2004-07-17 13:30
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: array.array objects should support sequences

Initial Comment:
array objects from the array module have an extend method that 
only takes arrays.  The implementation would be more useful if it 
accepted arbitrary sequences (generators, lists, strings, etc).  
Similarly, the initializer currently only accepts lists and strings, 
but it should also support arbitrary sequences.

>>> from array import array
>>> array('c', iter('1234'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: array initializer must be list or string
>>> array('c').extend('1234')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only extend array with array (not "str")

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 14:23

Message:
Logged In: YES 
user_id=80475

In Py2.4, I already made extend() take a general iterable. 
The goal was to simplify code doing repeated appends.

By calling array_extend, it should be easy to do the same
for the constructor.  The question is whether there are use
cases to warrant a further API change.  Most needs can
already be met with extend() or with array.array(code,
list(it)).  

My preference is to leave the constructor for cases with a
known sequence length.   With a single pre-allocation and
copy step, the performance is optimal.  I don't think it
would be obvious that using a general iterable would be much
slower and consume more memory than expected.  That's okay
for lists, but people use array when they are tight for
space or have other performance goals.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-19 10:56

Message:
Logged In: YES 
user_id=6656

I agree with your first point.  Should be easy, too.

I'm /slightly/ less enthusiastic about the latter point.  sequence-
>array conversion is sufficiently complex that I'm not sure I want 
it happening automatically.

This is the sort of report that a patch would help immensely, btw 
:-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 23:21:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 23:21:45 2004
Subject: [ python-Bugs-994100 ] seg fault when calling bsddb.hashopen()
Message-ID: <E1BmfZs-0002hy-00@sc8-sf-web1.sourceforge.net>

Bugs item #994100, was opened at 2004-07-19 16:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gregory P. Smith (greg)
Summary: seg fault when calling bsddb.hashopen()

Initial Comment:
Fresh 2.3.4 build (didn't even install!) on Mandrake
8.1-ish system
using Berkeley DB 3.3 yields this output when trying to
create a new hash db:

Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("foo.db", "c")

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 22763)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x404e284b in newDBObject (arg=0x0, flags=0)
    at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:697
#2  0x404ee808 in DB_construct (self=0x0,
args=0x401a602c, kwargs=0x0)
    at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:4322
#3  0x080f718a in PyCFunction_Call (func=0x4047344c,
arg=0x401a602c, kw=0x0)
    at Objects/methodobject.c:93
#4  0x080b122d in call_function (pp_stack=0xbffff31c,
oparg=0)
    at Python/ceval.c:3439
#5  0x080af680 in eval_frame (f=0x8195a0c) at
Python/ceval.c:2116
#6  0x080b0382 in PyEval_EvalCodeEx (co=0x4047ff60,
globals=0x404859bc, 
    locals=0x0, args=0x818e13c, argcount=2,
kws=0x818e144, kwcount=0, 
    defs=0x404868f8, defcount=8, closure=0x0) at
Python/ceval.c:2663
#7  0x080b2ea1 in fast_function (func=0x40486454,
pp_stack=0xbffff4bc, n=2, 
    na=2, nk=0) at Python/ceval.c:3529
#8  0x080b1119 in call_function (pp_stack=0xbffff4bc,
oparg=2)
    at Python/ceval.c:3458
#9  0x080af680 in eval_frame (f=0x818dfec) at
Python/ceval.c:2116
#10 0x080b0382 in PyEval_EvalCodeEx (co=0x4046a920,
globals=0x401bd79c, 
    locals=0x401bd79c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#11 0x080b2dd5 in PyEval_EvalCode (co=0x4046a920,
globals=0x401bd79c, 
    locals=0x401bd79c) at Python/ceval.c:537
#12 0x080d34ab in run_node (n=0x401a6a88,
filename=0x80f9fe8 "<stdin>", 
    globals=0x401bd79c, locals=0x401bd79c,
flags=0xbffff6cc)
    at Python/pythonrun.c:1267
#13 0x080d185c in PyRun_InteractiveOneFlags
(fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", flags=0xbffff6cc) at
Python/pythonrun.c:757
#14 0x080d164e in PyRun_InteractiveLoopFlags
(fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", flags=0xbffff6cc) at
Python/pythonrun.c:690
#15 0x080d2c08 in PyRun_AnyFileExFlags (fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", closeit=0,
flags=0xbffff6cc)
    at Python/pythonrun.c:653
#16 0x0805508c in Py_Main (argc=1, argv=0xbffff7a4) at
Modules/main.c:415
#17 0x08054a99 in main (argc=1, argv=0xbffff7a4) at
Modules/python.c:23
#18 0x400825b0 in __libc_start_main () from /lib/libc.so.6

ldd tells me this is how it's linked:

% ldd build/lib.linux-i686-2.3/_bsddb.so 
	libdb-3.3.so => /lib/libdb-3.3.so (0x40022000)
	libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400b2000)
	libc.so.6 => /lib/libc.so.6 (0x400ba000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

What's the oldest Berkeley DB usable with the
bsddb package?  According to the README file
versions 3.1 through 4.1 are supported.  According
to Modules/_bsddb.c versions 3.2 through 4.2 are
supported.  According to comments in setup.py 3.1
is only partially supported.  I'm wondering if maybe
the bar
has been raised even higher and 3.3 is no longer supported.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 23:22:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 23:23:01 2004
Subject: [ python-Bugs-994101 ] urllib2: improper capitalization of headers
Message-ID: <E1Bmfb9-0002mX-00@sc8-sf-web1.sourceforge.net>

Bugs item #994101, was opened at 2004-07-19 16:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Sayre (franklinmint)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2: improper capitalization of headers

Initial Comment:
urllib2.py version 1.72 uses capitalize() on HTTP
header names. This results in headers like "User-agent"
instead of "User-Agent". This causes HTTP 400 errors on
some servers when the request has a body, because there
are two content length headers placed in the request:

"Content-Length" (inserted by httplib)
"Content-length" (inserted by
Request.add_unredirected_header)

The capitalization is incorrect, and httplib inserts
Content-Length anyway, so I'm not sure why urllib2 is
bothering.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470
From noreply at sourceforge.net  Mon Jul 19 23:43:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 19 23:44:12 2004
Subject: [ python-Bugs-994100 ] seg fault when calling bsddb.hashopen()
Message-ID: <E1Bmfv4-0003Xw-00@sc8-sf-web1.sourceforge.net>

Bugs item #994100, was opened at 2004-07-19 16:21
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gregory P. Smith (greg)
Summary: seg fault when calling bsddb.hashopen()

Initial Comment:
Fresh 2.3.4 build (didn't even install!) on Mandrake
8.1-ish system
using Berkeley DB 3.3 yields this output when trying to
create a new hash db:

Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("foo.db", "c")

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 22763)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x404e284b in newDBObject (arg=0x0, flags=0)
    at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:697
#2  0x404ee808 in DB_construct (self=0x0,
args=0x401a602c, kwargs=0x0)
    at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:4322
#3  0x080f718a in PyCFunction_Call (func=0x4047344c,
arg=0x401a602c, kw=0x0)
    at Objects/methodobject.c:93
#4  0x080b122d in call_function (pp_stack=0xbffff31c,
oparg=0)
    at Python/ceval.c:3439
#5  0x080af680 in eval_frame (f=0x8195a0c) at
Python/ceval.c:2116
#6  0x080b0382 in PyEval_EvalCodeEx (co=0x4047ff60,
globals=0x404859bc, 
    locals=0x0, args=0x818e13c, argcount=2,
kws=0x818e144, kwcount=0, 
    defs=0x404868f8, defcount=8, closure=0x0) at
Python/ceval.c:2663
#7  0x080b2ea1 in fast_function (func=0x40486454,
pp_stack=0xbffff4bc, n=2, 
    na=2, nk=0) at Python/ceval.c:3529
#8  0x080b1119 in call_function (pp_stack=0xbffff4bc,
oparg=2)
    at Python/ceval.c:3458
#9  0x080af680 in eval_frame (f=0x818dfec) at
Python/ceval.c:2116
#10 0x080b0382 in PyEval_EvalCodeEx (co=0x4046a920,
globals=0x401bd79c, 
    locals=0x401bd79c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#11 0x080b2dd5 in PyEval_EvalCode (co=0x4046a920,
globals=0x401bd79c, 
    locals=0x401bd79c) at Python/ceval.c:537
#12 0x080d34ab in run_node (n=0x401a6a88,
filename=0x80f9fe8 "<stdin>", 
    globals=0x401bd79c, locals=0x401bd79c,
flags=0xbffff6cc)
    at Python/pythonrun.c:1267
#13 0x080d185c in PyRun_InteractiveOneFlags
(fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", flags=0xbffff6cc) at
Python/pythonrun.c:757
#14 0x080d164e in PyRun_InteractiveLoopFlags
(fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", flags=0xbffff6cc) at
Python/pythonrun.c:690
#15 0x080d2c08 in PyRun_AnyFileExFlags (fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", closeit=0,
flags=0xbffff6cc)
    at Python/pythonrun.c:653
#16 0x0805508c in Py_Main (argc=1, argv=0xbffff7a4) at
Modules/main.c:415
#17 0x08054a99 in main (argc=1, argv=0xbffff7a4) at
Modules/python.c:23
#18 0x400825b0 in __libc_start_main () from /lib/libc.so.6

ldd tells me this is how it's linked:

% ldd build/lib.linux-i686-2.3/_bsddb.so 
	libdb-3.3.so => /lib/libdb-3.3.so (0x40022000)
	libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400b2000)
	libc.so.6 => /lib/libc.so.6 (0x400ba000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

What's the oldest Berkeley DB usable with the
bsddb package?  According to the README file
versions 3.1 through 4.1 are supported.  According
to Modules/_bsddb.c versions 3.2 through 4.2 are
supported.  According to comments in setup.py 3.1
is only partially supported.  I'm wondering if maybe
the bar
has been raised even higher and 3.3 is no longer supported.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-19 16:43

Message:
Logged In: YES 
user_id=44345

I downloaded and installed BerkDB 4.2.52, then rebuilt bsddb
using it.  The
results are more promising:

% ./python
Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("junk.db", "c")
{}
>>> 
You have new mail in /var/spool/mail/skip
% ldd build/lib.linux-i686-2.3/_bsddb.so 
	libdb-4.2.so => /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
(0x40016000)
	libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400d4000)
	libc.so.6 => /lib/libc.so.6 (0x400dc000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 00:05:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 00:05:59 2004
Subject: [ python-Bugs-994100 ] seg fault when calling bsddb.hashopen()
Message-ID: <E1BmgGD-0001DL-00@sc8-sf-web3.sourceforge.net>

Bugs item #994100, was opened at 2004-07-19 14:21
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gregory P. Smith (greg)
Summary: seg fault when calling bsddb.hashopen()

Initial Comment:
Fresh 2.3.4 build (didn't even install!) on Mandrake
8.1-ish system
using Berkeley DB 3.3 yields this output when trying to
create a new hash db:

Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("foo.db", "c")

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 22763)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x404e284b in newDBObject (arg=0x0, flags=0)
    at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:697
#2  0x404ee808 in DB_construct (self=0x0,
args=0x401a602c, kwargs=0x0)
    at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:4322
#3  0x080f718a in PyCFunction_Call (func=0x4047344c,
arg=0x401a602c, kw=0x0)
    at Objects/methodobject.c:93
#4  0x080b122d in call_function (pp_stack=0xbffff31c,
oparg=0)
    at Python/ceval.c:3439
#5  0x080af680 in eval_frame (f=0x8195a0c) at
Python/ceval.c:2116
#6  0x080b0382 in PyEval_EvalCodeEx (co=0x4047ff60,
globals=0x404859bc, 
    locals=0x0, args=0x818e13c, argcount=2,
kws=0x818e144, kwcount=0, 
    defs=0x404868f8, defcount=8, closure=0x0) at
Python/ceval.c:2663
#7  0x080b2ea1 in fast_function (func=0x40486454,
pp_stack=0xbffff4bc, n=2, 
    na=2, nk=0) at Python/ceval.c:3529
#8  0x080b1119 in call_function (pp_stack=0xbffff4bc,
oparg=2)
    at Python/ceval.c:3458
#9  0x080af680 in eval_frame (f=0x818dfec) at
Python/ceval.c:2116
#10 0x080b0382 in PyEval_EvalCodeEx (co=0x4046a920,
globals=0x401bd79c, 
    locals=0x401bd79c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#11 0x080b2dd5 in PyEval_EvalCode (co=0x4046a920,
globals=0x401bd79c, 
    locals=0x401bd79c) at Python/ceval.c:537
#12 0x080d34ab in run_node (n=0x401a6a88,
filename=0x80f9fe8 "<stdin>", 
    globals=0x401bd79c, locals=0x401bd79c,
flags=0xbffff6cc)
    at Python/pythonrun.c:1267
#13 0x080d185c in PyRun_InteractiveOneFlags
(fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", flags=0xbffff6cc) at
Python/pythonrun.c:757
#14 0x080d164e in PyRun_InteractiveLoopFlags
(fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", flags=0xbffff6cc) at
Python/pythonrun.c:690
#15 0x080d2c08 in PyRun_AnyFileExFlags (fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", closeit=0,
flags=0xbffff6cc)
    at Python/pythonrun.c:653
#16 0x0805508c in Py_Main (argc=1, argv=0xbffff7a4) at
Modules/main.c:415
#17 0x08054a99 in main (argc=1, argv=0xbffff7a4) at
Modules/python.c:23
#18 0x400825b0 in __libc_start_main () from /lib/libc.so.6

ldd tells me this is how it's linked:

% ldd build/lib.linux-i686-2.3/_bsddb.so 
	libdb-3.3.so => /lib/libdb-3.3.so (0x40022000)
	libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400b2000)
	libc.so.6 => /lib/libc.so.6 (0x400ba000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

What's the oldest Berkeley DB usable with the
bsddb package?  According to the README file
versions 3.1 through 4.1 are supported.  According
to Modules/_bsddb.c versions 3.2 through 4.2 are
supported.  According to comments in setup.py 3.1
is only partially supported.  I'm wondering if maybe
the bar
has been raised even higher and 3.3 is no longer supported.

Skip


----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2004-07-19 15:05

Message:
Logged In: YES 
user_id=413

it -should- work with 3.2 and later.  that said, its been a
while since i've tested using 3.2 or 3.3.  Can you do one
more thing for me against your _bsddb.so that appearred to
be linked with 3.3?

    from bsddb import db
    print db.DB_VERSION_STRING
    print 'bsddb.db.version():   %s' % (db.version(), )
    print 'bsddb.db.__version__: %s' % db.__version__
    print 'bsddb.db.cvsid:       %s' % db.cvsid

just to make sure that the header files it compiled with
match the version the dynamic loader decided to link it
with.  i've seen problems with that in the past.

i'll built it against 3.2 and 3.3 later tonight and run the
testsuites locally.  if it doesn't work with those without
an obvious reason+fix i'll just mark them as unsupported. 
4.0 has been around for a long time now.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-19 14:43

Message:
Logged In: YES 
user_id=44345

I downloaded and installed BerkDB 4.2.52, then rebuilt bsddb
using it.  The
results are more promising:

% ./python
Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("junk.db", "c")
{}
>>> 
You have new mail in /var/spool/mail/skip
% ldd build/lib.linux-i686-2.3/_bsddb.so 
	libdb-4.2.so => /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
(0x40016000)
	libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400d4000)
	libc.so.6 => /lib/libc.so.6 (0x400dc000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 00:06:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 00:07:03 2004
Subject: [ python-Bugs-991754 ] _bsddb segfault
Message-ID: <E1BmgHj-0001Fi-00@sc8-sf-web3.sourceforge.net>

Bugs item #991754, was opened at 2004-07-15 10:27
Message generated for change (Settings changed) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Jim Fulton (dcjim)
>Assigned to: Gregory P. Smith (greg)
Summary: _bsddb segfault

Initial Comment:
I have to remove the _bsddb extension to run the Python
tests. Otherwise I get a segfault when test_anydbm is
run. I also get a segfault running test_bsddb

uname -r
2.4.22-1.2188.nptlsmp

rpm -q db4
db4-4.1.25-14


gdb ./python
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as
"i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r -E -tt ./Lib/test/regrtest.py -vv test_bsddb
Starting program:
/home/jim/src/python/cvs2/dist/src/python -E -tt
./Lib/test/regrtest.py -vv test_bsddb
[Thread debugging using libthread_db enabled]
[New Thread -1084317568 (LWP 19122)]
test_bsddb
test__no_deadlock_first (test.test_bsddb.TestBTree) ...
ERROR

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1084317568 (LWP 19122)]
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()
(gdb) r -E -tt ./Lib/test/regrtest.py -vv test_anydbm
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program:
/home/jim/src/python/cvs2/dist/src/python -E -tt
./Lib/test/regrtest.py -vv test_anydbm
[Thread debugging using libthread_db enabled]
[New Thread -1084645248 (LWP 19132)]
test_anydbm
test_anydbm_creation (test.test_anydbm.AnyDBMTestCase)
... ERROR

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1084645248 (LWP 19132)]
0x00000000 in ?? ()
(gdb) where
#0  0x00000000 in ?? ()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991754&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 01:57:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 01:57:42 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1Bmi0n-0001w9-00@sc8-sf-web4.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 14:31
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-19 19:57

Message:
Logged In: YES 
user_id=31435

Then I think you'll find the answer if you do

cvs diff -r r234 -r release23-maint threading.py

I was using the released 2.3.4 Python.  But on the current 
2.3 maint branch, you removed two lines like this:

        currentThread() # for side-effect

These *were* unconditionally executed in 2.3.4, but don't 
exist on the current 2.3 branch, or on HEAD.

I expect that explains why this didn't fail in 2.3.4.  I don't 
know that reverting those lines is a correct (or even the 
best) solution, though.  Perhaps doing currentThread() once, 
from the main thread, at the start of threading's shutdown 
dance, would be enough.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 02:13

Message:
Logged In: YES 
user_id=357491

OK, on the way to figuring this out, I think.

Line 503 of Lib/threading.py has the statement ``assert self is not 
currentThread()``.  Now currentThread() creates an instance of 
_DummyThread for the current thread and inserts it into 
threading._active with the key of threading._get_ident(), which is -1 for 
all dummy_threading Threads.

Problem is that this doesn't happen under -O so threading._active doesn't 
get an entry for -1 like the exit func expects there to be and thus leads 
to an error.  You can uncomment line 645 to see the difference when the 
test is run.

As for it being a new error in 2.4, my CVS checkout for 2.3 has this error 
as well.  Even if I back Lib/threading back to version 1.40 (before I made 
changes for printing the traceback from shutdown errors) and 
dummy_threading before Jim's threading local stuff (which puts it to the 
initial checkin) I still get the error.  So from what I can tell this is old.

Now, it isn't from the tests, that much I am sure.  If you change the 
imported module for _threading to 'threading' the tests pass either way.  
For some reason the initial thread created from the _MainThread() 
creation in 'threading' disappears before the end of execution for the 
test.  Not sure why.  Might have something to do with 
dummy_thread.get_ident() always returning -1.  Going to keep looking 
into it.  If it is from dummy_thread.get_ident() returning -1 then it might 
be a slight pain to try to fix.  Might have to come up with some modified 
dict for _active in dummy_threading for the code to use that just 
consistently has a -1 or somehow communicates with 
dummy_thread.get_ident() to keep everything in sync.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 18:16

Message:
Logged In: YES 
user_id=357491

This is just turning into the month of my regression tests breaking, or at 
least my regression tests that decide to play dangeously with 
sys.modules.  =)

I will take a look and see if I can figure this one out this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 04:13:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 04:13:29 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1Bmk8C-0008M4-00@sc8-sf-web3.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 11:31
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 19:13

Message:
Logged In: YES 
user_id=357491

Can't add those lines back in without breaking the fixes to allow 
tracebacks triggered during interpreter shutdown from failing.  And I 
don't think doing it at the beginning will solve it since it will still be 
overwritten by subsequent threads in threading._active anyway.  Could 
be fixed if the call is made in the method registered with atexit.

Plan on spending tonight on this one.  Hopefully I will come up with 
something.  =)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-19 16:57

Message:
Logged In: YES 
user_id=31435

Then I think you'll find the answer if you do

cvs diff -r r234 -r release23-maint threading.py

I was using the released 2.3.4 Python.  But on the current 
2.3 maint branch, you removed two lines like this:

        currentThread() # for side-effect

These *were* unconditionally executed in 2.3.4, but don't 
exist on the current 2.3 branch, or on HEAD.

I expect that explains why this didn't fail in 2.3.4.  I don't 
know that reverting those lines is a correct (or even the 
best) solution, though.  Perhaps doing currentThread() once, 
from the main thread, at the start of threading's shutdown 
dance, would be enough.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 23:13

Message:
Logged In: YES 
user_id=357491

OK, on the way to figuring this out, I think.

Line 503 of Lib/threading.py has the statement ``assert self is not 
currentThread()``.  Now currentThread() creates an instance of 
_DummyThread for the current thread and inserts it into 
threading._active with the key of threading._get_ident(), which is -1 for 
all dummy_threading Threads.

Problem is that this doesn't happen under -O so threading._active doesn't 
get an entry for -1 like the exit func expects there to be and thus leads 
to an error.  You can uncomment line 645 to see the difference when the 
test is run.

As for it being a new error in 2.4, my CVS checkout for 2.3 has this error 
as well.  Even if I back Lib/threading back to version 1.40 (before I made 
changes for printing the traceback from shutdown errors) and 
dummy_threading before Jim's threading local stuff (which puts it to the 
initial checkin) I still get the error.  So from what I can tell this is old.

Now, it isn't from the tests, that much I am sure.  If you change the 
imported module for _threading to 'threading' the tests pass either way.  
For some reason the initial thread created from the _MainThread() 
creation in 'threading' disappears before the end of execution for the 
test.  Not sure why.  Might have something to do with 
dummy_thread.get_ident() always returning -1.  Going to keep looking 
into it.  If it is from dummy_thread.get_ident() returning -1 then it might 
be a slight pain to try to fix.  Might have to come up with some modified 
dict for _active in dummy_threading for the code to use that just 
consistently has a -1 or somehow communicates with 
dummy_thread.get_ident() to keep everything in sync.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 15:16

Message:
Logged In: YES 
user_id=357491

This is just turning into the month of my regression tests breaking, or at 
least my regression tests that decide to play dangeously with 
sys.modules.  =)

I will take a look and see if I can figure this one out this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 04:22:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 04:23:26 2004
Subject: [ python-Bugs-994100 ] seg fault when calling bsddb.hashopen()
Message-ID: <E1BmkGj-0005fd-00@sc8-sf-web4.sourceforge.net>

Bugs item #994100, was opened at 2004-07-19 16:21
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Gregory P. Smith (greg)
Summary: seg fault when calling bsddb.hashopen()

Initial Comment:
Fresh 2.3.4 build (didn't even install!) on Mandrake
8.1-ish system
using Berkeley DB 3.3 yields this output when trying to
create a new hash db:

Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("foo.db", "c")

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 22763)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x404e284b in newDBObject (arg=0x0, flags=0)
    at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:697
#2  0x404ee808 in DB_construct (self=0x0,
args=0x401a602c, kwargs=0x0)
    at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:4322
#3  0x080f718a in PyCFunction_Call (func=0x4047344c,
arg=0x401a602c, kw=0x0)
    at Objects/methodobject.c:93
#4  0x080b122d in call_function (pp_stack=0xbffff31c,
oparg=0)
    at Python/ceval.c:3439
#5  0x080af680 in eval_frame (f=0x8195a0c) at
Python/ceval.c:2116
#6  0x080b0382 in PyEval_EvalCodeEx (co=0x4047ff60,
globals=0x404859bc, 
    locals=0x0, args=0x818e13c, argcount=2,
kws=0x818e144, kwcount=0, 
    defs=0x404868f8, defcount=8, closure=0x0) at
Python/ceval.c:2663
#7  0x080b2ea1 in fast_function (func=0x40486454,
pp_stack=0xbffff4bc, n=2, 
    na=2, nk=0) at Python/ceval.c:3529
#8  0x080b1119 in call_function (pp_stack=0xbffff4bc,
oparg=2)
    at Python/ceval.c:3458
#9  0x080af680 in eval_frame (f=0x818dfec) at
Python/ceval.c:2116
#10 0x080b0382 in PyEval_EvalCodeEx (co=0x4046a920,
globals=0x401bd79c, 
    locals=0x401bd79c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#11 0x080b2dd5 in PyEval_EvalCode (co=0x4046a920,
globals=0x401bd79c, 
    locals=0x401bd79c) at Python/ceval.c:537
#12 0x080d34ab in run_node (n=0x401a6a88,
filename=0x80f9fe8 "<stdin>", 
    globals=0x401bd79c, locals=0x401bd79c,
flags=0xbffff6cc)
    at Python/pythonrun.c:1267
#13 0x080d185c in PyRun_InteractiveOneFlags
(fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", flags=0xbffff6cc) at
Python/pythonrun.c:757
#14 0x080d164e in PyRun_InteractiveLoopFlags
(fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", flags=0xbffff6cc) at
Python/pythonrun.c:690
#15 0x080d2c08 in PyRun_AnyFileExFlags (fp=0x4019cf60, 
    filename=0x80f9fe8 "<stdin>", closeit=0,
flags=0xbffff6cc)
    at Python/pythonrun.c:653
#16 0x0805508c in Py_Main (argc=1, argv=0xbffff7a4) at
Modules/main.c:415
#17 0x08054a99 in main (argc=1, argv=0xbffff7a4) at
Modules/python.c:23
#18 0x400825b0 in __libc_start_main () from /lib/libc.so.6

ldd tells me this is how it's linked:

% ldd build/lib.linux-i686-2.3/_bsddb.so 
	libdb-3.3.so => /lib/libdb-3.3.so (0x40022000)
	libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400b2000)
	libc.so.6 => /lib/libc.so.6 (0x400ba000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

What's the oldest Berkeley DB usable with the
bsddb package?  According to the README file
versions 3.1 through 4.1 are supported.  According
to Modules/_bsddb.c versions 3.2 through 4.2 are
supported.  According to comments in setup.py 3.1
is only partially supported.  I'm wondering if maybe
the bar
has been raised even higher and 3.3 is no longer supported.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-19 21:22

Message:
Logged In: YES 
user_id=44345

I rebuilt it with 3.3, but noticed something I had missed when
it compiled before:

gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I/usr/local/BerkeleyDB.3.2/include -I. -I/home/skip/src/Python-2.3.4/./Include -I/usr/local/include -I/home/skip/src/Python-2.3.4/Include -I/home/skip/src/Python-2.3.4 -c /home/skip/src/Python-2.3.4/Modules/_bsddb.c -o build/temp.linux-i686-2.3/_bsddb.o

gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/lib -ldb-3.3 -o build/lib.linux-i686-2.3/_bsddb.so

Note that it searches /usr/local/BerkeleyDB.3.2/include for include 
files, but fails to search /usr/local/BerkeleyDB.3.2/lib for so files.  
(There are none there, just a .a file.) Consequently, it includes
the 3.2 header files and links against the 3.3 so files.  Definitely
a recipe for disaster.  Here's the proof:

>>> from bsddb import db
>>> print db.DB_VERSION_STRING
Sleepycat Software: Berkeley DB 3.2.9: (January 24, 2001)
>>> print 'bsddb.db.version():   %s' % (db.version(), )
bsddb.db.version():   (3, 3, 11)
>>> print 'bsddb.db.__version__: %s' % db.__version__
bsddb.db.__version__: 4.2.0.2
>>> print 'bsddb.db.cvsid:       %s' % db.cvsid
bsddb.db.cvsid:       $Id: _bsddb.c,v 1.17.6.4 2004/03/16 07:47:45 
greg Exp $

I manually compiled without the -I flag and relinked.  Opening
a new db file worked like a charm.

It would thus appear to be a combination of an incomplete 3.2
installation coupled with maybe some subtle breakage in
setup.py.

I'll leave it for you to close.  I don't know if it's worth comparing
information from the header files and the shared library during
import.  It certainly would have helped here though.


----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2004-07-19 17:05

Message:
Logged In: YES 
user_id=413

it -should- work with 3.2 and later.  that said, its been a
while since i've tested using 3.2 or 3.3.  Can you do one
more thing for me against your _bsddb.so that appearred to
be linked with 3.3?

    from bsddb import db
    print db.DB_VERSION_STRING
    print 'bsddb.db.version():   %s' % (db.version(), )
    print 'bsddb.db.__version__: %s' % db.__version__
    print 'bsddb.db.cvsid:       %s' % db.cvsid

just to make sure that the header files it compiled with
match the version the dynamic loader decided to link it
with.  i've seen problems with that in the past.

i'll built it against 3.2 and 3.3 later tonight and run the
testsuites locally.  if it doesn't work with those without
an obvious reason+fix i'll just mark them as unsupported. 
4.0 has been around for a long time now.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-19 16:43

Message:
Logged In: YES 
user_id=44345

I downloaded and installed BerkDB 4.2.52, then rebuilt bsddb
using it.  The
results are more promising:

% ./python
Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("junk.db", "c")
{}
>>> 
You have new mail in /var/spool/mail/skip
% ldd build/lib.linux-i686-2.3/_bsddb.so 
	libdb-4.2.so => /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
(0x40016000)
	libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400d4000)
	libc.so.6 => /lib/libc.so.6 (0x400dc000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 04:29:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 04:30:02 2004
Subject: [ python-Bugs-986795 ] New mandatory 2nd argument to
	site.addsitedir breaks compat
Message-ID: <E1BmkOE-0003Lb-00@sc8-sf-web1.sourceforge.net>

Bugs item #986795, was opened at 2004-07-07 11:56
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Brett Cannon (bcannon)
Summary: New mandatory 2nd argument to site.addsitedir breaks compat

Initial Comment:

  Old .pth files now raise a TypeError, which site.py
does not catch, which causes the import of site.py to fail.

  The new required parameter is also undocumented and,
on a cursory inspection, it is unclear to me what its
purpose is.

  This comes up because Debian allows for a version
neutral site-packages directory, /usr/lib/site-python/,
into which .pth files can be placed.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 19:29

Message:
Logged In: YES 
user_id=357491

OK, fixed in rev. 1.64.  Hopefully no one else is using undocumented 
functions in site.py .  =)

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2004-07-19 09:08

Message:
Logged In: YES 
user_id=366566

userlib.pth attached.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-15 22:49

Message:
Logged In: YES 
user_id=357491

I fixed the argument requirement, but I was waiting to here from JP 
about the TypeError issue since I have no clue where that is coming from 
(tests I have in test_site haven't shown any issue).

If you could double-check my test for .pth files in test_site and say they 
look good I will go ahead and close this.  Otherwise I want to wait a little 
while to give JP a chance to upload a .pth file that is causing trouble.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-15 17:50

Message:
Logged In: YES 
user_id=33168

Brett, didn't you fix this?  Can it be closed?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-09 16:35

Message:
Logged In: YES 
user_id=357491

Yes, it is my change, but the one call to the function has the argument 
and the function is undocumented so I didn't worry about it.  As for its 
use, it allowed me to get rid of the nasty global variable that every 
function assumed was there for basic sys.path duplication checks.

I have gone ahead and made it optional.

As for the .pth errors, the test suite tests .pth files and the test passes.  
Do you have an example .pth file, JP, that I can test against?  How about 
the traceback of the exception?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-07 18:30

Message:
Logged In: YES 
user_id=33168

Brett, did this happen from your changes?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=986795&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 04:59:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 04:59:48 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1Bmkr0-0006gL-00@sc8-sf-web4.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 11:31
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 19:59

Message:
Logged In: YES 
user_id=357491

OK, problem goes away if you add a currentThread() call in __exitfunc() 
(line 607).  This gives the desired side-effect all while being safe from 
causing shutdown problems since that function is only called by atexit.  
And I am about to run the whole test suite to make sure it doesn't cause 
evil to appear somewhere else.  =)

Does that solution work for you, Tim?

Otherwise I am afraid I am going to have to come up with a custom dict 
for threading._active that dummy_threading injects into its copy that 
tries to handle this properly.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 19:13

Message:
Logged In: YES 
user_id=357491

Can't add those lines back in without breaking the fixes to allow 
tracebacks triggered during interpreter shutdown from failing.  And I 
don't think doing it at the beginning will solve it since it will still be 
overwritten by subsequent threads in threading._active anyway.  Could 
be fixed if the call is made in the method registered with atexit.

Plan on spending tonight on this one.  Hopefully I will come up with 
something.  =)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-19 16:57

Message:
Logged In: YES 
user_id=31435

Then I think you'll find the answer if you do

cvs diff -r r234 -r release23-maint threading.py

I was using the released 2.3.4 Python.  But on the current 
2.3 maint branch, you removed two lines like this:

        currentThread() # for side-effect

These *were* unconditionally executed in 2.3.4, but don't 
exist on the current 2.3 branch, or on HEAD.

I expect that explains why this didn't fail in 2.3.4.  I don't 
know that reverting those lines is a correct (or even the 
best) solution, though.  Perhaps doing currentThread() once, 
from the main thread, at the start of threading's shutdown 
dance, would be enough.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 23:13

Message:
Logged In: YES 
user_id=357491

OK, on the way to figuring this out, I think.

Line 503 of Lib/threading.py has the statement ``assert self is not 
currentThread()``.  Now currentThread() creates an instance of 
_DummyThread for the current thread and inserts it into 
threading._active with the key of threading._get_ident(), which is -1 for 
all dummy_threading Threads.

Problem is that this doesn't happen under -O so threading._active doesn't 
get an entry for -1 like the exit func expects there to be and thus leads 
to an error.  You can uncomment line 645 to see the difference when the 
test is run.

As for it being a new error in 2.4, my CVS checkout for 2.3 has this error 
as well.  Even if I back Lib/threading back to version 1.40 (before I made 
changes for printing the traceback from shutdown errors) and 
dummy_threading before Jim's threading local stuff (which puts it to the 
initial checkin) I still get the error.  So from what I can tell this is old.

Now, it isn't from the tests, that much I am sure.  If you change the 
imported module for _threading to 'threading' the tests pass either way.  
For some reason the initial thread created from the _MainThread() 
creation in 'threading' disappears before the end of execution for the 
test.  Not sure why.  Might have something to do with 
dummy_thread.get_ident() always returning -1.  Going to keep looking 
into it.  If it is from dummy_thread.get_ident() returning -1 then it might 
be a slight pain to try to fix.  Might have to come up with some modified 
dict for _active in dummy_threading for the code to use that just 
consistently has a -1 or somehow communicates with 
dummy_thread.get_ident() to keep everything in sync.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 15:16

Message:
Logged In: YES 
user_id=357491

This is just turning into the month of my regression tests breaking, or at 
least my regression tests that decide to play dangeously with 
sys.modules.  =)

I will take a look and see if I can figure this one out this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 05:19:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 05:19:26 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1Bml9y-0007GI-00@sc8-sf-web4.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 14:31
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-19 23:19

Message:
Logged In: YES 
user_id=31435

I don't think that will hurt anything.  "The real problem" is of 
course that len(_active) should be the number of threads, 
and get_ident() should return a different int for each thread.  
That seems painful to do if there aren't really different 
threads.

An alternative would be to suppress KeyError in __delete().

Another alternative would be to suppress KeyError in __delete
() iff dummy_threading is in use.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 22:59

Message:
Logged In: YES 
user_id=357491

OK, problem goes away if you add a currentThread() call in __exitfunc() 
(line 607).  This gives the desired side-effect all while being safe from 
causing shutdown problems since that function is only called by atexit.  
And I am about to run the whole test suite to make sure it doesn't cause 
evil to appear somewhere else.  =)

Does that solution work for you, Tim?

Otherwise I am afraid I am going to have to come up with a custom dict 
for threading._active that dummy_threading injects into its copy that 
tries to handle this properly.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 22:13

Message:
Logged In: YES 
user_id=357491

Can't add those lines back in without breaking the fixes to allow 
tracebacks triggered during interpreter shutdown from failing.  And I 
don't think doing it at the beginning will solve it since it will still be 
overwritten by subsequent threads in threading._active anyway.  Could 
be fixed if the call is made in the method registered with atexit.

Plan on spending tonight on this one.  Hopefully I will come up with 
something.  =)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-19 19:57

Message:
Logged In: YES 
user_id=31435

Then I think you'll find the answer if you do

cvs diff -r r234 -r release23-maint threading.py

I was using the released 2.3.4 Python.  But on the current 
2.3 maint branch, you removed two lines like this:

        currentThread() # for side-effect

These *were* unconditionally executed in 2.3.4, but don't 
exist on the current 2.3 branch, or on HEAD.

I expect that explains why this didn't fail in 2.3.4.  I don't 
know that reverting those lines is a correct (or even the 
best) solution, though.  Perhaps doing currentThread() once, 
from the main thread, at the start of threading's shutdown 
dance, would be enough.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 02:13

Message:
Logged In: YES 
user_id=357491

OK, on the way to figuring this out, I think.

Line 503 of Lib/threading.py has the statement ``assert self is not 
currentThread()``.  Now currentThread() creates an instance of 
_DummyThread for the current thread and inserts it into 
threading._active with the key of threading._get_ident(), which is -1 for 
all dummy_threading Threads.

Problem is that this doesn't happen under -O so threading._active doesn't 
get an entry for -1 like the exit func expects there to be and thus leads 
to an error.  You can uncomment line 645 to see the difference when the 
test is run.

As for it being a new error in 2.4, my CVS checkout for 2.3 has this error 
as well.  Even if I back Lib/threading back to version 1.40 (before I made 
changes for printing the traceback from shutdown errors) and 
dummy_threading before Jim's threading local stuff (which puts it to the 
initial checkin) I still get the error.  So from what I can tell this is old.

Now, it isn't from the tests, that much I am sure.  If you change the 
imported module for _threading to 'threading' the tests pass either way.  
For some reason the initial thread created from the _MainThread() 
creation in 'threading' disappears before the end of execution for the 
test.  Not sure why.  Might have something to do with 
dummy_thread.get_ident() always returning -1.  Going to keep looking 
into it.  If it is from dummy_thread.get_ident() returning -1 then it might 
be a slight pain to try to fix.  Might have to come up with some modified 
dict for _active in dummy_threading for the code to use that just 
consistently has a -1 or somehow communicates with 
dummy_thread.get_ident() to keep everything in sync.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 18:16

Message:
Logged In: YES 
user_id=357491

This is just turning into the month of my regression tests breaking, or at 
least my regression tests that decide to play dangeously with 
sys.modules.  =)

I will take a look and see if I can figure this one out this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 05:36:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 05:36:55 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BmlQx-0002Ed-00@sc8-sf-web3.sourceforge.net>

Bugs item #994255, was opened at 2004-07-20 00:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 12:11:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 12:11:39 2004
Subject: [ python-Bugs-994416 ] logging module: default levels do not work
	as documented.
Message-ID: <E1Bmrat-00081B-00@sc8-sf-web3.sourceforge.net>

Bugs item #994416, was opened at 2004-07-20 06:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994416&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module: default levels do not work as documented.

Initial Comment:
I'm running:

Roy-Smiths-Computer:unit$ uname -a
Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc

Roy-Smiths-Computer:unit$ py
Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

Under "6.28.2 Handler Objects", it says:

"setLevel(lvl)  Sets the threshold for this handler to lvl. Logging 
messages which are less severe than lvl will be ignored. When a 
handler is created, the level is set to NOTSET (which causes all 
messages to be processed)."

The default level of NOTSET does not work as advertised.  The 
attached program prints:

---------------
ERROR two
DEBUG three
ERROR four
---------------

The first line, "DEBUG one", was not processed.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994416&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 12:28:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 12:28:05 2004
Subject: [ python-Bugs-994421 ] logging module prints unexpected message
	when no handler set
Message-ID: <E1Bmrqs-0003qy-00@sc8-sf-web2.sourceforge.net>

Bugs item #994421, was opened at 2004-07-20 06:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging module prints unexpected message when no handler set

Initial Comment:
I am running:

Roy-Smiths-Computer:unit$ uname -a
Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc
Roy-Smiths-Computer:unit$ py
Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

---------
#!/usr/bin/env python

import logging

logger = logging.getLogger ()
logger.error ('one')
logger.error ('two')
---------

The above program prints (to stderr):

---------
No handlers could be found for logger "root"
---------

6.28 logging --  Logging facility for Python says, "Each logger can 
have zero, one or more handlers associated with it".  It doesn't 
explicitly says what happens when there are zero handlers, but I 
would expect that any messages would just be silently ignored.  
Printing a warning to stderr is definately the WRONG thing to do.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 13:25:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 13:25:54 2004
Subject: [ python-Bugs-994421 ] logging module prints unexpected message
	when no handler set
Message-ID: <E1Bmskj-0006lJ-00@sc8-sf-web4.sourceforge.net>

Bugs item #994421, was opened at 2004-07-20 05:28
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Roy Smith (roysmith)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging module prints unexpected message when no handler set

Initial Comment:
I am running:

Roy-Smiths-Computer:unit$ uname -a
Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc
Roy-Smiths-Computer:unit$ py
Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

---------
#!/usr/bin/env python

import logging

logger = logging.getLogger ()
logger.error ('one')
logger.error ('two')
---------

The above program prints (to stderr):

---------
No handlers could be found for logger "root"
---------

6.28 logging --  Logging facility for Python says, "Each logger can 
have zero, one or more handlers associated with it".  It doesn't 
explicitly says what happens when there are zero handlers, but I 
would expect that any messages would just be silently ignored.  
Printing a warning to stderr is definately the WRONG thing to do.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 13:26:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 13:26:31 2004
Subject: [ python-Bugs-994416 ] logging module: default levels do not work
	as documented.
Message-ID: <E1BmslO-0006ni-00@sc8-sf-web4.sourceforge.net>

Bugs item #994416, was opened at 2004-07-20 05:11
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994416&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Roy Smith (roysmith)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging module: default levels do not work as documented.

Initial Comment:
I'm running:

Roy-Smiths-Computer:unit$ uname -a
Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc

Roy-Smiths-Computer:unit$ py
Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

Under "6.28.2 Handler Objects", it says:

"setLevel(lvl)  Sets the threshold for this handler to lvl. Logging 
messages which are less severe than lvl will be ignored. When a 
handler is created, the level is set to NOTSET (which causes all 
messages to be processed)."

The default level of NOTSET does not work as advertised.  The 
attached program prints:

---------------
ERROR two
DEBUG three
ERROR four
---------------

The first line, "DEBUG one", was not processed.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994416&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 13:27:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 13:28:07 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BmsmA-0006px-00@sc8-sf-web4.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 22:36
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 06:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 17:27:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 17:27:54 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BmwWj-0000RJ-00@sc8-sf-web2.sourceforge.net>

Bugs item #994255, was opened at 2004-07-20 00:36
Message generated for change (Comment added) made by thiagocorrea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Correa (thiagocorrea)
Date: 2004-07-20 12:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 08:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 17:29:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 17:29:33 2004
Subject: [ python-Bugs-994580 ] typo in time.tzset's docstring
Message-ID: <E1BmwYb-0007TL-00@sc8-sf-web1.sourceforge.net>

Bugs item #994580, was opened at 2004-07-20 17:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994580&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Marius Gedminas (mgedmin)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in time.tzset's docstring

Initial Comment:
The docstring for time.tzset() talks about "Uniz
timezones".  I assume it means Unix, not Uniz.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994580&group_id=5470
From noreply at sourceforge.net  Tue Jul 20 17:54:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 20 17:54:55 2004
Subject: [ python-Bugs-994605 ] fcntl example is broken
Message-ID: <E1BmwxA-0000LD-00@sc8-sf-web1.sourceforge.net>

Bugs item #994605, was opened at 2004-07-20 15:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994605&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Green (chrisgreen)
Assigned to: Nobody/Anonymous (nobody)
Summary: fcntl example is broken

Initial Comment:
http://www.python.org/doc/current/lib/module-fcntl.html
import os,struct, fcntl
f = open(".zshrc", "r+")
rv = fcntl.fcntl(f, fcntl.F_SETFL, os.O_NDELAY)
lockdata = struct.pack('hhllhh', fcntl.F_WRLCK, 0, 0,
0, 0, 0)
rv = fcntl.fcntl(f,
                 fcntl.F_SETLKW,
                 lockdata)

It was missing an os import and was directly calling
the module 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994605&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 00:10:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 00:10:12 2004
Subject: [ python-Bugs-857297 ] Tarfile and hard-links
Message-ID: <E1Bn2oJ-0007Xq-00@sc8-sf-web2.sourceforge.net>

Bugs item #857297, was opened at 2003-12-09 21:22
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857297&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ricardo Martins (aggression)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Tarfile and hard-links

Initial Comment:
The attachment has a tar.gz file which contains a file
and an hard-link to that file. The Python script
unpacks the tar file to 3 locations: the current
directory, the current directory specified by absolute
path and /tmp). In the machines I've tested it, when
unpacking to /tmp (or any other directory that does not
belongs to the same branch as the current) the
hard-link is not created. Am I missing something ?

I have tested it with the tarfile module that ships
with Python 2.3.2, and with the CVS tarfile module, the
behavior is the same.

Regards
Ricardo Martins

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-20 18:10

Message:
Logged In: YES 
user_id=33168

Checked in as:
 * Lib/tarfile.py; 1.13
 * Lib/test/test_tarfile.py; 1.13
 * Misc/NEWS; 1.1048

Perhaps this should be backported to 2.3?

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2004-03-15 15:54

Message:
Logged In: YES 
user_id=642936

I submitted a patch (#916874) that fixes this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857297&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 00:34:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 00:34:59 2004
Subject: [ python-Bugs-994580 ] typo in time.tzset's docstring
Message-ID: <E1Bn3CD-0008Hf-00@sc8-sf-web2.sourceforge.net>

Bugs item #994580, was opened at 2004-07-20 11:29
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994580&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Marius Gedminas (mgedmin)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: typo in time.tzset's docstring

Initial Comment:
The docstring for time.tzset() talks about "Uniz
timezones".  I assume it means Unix, not Uniz.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-20 18:34

Message:
Logged In: YES 
user_id=33168

Yes, thanks.  Checked in as Modules/timemodule.c 2.143

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994580&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 02:30:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 02:30:54 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1Bn50V-000287-00@sc8-sf-web1.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 11:31
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 17:30

Message:
Logged In: YES 
user_id=357491

I like your last suggestion: doesn't get into side-effect dependence and 
keeps any possible error detection for when threading isn't using 
dummy_thread.

I'll go ahead and commit that fix.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-19 20:19

Message:
Logged In: YES 
user_id=31435

I don't think that will hurt anything.  "The real problem" is of 
course that len(_active) should be the number of threads, 
and get_ident() should return a different int for each thread.  
That seems painful to do if there aren't really different 
threads.

An alternative would be to suppress KeyError in __delete().

Another alternative would be to suppress KeyError in __delete
() iff dummy_threading is in use.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 19:59

Message:
Logged In: YES 
user_id=357491

OK, problem goes away if you add a currentThread() call in __exitfunc() 
(line 607).  This gives the desired side-effect all while being safe from 
causing shutdown problems since that function is only called by atexit.  
And I am about to run the whole test suite to make sure it doesn't cause 
evil to appear somewhere else.  =)

Does that solution work for you, Tim?

Otherwise I am afraid I am going to have to come up with a custom dict 
for threading._active that dummy_threading injects into its copy that 
tries to handle this properly.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 19:13

Message:
Logged In: YES 
user_id=357491

Can't add those lines back in without breaking the fixes to allow 
tracebacks triggered during interpreter shutdown from failing.  And I 
don't think doing it at the beginning will solve it since it will still be 
overwritten by subsequent threads in threading._active anyway.  Could 
be fixed if the call is made in the method registered with atexit.

Plan on spending tonight on this one.  Hopefully I will come up with 
something.  =)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-19 16:57

Message:
Logged In: YES 
user_id=31435

Then I think you'll find the answer if you do

cvs diff -r r234 -r release23-maint threading.py

I was using the released 2.3.4 Python.  But on the current 
2.3 maint branch, you removed two lines like this:

        currentThread() # for side-effect

These *were* unconditionally executed in 2.3.4, but don't 
exist on the current 2.3 branch, or on HEAD.

I expect that explains why this didn't fail in 2.3.4.  I don't 
know that reverting those lines is a correct (or even the 
best) solution, though.  Perhaps doing currentThread() once, 
from the main thread, at the start of threading's shutdown 
dance, would be enough.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 23:13

Message:
Logged In: YES 
user_id=357491

OK, on the way to figuring this out, I think.

Line 503 of Lib/threading.py has the statement ``assert self is not 
currentThread()``.  Now currentThread() creates an instance of 
_DummyThread for the current thread and inserts it into 
threading._active with the key of threading._get_ident(), which is -1 for 
all dummy_threading Threads.

Problem is that this doesn't happen under -O so threading._active doesn't 
get an entry for -1 like the exit func expects there to be and thus leads 
to an error.  You can uncomment line 645 to see the difference when the 
test is run.

As for it being a new error in 2.4, my CVS checkout for 2.3 has this error 
as well.  Even if I back Lib/threading back to version 1.40 (before I made 
changes for printing the traceback from shutdown errors) and 
dummy_threading before Jim's threading local stuff (which puts it to the 
initial checkin) I still get the error.  So from what I can tell this is old.

Now, it isn't from the tests, that much I am sure.  If you change the 
imported module for _threading to 'threading' the tests pass either way.  
For some reason the initial thread created from the _MainThread() 
creation in 'threading' disappears before the end of execution for the 
test.  Not sure why.  Might have something to do with 
dummy_thread.get_ident() always returning -1.  Going to keep looking 
into it.  If it is from dummy_thread.get_ident() returning -1 then it might 
be a slight pain to try to fix.  Might have to come up with some modified 
dict for _active in dummy_threading for the code to use that just 
consistently has a -1 or somehow communicates with 
dummy_thread.get_ident() to keep everything in sync.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 15:16

Message:
Logged In: YES 
user_id=357491

This is just turning into the month of my regression tests breaking, or at 
least my regression tests that decide to play dangeously with 
sys.modules.  =)

I will take a look and see if I can figure this one out this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 02:40:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 02:40:30 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1Bn59k-0003dC-00@sc8-sf-web2.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 20:36
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 17:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 08:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 04:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 03:26:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 03:26:47 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1Bn5sY-0003bU-00@sc8-sf-web1.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 23:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-20 21:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 20:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 11:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 07:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 03:41:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 03:41:26 2004
Subject: [ python-Bugs-994605 ] fcntl example is broken
Message-ID: <E1Bn66j-0005KY-00@sc8-sf-web2.sourceforge.net>

Bugs item #994605, was opened at 2004-07-20 11:54
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994605&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris Green (chrisgreen)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: fcntl example is broken

Initial Comment:
http://www.python.org/doc/current/lib/module-fcntl.html
import os,struct, fcntl
f = open(".zshrc", "r+")
rv = fcntl.fcntl(f, fcntl.F_SETFL, os.O_NDELAY)
lockdata = struct.pack('hhllhh', fcntl.F_WRLCK, 0, 0,
0, 0, 0)
rv = fcntl.fcntl(f,
                 fcntl.F_SETLKW,
                 lockdata)

It was missing an os import and was directly calling
the module 


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-20 21:41

Message:
Logged In: YES 
user_id=33168

Thanks.  Fixed in Doc/lib/libfcntl.tex 1.36

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994605&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 03:46:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 03:46:45 2004
Subject: [ python-Bugs-990911 ] Crash from Rapid Clicks
Message-ID: <E1Bn6Bp-0005UO-00@sc8-sf-web2.sourceforge.net>

Bugs item #990911, was opened at 2004-07-14 10:54
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl (thedisciple)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Crash from Rapid Clicks

Initial Comment:
IDLE crashes when I rapidly (within 1/2 second, maybe) 
click the Run, then Options menus on the menu bar.  
These seem to be the only menus for which the crash 
happens, which is odd.  I'm running Windows XP SP1 on 
an AMD system using Python 2.3.3

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-20 21:46

Message:
Logged In: YES 
user_id=33168

Kurt, have you heard of this before?

----------------------------------------------------------------------

Comment By: Karl (thedisciple)
Date: 2004-07-14 12:04

Message:
Logged In: YES 
user_id=1083575

Update:  With a little more expirimentation I found that it often 
crashes whenever any of the last 3 menus (Options, Windows, 
Help) are clicked. It works fine if another menu is clicked then 
the mouse is moved over one of the last three menus to open 
it.  I also noticed that after crashing the program many times 
to determine the problem, I see about twenty pythonw.exe 
processes running in Windows Task Manager.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 04:26:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 04:26:27 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1Bn6oH-0005fx-00@sc8-sf-web4.sourceforge.net>

Bugs item #994255, was opened at 2004-07-20 00:36
Message generated for change (Comment added) made by thiagocorrea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Correa (thiagocorrea)
Date: 2004-07-20 23:26

Message:
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 22:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 21:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 12:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 08:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 04:56:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 04:57:02 2004
Subject: [ python-Bugs-993394 ] test_dummy_threading vs -O
Message-ID: <E1Bn7Hm-0007dC-00@sc8-sf-web2.sourceforge.net>

Bugs item #993394, was opened at 2004-07-18 11:31
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470

Category: Threads
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Brett Cannon (bcannon)
Summary: test_dummy_threading vs -O

Initial Comment:
In Python 2.4, running test_dummy_threading with -O 
leads to an exception after the test is finished, in 
threading's exit func.  Didn't happen under 2.3.  Sorry, 
no idea why, and as soon as I saw all the fiddling with 
sys.modules I ran screaming in terror <wink>.  Here on 
WinXP:

C:\Python23>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>python -O lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python23>cd \python24

C:\Python24>python lib/test/regrtest.py 
test_dummy_threading # OK
test_dummy_threading
1 test OK.

C:\Python24>python -O lib/test/regrtest.py 
test_dummy_threading # not OK
test_dummy_threading
1 test OK.
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 20, in 
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 607, in 
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 497, in __delete
    del _active[_get_ident()]
KeyError: -1

C:\Python24>

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 19:56

Message:
Logged In: YES 
user_id=357491

OK, fixed in Lib/threading.py for rev. 1.44 in HEAD and rev. 1.38.6.3 for 
release23-maint.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 17:30

Message:
Logged In: YES 
user_id=357491

I like your last suggestion: doesn't get into side-effect dependence and 
keeps any possible error detection for when threading isn't using 
dummy_thread.

I'll go ahead and commit that fix.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-19 20:19

Message:
Logged In: YES 
user_id=31435

I don't think that will hurt anything.  "The real problem" is of 
course that len(_active) should be the number of threads, 
and get_ident() should return a different int for each thread.  
That seems painful to do if there aren't really different 
threads.

An alternative would be to suppress KeyError in __delete().

Another alternative would be to suppress KeyError in __delete
() iff dummy_threading is in use.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 19:59

Message:
Logged In: YES 
user_id=357491

OK, problem goes away if you add a currentThread() call in __exitfunc() 
(line 607).  This gives the desired side-effect all while being safe from 
causing shutdown problems since that function is only called by atexit.  
And I am about to run the whole test suite to make sure it doesn't cause 
evil to appear somewhere else.  =)

Does that solution work for you, Tim?

Otherwise I am afraid I am going to have to come up with a custom dict 
for threading._active that dummy_threading injects into its copy that 
tries to handle this properly.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-19 19:13

Message:
Logged In: YES 
user_id=357491

Can't add those lines back in without breaking the fixes to allow 
tracebacks triggered during interpreter shutdown from failing.  And I 
don't think doing it at the beginning will solve it since it will still be 
overwritten by subsequent threads in threading._active anyway.  Could 
be fixed if the call is made in the method registered with atexit.

Plan on spending tonight on this one.  Hopefully I will come up with 
something.  =)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-19 16:57

Message:
Logged In: YES 
user_id=31435

Then I think you'll find the answer if you do

cvs diff -r r234 -r release23-maint threading.py

I was using the released 2.3.4 Python.  But on the current 
2.3 maint branch, you removed two lines like this:

        currentThread() # for side-effect

These *were* unconditionally executed in 2.3.4, but don't 
exist on the current 2.3 branch, or on HEAD.

I expect that explains why this didn't fail in 2.3.4.  I don't 
know that reverting those lines is a correct (or even the 
best) solution, though.  Perhaps doing currentThread() once, 
from the main thread, at the start of threading's shutdown 
dance, would be enough.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 23:13

Message:
Logged In: YES 
user_id=357491

OK, on the way to figuring this out, I think.

Line 503 of Lib/threading.py has the statement ``assert self is not 
currentThread()``.  Now currentThread() creates an instance of 
_DummyThread for the current thread and inserts it into 
threading._active with the key of threading._get_ident(), which is -1 for 
all dummy_threading Threads.

Problem is that this doesn't happen under -O so threading._active doesn't 
get an entry for -1 like the exit func expects there to be and thus leads 
to an error.  You can uncomment line 645 to see the difference when the 
test is run.

As for it being a new error in 2.4, my CVS checkout for 2.3 has this error 
as well.  Even if I back Lib/threading back to version 1.40 (before I made 
changes for printing the traceback from shutdown errors) and 
dummy_threading before Jim's threading local stuff (which puts it to the 
initial checkin) I still get the error.  So from what I can tell this is old.

Now, it isn't from the tests, that much I am sure.  If you change the 
imported module for _threading to 'threading' the tests pass either way.  
For some reason the initial thread created from the _MainThread() 
creation in 'threading' disappears before the end of execution for the 
test.  Not sure why.  Might have something to do with 
dummy_thread.get_ident() always returning -1.  Going to keep looking 
into it.  If it is from dummy_thread.get_ident() returning -1 then it might 
be a slight pain to try to fix.  Might have to come up with some modified 
dict for _active in dummy_threading for the code to use that just 
consistently has a -1 or somehow communicates with 
dummy_thread.get_ident() to keep everything in sync.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-18 15:16

Message:
Logged In: YES 
user_id=357491

This is just turning into the month of my regression tests breaking, or at 
least my regression tests that decide to play dangeously with 
sys.modules.  =)

I will take a look and see if I can figure this one out this week.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993394&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 05:05:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 05:05:17 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1Bn7Pl-0006SP-00@sc8-sf-web1.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 23:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-20 23:05

Message:
Logged In: YES 
user_id=31435

There are at least 27 macros in core Python that use this 
standard C idiom, and you're the first person to raise an 
objection.  I recommend closing this as "Won't Fix" -- unless 
you have a much simpler suggestion than rewriting all these 
things.  More mounds of C preprocessor convolution would 
harm maintainability and readablity for everyone, and if that's 
the tradeoff, I'd rather you learn how to set an appropriate 
warning level when compiling Python sources.

BTW, Python uses /W3.  As the MS docs say, "[/W4] should 
be used only to provide 'lint' level warnings and is not 
recommended as your usual warning level setting".  We 
promise no warnings at /W3, but that's all.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 22:26

Message:
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 21:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 20:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 11:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 07:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 05:16:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 05:17:02 2004
Subject: [ python-Bugs-984714 ] unknown parsing error
Message-ID: <E1Bn7bC-00078A-00@sc8-sf-web4.sourceforge.net>

Bugs item #984714, was opened at 2004-07-03 15:39
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984714&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Igor Sidorenkov (gazum)
>Assigned to: Martin v. L?wis (loewis)
Summary: unknown parsing error

Initial Comment:
I am getting "unknown parsing error" when trying to run 
a script with a following first line: 
#@+leo-encoding=cp1251.

If I add a couple of empty lines or 
# -*- coding: cp1251 -*-
then everything is ok.

I am using ActiveState python 2.3.3 on
Win2K server.

---------- Python ----------
error=22
  File "test.py", line 1
SyntaxError: unknown parsing error

Output completed (0 sec consumed) - Normal 
Termination
------------------------------
#@+leo-encoding=cp1251.
#@+node:0::@file test.py
#@+body
for i in range(5):
	print i
#@-body
#@-node:0::@file test.py
#@-leo


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-20 23:16

Message:
Logged In: YES 
user_id=33168

Martin, I hope you don't mind me assigning this to you.  I
think you implemented the coding spec.  I briefly read the
PEP and while the code does what the PEP states (ie, use a
regex), the behaviour doesn't match the examples.  It also
seems like it could be error prone to allow r'#.*coding[:=]'

I think there are two issues.  
1) in pythonrun.c in E_DECODE there is a missing break
2) the check for # -*- coding is not strict enough
    The patch makes the check r'# (-\*-)? coding[:=]'

The attached patch addresses both issues, although I'm not
sure you will agree #2 is a problem.  

Feel free to checkin, assign back to me or whatever.  I'm
not sure what the error message in pythonrun should be,
right now it's "unknown decode error."  Perhaps that should
be "invalid encoding" or something?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984714&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 05:35:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 05:35:23 2004
Subject: [ python-Bugs-990954 ] IDLE displays wrong help pages on Windows
Message-ID: <E1Bn7sz-0007YM-00@sc8-sf-web4.sourceforge.net>

Bugs item #990954, was opened at 2004-07-14 10:47
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990954&group_id=5470

Category: IDLE
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Thomas Heller (theller)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE displays wrong help pages on Windows

Initial Comment:
In 2.4a1, installed from the MSI installer, IDLE
doesn't open the CHM file to display the Python help
pages, instead it opens a browser which displays
http://www.python.org/doc/current.

I have no idea if this is related to the MSI installer
or not.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-07-20 22:35

Message:
Logged In: YES 
user_id=149084

Typo at 1.54

EditorWindow 1.61

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-07-14 20:31

Message:
Logged In: YES 
user_id=149084

If IDLE can't find the .chm files it will use the website.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990954&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 06:47:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 06:47:21 2004
Subject: [ python-Bugs-779147 ] FutureWarning in Carbon/Controls.py
Message-ID: <E1Bn90d-0000zs-00@sc8-sf-web4.sourceforge.net>

Bugs item #779147, was opened at 2003-07-28 13:27
Message generated for change (Comment added) made by kasplat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779147&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Jack Jansen (jackjansen)
Summary: FutureWarning in Carbon/Controls.py

Initial Comment:
While building a wxPython standalone with 
bundlebuilder.py I got the following warning that I hadn't 
seen before. Just in case this is an issue for 2.3rc2 I 
thought I should bring it up here.

Finding module dependencies
/Library/Frameworks/Python.framework/Versions/2.3/lib/p
ython2.3/plat-mac/Carbon/Controls.py:11: 
FutureWarning: hex/oct constants &gt; sys.maxint will 
return positive values in Python 2.4 and up
   kDataBrowserClientPropertyFlagsMask = 0xFF000000

ka

----------------------------------------------------------------------

>Comment By: Kevin Altis (kasplat)
Date: 2004-07-20 21:47

Message:
Logged In: YES 
user_id=228025

Just doing some house cleaning. This probably should have been closed 
last summer.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-08-03 12:48

Message:
Logged In: YES 
user_id=593130

This is a new warning intentionally added to 2.3.  It means 
just what it says, to warn you in case the planned change 
will break your code.  Check the PEP on int/long unification, 
discussions on c.l.py and pydev, and I presume, somewhere 
in the 2.3 release docs.  If you still have questions, ask on 
c.l.py.

Unless you still see a bug, please close his (I can't).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779147&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 06:49:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 06:49:34 2004
Subject: [ python-Feature Requests-498855 ] add POST support to webbrowser
	module
Message-ID: <E1Bn92p-0002EK-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #498855, was opened at 2002-01-02 22:58
Message generated for change (Settings changed) made by kasplat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Nobody/Anonymous (nobody)
Summary: add POST support to webbrowser module

Initial Comment:
This is certainly possible with Internet Explorer 
under Windows, but I'm not sure about all the other 
browsers and platforms. With IE the POST data must 
be &quot;packed&quot;.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-05 19:45

Message:
Logged In: YES 
user_id=6380

I'm still waiting for an *actual situation* where this need
has arisen.

----------------------------------------------------------------------

Comment By: Kevin Altis (kasplat)
Date: 2002-01-05 19:33

Message:
Logged In: YES 
user_id=228025

If you want to direct a user's browser to a web page that 
is the result of a POST. As I stated earlier, it is not 
always possible to get to the same page using GET.

If this isn't possible on other browsers on other platforms 
then it might be best to just note this feature request in 
the webbrowser docs so that the issue isn't raised again. 
As mentioned earlier, a Windows script can always drive IE 
via COM or DDE if needed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-03 11:08

Message:
Logged In: YES 
user_id=6380

I still don't understand why you would need to do this.

urllib supports POST.

But the webbrowser module directs the user's browser to a
website. Can you give an *example* of when you need this?
Otherwise I'll just reject it -- I don't think this is
possible anyway for most browsers except IE.

----------------------------------------------------------------------

Comment By: Kevin Altis (kasplat)
Date: 2002-01-03 10:58

Message:
Logged In: YES 
user_id=228025

If POST is not supported, there is a limit to the size of 
data that you can send; the limit will be different 
depending on each browser, but will always be less than 4K 
URL length limit.

Many sites don't accept GET instead of POST for form data. 
Unfortunately, it is often difficult to tell whether a site 
accepts GET without changing the form manually and 
attempting a GET. Sometimes the reason that GET isn't 
accepted is do to lazy programming, but since a user can't 
do anything about that they still end up needing POST.

Other times it is specifically because a site doesn't want 
the POST data to be cached. Any GET request will end up 
getting cached in proxies, show up in server logs, and also 
cached on the local client. All of these are bad from a 
security standpoint. POST data is never cached.

This is not a critical addition to the webbrowser module, 
it simply makes it more complete. It is still possible to 
do POST another way and Windows programs can always drive 
Internet Explorer via COM or DDE, but I think POST in 
webbrowser would make a nice addition for the future.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-03 05:44

Message:
Logged In: YES 
user_id=6380

Why would you need this? I find it hard to imagine a
situation where I'd need this. Almost any forms that I would
want to reach through webbrowser support GET anyway.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=498855&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 07:36:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 07:36:45 2004
Subject: [ python-Bugs-984714 ] unknown parsing error
Message-ID: <E1Bn9mS-0002Fa-00@sc8-sf-web4.sourceforge.net>

Bugs item #984714, was opened at 2004-07-03 21:39
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984714&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Igor Sidorenkov (gazum)
Assigned to: Martin v. L?wis (loewis)
Summary: unknown parsing error

Initial Comment:
I am getting "unknown parsing error" when trying to run 
a script with a following first line: 
#@+leo-encoding=cp1251.

If I add a couple of empty lines or 
# -*- coding: cp1251 -*-
then everything is ok.

I am using ActiveState python 2.3.3 on
Win2K server.

---------- Python ----------
error=22
  File "test.py", line 1
SyntaxError: unknown parsing error

Output completed (0 sec consumed) - Normal 
Termination
------------------------------
#@+leo-encoding=cp1251.
#@+node:0::@file test.py
#@+body
for i in range(5):
	print i
#@-body
#@-node:0::@file test.py
#@-leo


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-21 07:36

Message:
Logged In: YES 
user_id=21627

The patch is wrong. The PEP deliberately allows for
arbitrary occurrences of the substring "coding", in
particular inside "encoding". This was made so that other
editors, like vi or LEO, can continue to use their own
encoding declarations, and Python would recognize them.

Unfortunately, LEO decided to add a full stop at the end of
the line, so Python looks for an encoding named "cp1251.".
We agree with the LEO author that this is a problem in LEO,
and will be fixed. Alternatively, we could amend the PEP and
declare that trailing dots are not part of the encoding name.

The other part of the patch is correct; I have applied it as
pythonrun.c 2.195.6.6 and 2.207. It would be even better if
we could display the actual cause of the problem, but that
is currently not supported in the parser.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-21 05:16

Message:
Logged In: YES 
user_id=33168

Martin, I hope you don't mind me assigning this to you.  I
think you implemented the coding spec.  I briefly read the
PEP and while the code does what the PEP states (ie, use a
regex), the behaviour doesn't match the examples.  It also
seems like it could be error prone to allow r'#.*coding[:=]'

I think there are two issues.  
1) in pythonrun.c in E_DECODE there is a missing break
2) the check for # -*- coding is not strict enough
    The patch makes the check r'# (-\*-)? coding[:=]'

The attached patch addresses both issues, although I'm not
sure you will agree #2 is a problem.  

Feel free to checkin, assign back to me or whatever.  I'm
not sure what the error message in pythonrun should be,
right now it's "unknown decode error."  Perhaps that should
be "invalid encoding" or something?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984714&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 08:19:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 08:19:44 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnAS5-0003YX-00@sc8-sf-web4.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 02:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 08:27:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 08:27:06 2004
Subject: [ python-Bugs-995023 ] Should build Python dylib with -single_module
Message-ID: <E1BnAZB-0003oF-00@sc8-sf-web4.sourceforge.net>

Bugs item #995023, was opened at 2004-07-21 02:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995023&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Should build Python dylib with -single_module

Initial Comment:
According to bbum, dylibs built with -single_module load 
significantly faster.  The default is not -single_module.  A typical 
build of Python will have ~190 modules, when it could have just 
one.  To check to see how many modules a dylib has, use otool -
Mv on the dylib.

Note that this is NOT for building extensions, only for building the 
dylib for Python itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995023&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 08:29:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 08:29:36 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnAbV-0003z4-00@sc8-sf-web1.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 02:19
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 02:29

Message:
Logged In: YES 
user_id=139309

[I'm closing 995023, because bbum filed first]

distutils extensions can not use -single_module because they are 
bundles, not dylibs.  Frameworks and dylibs are synonymous, of course.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 08:35:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 08:35:34 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnAhG-00045D-00@sc8-sf-web4.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 02:19
Message generated for change (Comment added) made by bbum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

>Comment By: Bill Bumgarner (bbum)
Date: 2004-07-21 02:35

Message:
Logged In: YES 
user_id=103811

This is not applicable to the distutils modules as they are built now;  
only applicable to Python.framework (and like builds).


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 02:29

Message:
Logged In: YES 
user_id=139309

[I'm closing 995023, because bbum filed first]

distutils extensions can not use -single_module because they are 
bundles, not dylibs.  Frameworks and dylibs are synonymous, of course.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 08:37:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 08:38:05 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnAjj-00048U-00@sc8-sf-web4.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 02:19
Message generated for change (Settings changed) made by bbum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
>Assigned to: Jack Jansen (jackjansen)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2004-07-21 02:35

Message:
Logged In: YES 
user_id=103811

This is not applicable to the distutils modules as they are built now;  
only applicable to Python.framework (and like builds).


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 02:29

Message:
Logged In: YES 
user_id=139309

[I'm closing 995023, because bbum filed first]

distutils extensions can not use -single_module because they are 
bundles, not dylibs.  Frameworks and dylibs are synonymous, of course.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 08:49:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 08:49:34 2004
Subject: [ python-Bugs-995023 ] Should build Python dylib with -single_module
Message-ID: <E1BnAuv-0001PC-00@sc8-sf-web3.sourceforge.net>

Bugs item #995023, was opened at 2004-07-21 02:27
Message generated for change (Settings changed) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995023&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
>Resolution: Duplicate
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Should build Python dylib with -single_module

Initial Comment:
According to bbum, dylibs built with -single_module load 
significantly faster.  The default is not -single_module.  A typical 
build of Python will have ~190 modules, when it could have just 
one.  To check to see how many modules a dylib has, use otool -
Mv on the dylib.

Note that this is NOT for building extensions, only for building the 
dylib for Python itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995023&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 08:49:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 08:49:53 2004
Subject: [ python-Bugs-995023 ] Should build Python dylib with -single_module
Message-ID: <E1BnAvE-0001PX-00@sc8-sf-web3.sourceforge.net>

Bugs item #995023, was opened at 2004-07-21 02:27
Message generated for change (Settings changed) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995023&group_id=5470

Category: Macintosh
Group: Platform-specific
>Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Jack Jansen (jackjansen)
Summary: Should build Python dylib with -single_module

Initial Comment:
According to bbum, dylibs built with -single_module load 
significantly faster.  The default is not -single_module.  A typical 
build of Python will have ~190 modules, when it could have just 
one.  To check to see how many modules a dylib has, use otool -
Mv on the dylib.

Note that this is NOT for building extensions, only for building the 
dylib for Python itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995023&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 08:57:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 08:57:48 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnB2q-0004vB-00@sc8-sf-web1.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 08:19
Message generated for change (Comment added) made by sjoerd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jack Jansen (jackjansen)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-21 08:57

Message:
Logged In: YES 
user_id=43607

Is this related to bug 799088?

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2004-07-21 08:35

Message:
Logged In: YES 
user_id=103811

This is not applicable to the distutils modules as they are built now;  
only applicable to Python.framework (and like builds).


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 08:29

Message:
Logged In: YES 
user_id=139309

[I'm closing 995023, because bbum filed first]

distutils extensions can not use -single_module because they are 
bundles, not dylibs.  Frameworks and dylibs are synonymous, of course.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 09:15:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 09:15:32 2004
Subject: [ python-Bugs-857297 ] Tarfile and hard-links
Message-ID: <E1BnBK2-0002NS-00@sc8-sf-web3.sourceforge.net>

Bugs item #857297, was opened at 2003-12-10 03:22
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857297&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ricardo Martins (aggression)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Tarfile and hard-links

Initial Comment:
The attachment has a tar.gz file which contains a file
and an hard-link to that file. The Python script
unpacks the tar file to 3 locations: the current
directory, the current directory specified by absolute
path and /tmp). In the machines I've tested it, when
unpacking to /tmp (or any other directory that does not
belongs to the same branch as the current) the
hard-link is not created. Am I missing something ?

I have tested it with the tarfile module that ships
with Python 2.3.2, and with the CVS tarfile module, the
behavior is the same.

Regards
Ricardo Martins

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2004-07-21 09:15

Message:
Logged In: YES 
user_id=642936

Yes, it should be backported.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-21 00:10

Message:
Logged In: YES 
user_id=33168

Checked in as:
 * Lib/tarfile.py; 1.13
 * Lib/test/test_tarfile.py; 1.13
 * Misc/NEWS; 1.1048

Perhaps this should be backported to 2.3?

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2004-03-15 21:54

Message:
Logged In: YES 
user_id=642936

I submitted a patch (#916874) that fixes this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857297&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 10:25:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 10:25:51 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnCPz-0000zi-00@sc8-sf-web2.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 02:19
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jack Jansen (jackjansen)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 04:25

Message:
Logged In: YES 
user_id=139309

Not in the least.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-21 02:57

Message:
Logged In: YES 
user_id=43607

Is this related to bug 799088?

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2004-07-21 02:35

Message:
Logged In: YES 
user_id=103811

This is not applicable to the distutils modules as they are built now;  
only applicable to Python.framework (and like builds).


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 02:29

Message:
Logged In: YES 
user_id=139309

[I'm closing 995023, because bbum filed first]

distutils extensions can not use -single_module because they are 
bundles, not dylibs.  Frameworks and dylibs are synonymous, of course.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 11:21:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 11:21:52 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnDIH-0007N6-00@sc8-sf-web3.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 08:19
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jack Jansen (jackjansen)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-21 11:21

Message:
Logged In: YES 
user_id=45365

Could either of you come up with a patch? Also, how would I measure 
any improvement, "time python -c pass" or are there other things that 
are influenced as well?

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 10:25

Message:
Logged In: YES 
user_id=139309

Not in the least.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-21 08:57

Message:
Logged In: YES 
user_id=43607

Is this related to bug 799088?

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2004-07-21 08:35

Message:
Logged In: YES 
user_id=103811

This is not applicable to the distutils modules as they are built now;  
only applicable to Python.framework (and like builds).


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 08:29

Message:
Logged In: YES 
user_id=139309

[I'm closing 995023, because bbum filed first]

distutils extensions can not use -single_module because they are 
bundles, not dylibs.  Frameworks and dylibs are synonymous, of course.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 11:40:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 11:41:00 2004
Subject: [ python-Bugs-995109 ] logging.handlers.RotatingFileHandler missing
	error handling
Message-ID: <E1BnDar-0008G6-00@sc8-sf-web3.sourceforge.net>

Bugs item #995109, was opened at 2004-07-21 12:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995109&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging.handlers.RotatingFileHandler missing error handling

Initial Comment:
If i open('logfile','r') in one shell and in my program
use a RotatingFileHandler using the same 'logfile', then 

os.rename(self.baseFilename, dfn) # line 86 in handlers.py

will fail and no log open, thus subsequent logging
attempts will  trigger a ValueError and render the
application in an unusable state.
(File "C:\Python23\lib\logging\handlers.py", line 103,
in emit
    self.stream.seek(0, 2)  #due to non-posix-compliant
Windows feature
ValueError: I/O operation on closed file)

I would have created a patch, but I am unsure of what
the correct behaviour should be?

- one possibility would be to continue logging to the
same file (skip rollover), but that is not ideal behaviour

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995109&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 11:50:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 11:50:25 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnDje-0002tH-00@sc8-sf-web1.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 02:19
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jack Jansen (jackjansen)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 05:50

Message:
Logged In: YES 
user_id=139309

time python -c pass is probably sufficient..

I guess the patch is to line 114 of Makefile.pre.in.. should change from:

OTHER_LIBTOOL_OPT = -prebind -seg1addr 0x10000000

to

OTHER_LIBTOOL_OPT = -prebind -seg1addr 0xCFC00000 -single_module

Note I picked an arbitrary, probably unused, seg1addr.  0x10000000 is 
*NOT* correct!  It's in the Application Address Range!!!! See:
http://developer.apple.com/documentation/Performance/Conceptual/
LaunchTime/index.html

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-07-21 05:21

Message:
Logged In: YES 
user_id=45365

Could either of you come up with a patch? Also, how would I measure 
any improvement, "time python -c pass" or are there other things that 
are influenced as well?

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 04:25

Message:
Logged In: YES 
user_id=139309

Not in the least.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-21 02:57

Message:
Logged In: YES 
user_id=43607

Is this related to bug 799088?

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2004-07-21 02:35

Message:
Logged In: YES 
user_id=103811

This is not applicable to the distutils modules as they are built now;  
only applicable to Python.framework (and like builds).


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 02:29

Message:
Logged In: YES 
user_id=139309

[I'm closing 995023, because bbum filed first]

distutils extensions can not use -single_module because they are 
bundles, not dylibs.  Frameworks and dylibs are synonymous, of course.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 14:13:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 14:13:59 2004
Subject: [ python-Feature Requests-992967 ] array.array objects should
	support sequences
Message-ID: <E1BnFys-0007jW-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #992967, was opened at 2004-07-17 14:30
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: array.array objects should support sequences

Initial Comment:
array objects from the array module have an extend method that 
only takes arrays.  The implementation would be more useful if it 
accepted arbitrary sequences (generators, lists, strings, etc).  
Similarly, the initializer currently only accepts lists and strings, 
but it should also support arbitrary sequences.

>>> from array import array
>>> array('c', iter('1234'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: array initializer must be list or string
>>> array('c').extend('1234')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only extend array with array (not "str")

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2004-07-21 08:13

Message:
Logged In: YES 
user_id=99874

I'll just chime in to agree with Raymond's analysis... the
constructor doesn't need to take general iterables. One can
always construct an empty array and extend it if that's
what's needed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 15:23

Message:
Logged In: YES 
user_id=80475

In Py2.4, I already made extend() take a general iterable. 
The goal was to simplify code doing repeated appends.

By calling array_extend, it should be easy to do the same
for the constructor.  The question is whether there are use
cases to warrant a further API change.  Most needs can
already be met with extend() or with array.array(code,
list(it)).  

My preference is to leave the constructor for cases with a
known sequence length.   With a single pre-allocation and
copy step, the performance is optimal.  I don't think it
would be obvious that using a general iterable would be much
slower and consume more memory than expected.  That's okay
for lists, but people use array when they are tight for
space or have other performance goals.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-19 11:56

Message:
Logged In: YES 
user_id=6656

I agree with your first point.  Should be easy, too.

I'm /slightly/ less enthusiastic about the latter point.  sequence-
>array conversion is sufficiently complex that I'm not sure I want 
it happening automatically.

This is the sort of report that a patch would help immensely, btw 
:-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 14:21:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 14:21:34 2004
Subject: [ python-Feature Requests-992967 ] array.array objects should
	support sequences
Message-ID: <E1BnG6D-00067u-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #992967, was opened at 2004-07-17 14:30
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: array.array objects should support sequences

Initial Comment:
array objects from the array module have an extend method that 
only takes arrays.  The implementation would be more useful if it 
accepted arbitrary sequences (generators, lists, strings, etc).  
Similarly, the initializer currently only accepts lists and strings, 
but it should also support arbitrary sequences.

>>> from array import array
>>> array('c', iter('1234'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: array initializer must be list or string
>>> array('c').extend('1234')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only extend array with array (not "str")

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 08:21

Message:
Logged In: YES 
user_id=139309

One can construct an empty list and extend it too, but for some reason 
they let you make them out of arbitrary iterables.  I wonder why! :)

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-21 08:13

Message:
Logged In: YES 
user_id=99874

I'll just chime in to agree with Raymond's analysis... the
constructor doesn't need to take general iterables. One can
always construct an empty array and extend it if that's
what's needed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 15:23

Message:
Logged In: YES 
user_id=80475

In Py2.4, I already made extend() take a general iterable. 
The goal was to simplify code doing repeated appends.

By calling array_extend, it should be easy to do the same
for the constructor.  The question is whether there are use
cases to warrant a further API change.  Most needs can
already be met with extend() or with array.array(code,
list(it)).  

My preference is to leave the constructor for cases with a
known sequence length.   With a single pre-allocation and
copy step, the performance is optimal.  I don't think it
would be obvious that using a general iterable would be much
slower and consume more memory than expected.  That's okay
for lists, but people use array when they are tight for
space or have other performance goals.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-19 11:56

Message:
Logged In: YES 
user_id=6656

I agree with your first point.  Should be easy, too.

I'm /slightly/ less enthusiastic about the latter point.  sequence-
>array conversion is sufficiently complex that I'm not sure I want 
it happening automatically.

This is the sort of report that a patch would help immensely, btw 
:-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 14:48:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 14:48:35 2004
Subject: [ python-Bugs-995206 ] Deprecation Warning lies when it cannot
	parse your encoding
Message-ID: <E1BnGWN-0002s9-00@sc8-sf-web2.sourceforge.net>

Bugs item #995206, was opened at 2004-07-21 14:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation Warning lies when it cannot parse your encoding

Initial Comment:
The first line of my python file was:
# -*- coding: 'iso-8859-1' -*-

This is wrong, I need to drop the quotes.  But Python
2.3.4 (#2, Jun 19 2004, 18:15:30) is wrong, also, when it
complains:
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file test_stockdict.py on line 14, but no encoding
declared; see http://www.python.org/peps/pep-0263


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 15:02:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 15:02:46 2004
Subject: [ python-Feature Requests-992967 ] array.array objects should
	support sequences
Message-ID: <E1BnGk5-0001PG-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #992967, was opened at 2004-07-17 19:30
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: array.array objects should support sequences

Initial Comment:
array objects from the array module have an extend method that 
only takes arrays.  The implementation would be more useful if it 
accepted arbitrary sequences (generators, lists, strings, etc).  
Similarly, the initializer currently only accepts lists and strings, 
but it should also support arbitrary sequences.

>>> from array import array
>>> array('c', iter('1234'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: array initializer must be list or string
>>> array('c').extend('1234')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only extend array with array (not "str")

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-21 14:02

Message:
Logged In: YES 
user_id=6656

Interesting how intuitions differ :-)

It's just a call to PySequence_FAST, hardly an intrusive
patch (which didn't you use that for array_extend?).

The error message is wrong, btw: tuples are accepted too.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 13:21

Message:
Logged In: YES 
user_id=139309

One can construct an empty list and extend it too, but for some reason 
they let you make them out of arbitrary iterables.  I wonder why! :)

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-21 13:13

Message:
Logged In: YES 
user_id=99874

I'll just chime in to agree with Raymond's analysis... the
constructor doesn't need to take general iterables. One can
always construct an empty array and extend it if that's
what's needed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 20:23

Message:
Logged In: YES 
user_id=80475

In Py2.4, I already made extend() take a general iterable. 
The goal was to simplify code doing repeated appends.

By calling array_extend, it should be easy to do the same
for the constructor.  The question is whether there are use
cases to warrant a further API change.  Most needs can
already be met with extend() or with array.array(code,
list(it)).  

My preference is to leave the constructor for cases with a
known sequence length.   With a single pre-allocation and
copy step, the performance is optimal.  I don't think it
would be obvious that using a general iterable would be much
slower and consume more memory than expected.  That's okay
for lists, but people use array when they are tight for
space or have other performance goals.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-19 16:56

Message:
Logged In: YES 
user_id=6656

I agree with your first point.  Should be easy, too.

I'm /slightly/ less enthusiastic about the latter point.  sequence-
>array conversion is sufficiently complex that I'm not sure I want 
it happening automatically.

This is the sort of report that a patch would help immensely, btw 
:-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 15:20:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 15:20:32 2004
Subject: [ python-Bugs-995206 ] Deprecation Warning lies when it cannot
	parse your encoding
Message-ID: <E1BnH1H-0004BV-00@sc8-sf-web2.sourceforge.net>

Bugs item #995206, was opened at 2004-07-21 14:48
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation Warning lies when it cannot parse your encoding

Initial Comment:
The first line of my python file was:
# -*- coding: 'iso-8859-1' -*-

This is wrong, I need to drop the quotes.  But Python
2.3.4 (#2, Jun 19 2004, 18:15:30) is wrong, also, when it
complains:
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file test_stockdict.py on line 14, but no encoding
declared; see http://www.python.org/peps/pep-0263


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 15:20

Message:
Logged In: YES 
user_id=38388

I don't see why this should be wrong: if the parser cannot
parse the encoding comment, it simply ignores it and then
continues to work as if no encoding comment were given.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 15:52:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 15:52:41 2004
Subject: [ python-Bugs-990325 ] testtar.tar is partially insane
Message-ID: <E1BnHWP-0005Lk-00@sc8-sf-web2.sourceforge.net>

Bugs item #990325, was opened at 2004-07-13 20:00
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990325&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: testtar.tar is partially insane

Initial Comment:
The test file testtar.tar is a binary file, but contains 
(seemingly by accident) CVS keywords, like $Date$ and 
$Revision$.  As a result, if Python is checked out with -
kk (don't expand keywords), test_tarfile fails.  I'm not 
clear on exactly why.

Binary files shouldn't have CVS keywords inside them, 
and tests shouldn't care whether keywords are 
expanded anyway.

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2004-07-21 15:52

Message:
Logged In: YES 
user_id=642936

When I created testtar.tar I used a copy of pep-0000.txt as
dummy data, and that has CVS keywords in it. The problem is,
that -kk substitutes the keywords, although testtar.tar was
checked in with -kb. I blame CVS's rotten handling of binary
files for that one.

I opened a patch #995225 with a new testtar.tar that has no
keywords.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990325&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 16:24:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 16:24:41 2004
Subject: [ python-Bugs-994421 ] logging module prints unexpected message
	when no handler set
Message-ID: <E1BnI1M-00064U-00@sc8-sf-web1.sourceforge.net>

Bugs item #994421, was opened at 2004-07-20 10:28
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module prints unexpected message when no handler set

Initial Comment:
I am running:

Roy-Smiths-Computer:unit$ uname -a
Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc
Roy-Smiths-Computer:unit$ py
Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

---------
#!/usr/bin/env python

import logging

logger = logging.getLogger ()
logger.error ('one')
logger.error ('two')
---------

The above program prints (to stderr):

---------
No handlers could be found for logger "root"
---------

6.28 logging --  Logging facility for Python says, "Each logger can 
have zero, one or more handlers associated with it".  It doesn't 
explicitly says what happens when there are zero handlers, but I 
would expect that any messages would just be silently ignored.  
Printing a warning to stderr is definately the WRONG thing to do.


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-21 14:24

Message:
Logged In: YES 
user_id=308438

This is not a bug. In general, the logging module does not 
print spurious error messages - however, in the case where 
no handlers are configured at all, then this is considered a 
possible configuration error and a single message is printed. 
Note that log4j does this too - it's not peculiar to Python 
logging.

Note that logged messages are not printed - only the single 
warning indicating a possible configuration problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 16:27:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 16:27:53 2004
Subject: [ python-Bugs-994416 ] logging module: default levels do not work
	as documented.
Message-ID: <E1BnI4U-0006BF-00@sc8-sf-web1.sourceforge.net>

Bugs item #994416, was opened at 2004-07-20 10:11
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994416&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module: default levels do not work as documented.

Initial Comment:
I'm running:

Roy-Smiths-Computer:unit$ uname -a
Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc

Roy-Smiths-Computer:unit$ py
Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

Under "6.28.2 Handler Objects", it says:

"setLevel(lvl)  Sets the threshold for this handler to lvl. Logging 
messages which are less severe than lvl will be ignored. When a 
handler is created, the level is set to NOTSET (which causes all 
messages to be processed)."

The default level of NOTSET does not work as advertised.  The 
attached program prints:

---------------
ERROR two
DEBUG three
ERROR four
---------------

The first line, "DEBUG one", was not processed.



----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-21 14:27

Message:
Logged In: YES 
user_id=308438

The level for a handler is different from a level for a logger. 
Filtering first happens at logger level - then at handler level. 
The default level for the root logger is WARNING - hence the 
initial debug message is not printed, but the next one is - 
because you have perviously set the level to DEBUG.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994416&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 16:45:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 16:45:27 2004
Subject: [ python-Bugs-994421 ] logging module prints unexpected message
	when no handler set
Message-ID: <E1BnILQ-0006wO-00@sc8-sf-web1.sourceforge.net>

Bugs item #994421, was opened at 2004-07-20 06:28
Message generated for change (Comment added) made by roysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module prints unexpected message when no handler set

Initial Comment:
I am running:

Roy-Smiths-Computer:unit$ uname -a
Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc
Roy-Smiths-Computer:unit$ py
Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

---------
#!/usr/bin/env python

import logging

logger = logging.getLogger ()
logger.error ('one')
logger.error ('two')
---------

The above program prints (to stderr):

---------
No handlers could be found for logger "root"
---------

6.28 logging --  Logging facility for Python says, "Each logger can 
have zero, one or more handlers associated with it".  It doesn't 
explicitly says what happens when there are zero handlers, but I 
would expect that any messages would just be silently ignored.  
Printing a warning to stderr is definately the WRONG thing to do.


----------------------------------------------------------------------

>Comment By: Roy Smith (roysmith)
Date: 2004-07-21 10:45

Message:
Logged In: YES 
user_id=390499

I disagree.

I don't think it should be considered an error to have a logger with no 
handlers configured (especially since the documentation explicitly states 
that it's allowed).  The logic here is that every handler gets a chance to 
process the message; there's nothing magic about the list of handlers 
being empty.

Here's where this came up:  I've got a class I'm testing.  I embedded 
some logger.debug () calls in it.  Most of the time I don't even want to 
see those calls.  Sure, I could create a logger handler, and set a level 
which ignores debug calls, but that forces every user of my class to do 
that.  If a logger with no handlers attached just silently drops all 
messages, the user doesn't even have to know about the logging calls in 
my class.

Even if you were to decide to enforce that a logger must have at least 
one handler, then the error should be signified the way all other python 
errors are -- by throwing an exception.  And, of course, you should 
update the documention to match.  But, I think this would be the wrong 
approach.  Just eliminating the message to stderr would be (IMHO) the 
right thing to do.


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-21 10:24

Message:
Logged In: YES 
user_id=308438

This is not a bug. In general, the logging module does not 
print spurious error messages - however, in the case where 
no handlers are configured at all, then this is considered a 
possible configuration error and a single message is printed. 
Note that log4j does this too - it's not peculiar to Python 
logging.

Note that logged messages are not printed - only the single 
warning indicating a possible configuration problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 16:45:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 16:46:01 2004
Subject: [ python-Bugs-994421 ] logging module prints unexpected message
	when no handler set
Message-ID: <E1BnILx-0006zX-00@sc8-sf-web1.sourceforge.net>

Bugs item #994421, was opened at 2004-07-20 06:28
Message generated for change (Comment added) made by roysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module prints unexpected message when no handler set

Initial Comment:
I am running:

Roy-Smiths-Computer:unit$ uname -a
Darwin Roy-Smiths-Computer.local 7.4.0 Darwin Kernel Version 
7.4.0: Wed May 12 16:58:24 PDT 2004; root:xnu/xnu
-517.7.7.obj~7/RELEASE_PPC  Power Macintosh powerpc
Roy-Smiths-Computer:unit$ py
Python 2.3.4 (#3, Jun 29 2004, 21:48:03) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.

---------
#!/usr/bin/env python

import logging

logger = logging.getLogger ()
logger.error ('one')
logger.error ('two')
---------

The above program prints (to stderr):

---------
No handlers could be found for logger "root"
---------

6.28 logging --  Logging facility for Python says, "Each logger can 
have zero, one or more handlers associated with it".  It doesn't 
explicitly says what happens when there are zero handlers, but I 
would expect that any messages would just be silently ignored.  
Printing a warning to stderr is definately the WRONG thing to do.


----------------------------------------------------------------------

>Comment By: Roy Smith (roysmith)
Date: 2004-07-21 10:45

Message:
Logged In: YES 
user_id=390499

I disagree.

I don't think it should be considered an error to have a logger with no 
handlers configured (especially since the documentation explicitly states 
that it's allowed).  The logic here is that every handler gets a chance to 
process the message; there's nothing magic about the list of handlers 
being empty.

Here's where this came up:  I've got a class I'm testing.  I embedded 
some logger.debug () calls in it.  Most of the time I don't even want to 
see those calls.  Sure, I could create a logger handler, and set a level 
which ignores debug calls, but that forces every user of my class to do 
that.  If a logger with no handlers attached just silently drops all 
messages, the user doesn't even have to know about the logging calls in 
my class.

Even if you were to decide to enforce that a logger must have at least 
one handler, then the error should be signified the way all other python 
errors are -- by throwing an exception.  And, of course, you should 
update the documention to match.  But, I think this would be the wrong 
approach.  Just eliminating the message to stderr would be (IMHO) the 
right thing to do.


----------------------------------------------------------------------

Comment By: Roy Smith (roysmith)
Date: 2004-07-21 10:45

Message:
Logged In: YES 
user_id=390499

I disagree.

I don't think it should be considered an error to have a logger with no 
handlers configured (especially since the documentation explicitly states 
that it's allowed).  The logic here is that every handler gets a chance to 
process the message; there's nothing magic about the list of handlers 
being empty.

Here's where this came up:  I've got a class I'm testing.  I embedded 
some logger.debug () calls in it.  Most of the time I don't even want to 
see those calls.  Sure, I could create a logger handler, and set a level 
which ignores debug calls, but that forces every user of my class to do 
that.  If a logger with no handlers attached just silently drops all 
messages, the user doesn't even have to know about the logging calls in 
my class.

Even if you were to decide to enforce that a logger must have at least 
one handler, then the error should be signified the way all other python 
errors are -- by throwing an exception.  And, of course, you should 
update the documention to match.  But, I think this would be the wrong 
approach.  Just eliminating the message to stderr would be (IMHO) the 
right thing to do.


----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2004-07-21 10:24

Message:
Logged In: YES 
user_id=308438

This is not a bug. In general, the logging module does not 
print spurious error messages - however, in the case where 
no handlers are configured at all, then this is considered a 
possible configuration error and a single message is printed. 
Note that log4j does this too - it's not peculiar to Python 
logging.

Note that logged messages are not printed - only the single 
warning indicating a possible configuration problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994421&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 17:20:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 17:20:50 2004
Subject: [ python-Bugs-973579 ] Doc error on super(cls,self)
Message-ID: <E1BnIte-0000Z4-00@sc8-sf-web2.sourceforge.net>

Bugs item #973579, was opened at 2004-06-15 15:43
Message generated for change (Comment added) made by macquigg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doc error on super(cls,self)

Initial Comment:
In both the Library Reference, section 2.1, and in the 
Python 2.2 Quick Reference, page 19, the explanation 
for this function is:

super( type[, object-or-type]) 
   Returns the superclass of type. ...

This is misleading.  I could not get this function to work 
right until I realized that it is searching the entire MRO, 
not just the superclasses of 'type'.  See 
comp.lang.python 6/11/04, same subject as above, for 
further discussion and an example.

I think a better explanation would be:

super(cls,self).m(arg)

   Calls method 'm' from a class in the MRO (Method 
Resolution Order) of 'self'.  The selected class is the first 
one which is above 'cls' in the MRO and which 
contains 'm'.

The 'super' built-in function actually returns not a class, 
but a 'super' object.  This object can be saved, like a 
bound method, and later used to do a new search of the 
MRO for a different method to be applied to the saved 
instance.


----------------------------------------------------------------------

>Comment By: David MacQuigg (macquigg)
Date: 2004-07-21 08:20

Message:
Logged In: YES 
user_id=676422

While waiting for the perfect solution, would it be possible to 
have links to this item at the places in the documentation 
where the corrections should be made (Library Reference 2.1, 
Quick Reference page 19)?  It could save an hour of 
experimentation for each new user of this feature.


----------------------------------------------------------------------

Comment By: David MacQuigg (macquigg)
Date: 2004-06-21 09:23

Message:
Logged In: YES 
user_id=676422

I like the example, but the new explanation still leaves the 
impression that super() returns a class ( or something that 
acts like a class).  This is what made super() so difficult to 
figure out the first time I tried it.  The 'super' object returned 
by the function appears to be a collection of references, one 
to the 'self' instance, and one to each of the classes in the 
MRO of self above 'cls'.  The reason it can't be just a class is 
that a given super object needs to retrieve a different class 
each time it is used, depending on what method is provided.

The only thing lacking in the example is motivation for why we 
need super(B,self).meth(arg) instead of just calling C.meth
(self,arg).  I have a longer example and some motivation on 
page 16 in my OOP chapter at 
http://ece.arizona.edu/~edatools/Python/PythonOOP.doc but 
that may be too long if what we need here is a "man page" 
explanation.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-06-21 07:50

Message:
Logged In: YES 
user_id=764593

Would an expanded example also help?  

I'm not sure I like my own wording yet, but ... I propose it as a 
straw man.

"""super returns the next parent class[1]

class A(object): pass

class B(A):
    def meth(self, arg):
        super(B, self).meth(arg)

class C(A): pass

class D(B, C): pass

d=D()
d.meth()

In this case, the super(B, self) call will actually return a 
reference to class C.  Class C is not a parent of class B, but it 
is the next parent for this particular instance d of class B.


[1] Actually, a super class mimicing the parent class.  

"""

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973579&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 17:37:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 17:37:32 2004
Subject: [ python-Bugs-995206 ] Deprecation Warning lies when it cannot
	parse your encoding
Message-ID: <E1BnJ9q-0006ML-00@sc8-sf-web3.sourceforge.net>

Bugs item #995206, was opened at 2004-07-21 14:48
Message generated for change (Comment added) made by lcreighton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation Warning lies when it cannot parse your encoding

Initial Comment:
The first line of my python file was:
# -*- coding: 'iso-8859-1' -*-

This is wrong, I need to drop the quotes.  But Python
2.3.4 (#2, Jun 19 2004, 18:15:30) is wrong, also, when it
complains:
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file test_stockdict.py on line 14, but no encoding
declared; see http://www.python.org/peps/pep-0263


----------------------------------------------------------------------

>Comment By: Laura Creighton (lcreighton)
Date: 2004-07-21 17:37

Message:
Logged In: YES 
user_id=376262

We'll see if this gets me what I want, a comment to
Marc-Andr?s comment.

That the parser, which cannot parse my encoding comment
ignores it and tries to continue work, may or may not be
admirable behaviour on the part of the parser.  I'd have
preferred a LookupError or a ValueError, or maybe a 
RuntimeWarning complaining that it couldn't make sense of my
encoding.

But when I get a Deprecation Warning, saying 'no encoding
declared' when there is one, and it's unusable, then that is
the wrong Warning to raise.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 15:20

Message:
Logged In: YES 
user_id=38388

I don't see why this should be wrong: if the parser cannot
parse the encoding comment, it simply ignores it and then
continues to work as if no encoding comment were given.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 17:44:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 18:02:33 2004
Subject: [ python-Bugs-995206 ] Deprecation Warning lies when it cannot
	parse your encoding
Message-ID: <E1BnJGR-0006be-00@sc8-sf-web3.sourceforge.net>

Bugs item #995206, was opened at 2004-07-21 14:48
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation Warning lies when it cannot parse your encoding

Initial Comment:
The first line of my python file was:
# -*- coding: 'iso-8859-1' -*-

This is wrong, I need to drop the quotes.  But Python
2.3.4 (#2, Jun 19 2004, 18:15:30) is wrong, also, when it
complains:
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file test_stockdict.py on line 14, but no encoding
declared; see http://www.python.org/peps/pep-0263


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 17:44

Message:
Logged In: YES 
user_id=38388

Laura, the problem is that the parser only checks for
encoding comments of a certain style. If it doesn't
find that particular style (defined in the PEP), then
is simply goes on with the processing as if there were
no encoding comment (because there isn't ;-).

Quotes are not allowed according to the PEP, so
using them will render the comment useless.

I don't see how the parser could give you a note in
the sense of "well, this may be an encoding comment,
but it is not what I expected, please check".

Of course, patches are welcome if they don't make
the implementation more complicated :-)


----------------------------------------------------------------------

Comment By: Laura Creighton (lcreighton)
Date: 2004-07-21 17:37

Message:
Logged In: YES 
user_id=376262

We'll see if this gets me what I want, a comment to
Marc-Andr?s comment.

That the parser, which cannot parse my encoding comment
ignores it and tries to continue work, may or may not be
admirable behaviour on the part of the parser.  I'd have
preferred a LookupError or a ValueError, or maybe a 
RuntimeWarning complaining that it couldn't make sense of my
encoding.

But when I get a Deprecation Warning, saying 'no encoding
declared' when there is one, and it's unusable, then that is
the wrong Warning to raise.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 15:20

Message:
Logged In: YES 
user_id=38388

I don't see why this should be wrong: if the parser cannot
parse the encoding comment, it simply ignores it and then
continues to work as if no encoding comment were given.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 18:02:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 18:02:34 2004
Subject: [ python-Bugs-995206 ] Deprecation Warning lies when it cannot
	parse your encoding
Message-ID: <E1BnJY3-0000RF-00@sc8-sf-web4.sourceforge.net>

Bugs item #995206, was opened at 2004-07-21 08:48
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation Warning lies when it cannot parse your encoding

Initial Comment:
The first line of my python file was:
# -*- coding: 'iso-8859-1' -*-

This is wrong, I need to drop the quotes.  But Python
2.3.4 (#2, Jun 19 2004, 18:15:30) is wrong, also, when it
complains:
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file test_stockdict.py on line 14, but no encoding
declared; see http://www.python.org/peps/pep-0263


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-21 12:02

Message:
Logged In: YES 
user_id=31435

Laura, you don't *have* an encoding directive here.  You 
thought you were writing one, but it's no more an encoding 
directive than, e.g.,

# I want this to be treated as some form of Finnish.

would have been.  Neither matches the syntax for an 
encoding directive, so both are treated as comments.

You want Python to guess that your line, which matches the 
syntax of a Python comment but not the syntax of an 
encoding directive (and so is treated as a comment), was 
*intended* to be an encoding directive.  That would be 
possible, but first needs a rigorous definition of 
what "intended to look like an encoding directive" means.  
Right now it's a binary "yes or no" decision, based on whether 
one of the first two lines matches (or not) the regexp given in 
the PEP.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 11:44

Message:
Logged In: YES 
user_id=38388

Laura, the problem is that the parser only checks for
encoding comments of a certain style. If it doesn't
find that particular style (defined in the PEP), then
is simply goes on with the processing as if there were
no encoding comment (because there isn't ;-).

Quotes are not allowed according to the PEP, so
using them will render the comment useless.

I don't see how the parser could give you a note in
the sense of "well, this may be an encoding comment,
but it is not what I expected, please check".

Of course, patches are welcome if they don't make
the implementation more complicated :-)


----------------------------------------------------------------------

Comment By: Laura Creighton (lcreighton)
Date: 2004-07-21 11:37

Message:
Logged In: YES 
user_id=376262

We'll see if this gets me what I want, a comment to
Marc-Andr?s comment.

That the parser, which cannot parse my encoding comment
ignores it and tries to continue work, may or may not be
admirable behaviour on the part of the parser.  I'd have
preferred a LookupError or a ValueError, or maybe a 
RuntimeWarning complaining that it couldn't make sense of my
encoding.

But when I get a Deprecation Warning, saying 'no encoding
declared' when there is one, and it's unusable, then that is
the wrong Warning to raise.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 09:20

Message:
Logged In: YES 
user_id=38388

I don't see why this should be wrong: if the parser cannot
parse the encoding comment, it simply ignores it and then
continues to work as if no encoding comment were given.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 18:50:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 18:50:41 2004
Subject: [ python-Bugs-995206 ] Deprecation Warning lies when it cannot
	parse your encoding
Message-ID: <E1BnKIc-0003tN-00@sc8-sf-web1.sourceforge.net>

Bugs item #995206, was opened at 2004-07-21 14:48
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation Warning lies when it cannot parse your encoding

Initial Comment:
The first line of my python file was:
# -*- coding: 'iso-8859-1' -*-

This is wrong, I need to drop the quotes.  But Python
2.3.4 (#2, Jun 19 2004, 18:15:30) is wrong, also, when it
complains:
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file test_stockdict.py on line 14, but no encoding
declared; see http://www.python.org/peps/pep-0263


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-07-21 18:50

Message:
Logged In: YES 
user_id=11105

It is even worse - pass the string contents of this file to
compile(), and you get a MemoryError.  See SF # 979739.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 18:02

Message:
Logged In: YES 
user_id=31435

Laura, you don't *have* an encoding directive here.  You 
thought you were writing one, but it's no more an encoding 
directive than, e.g.,

# I want this to be treated as some form of Finnish.

would have been.  Neither matches the syntax for an 
encoding directive, so both are treated as comments.

You want Python to guess that your line, which matches the 
syntax of a Python comment but not the syntax of an 
encoding directive (and so is treated as a comment), was 
*intended* to be an encoding directive.  That would be 
possible, but first needs a rigorous definition of 
what "intended to look like an encoding directive" means.  
Right now it's a binary "yes or no" decision, based on whether 
one of the first two lines matches (or not) the regexp given in 
the PEP.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 17:44

Message:
Logged In: YES 
user_id=38388

Laura, the problem is that the parser only checks for
encoding comments of a certain style. If it doesn't
find that particular style (defined in the PEP), then
is simply goes on with the processing as if there were
no encoding comment (because there isn't ;-).

Quotes are not allowed according to the PEP, so
using them will render the comment useless.

I don't see how the parser could give you a note in
the sense of "well, this may be an encoding comment,
but it is not what I expected, please check".

Of course, patches are welcome if they don't make
the implementation more complicated :-)


----------------------------------------------------------------------

Comment By: Laura Creighton (lcreighton)
Date: 2004-07-21 17:37

Message:
Logged In: YES 
user_id=376262

We'll see if this gets me what I want, a comment to
Marc-Andr?s comment.

That the parser, which cannot parse my encoding comment
ignores it and tries to continue work, may or may not be
admirable behaviour on the part of the parser.  I'd have
preferred a LookupError or a ValueError, or maybe a 
RuntimeWarning complaining that it couldn't make sense of my
encoding.

But when I get a Deprecation Warning, saying 'no encoding
declared' when there is one, and it's unusable, then that is
the wrong Warning to raise.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 15:20

Message:
Logged In: YES 
user_id=38388

I don't see why this should be wrong: if the parser cannot
parse the encoding comment, it simply ignores it and then
continues to work as if no encoding comment were given.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 18:53:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 18:54:14 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BnKLl-0000iz-00@sc8-sf-web3.sourceforge.net>

Bugs item #994255, was opened at 2004-07-20 00:36
Message generated for change (Comment added) made by thiagocorrea
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Correa (thiagocorrea)
Date: 2004-07-21 13:53

Message:
Logged In: YES 
user_id=111587

Again, I'm not compiling python sources, I'm using the
public C API.

The tradeoff isn't maintainability at all nor readability,
unless you want to imply that there is a python developer
who can't understand the concepts of function call/definition ;)
The question is how the above solution differ from the one
in the current source. And that's the warning level,
considering that it's the compiler job to optimize out the
function call.

There is nothing wrong in using /W4 once in a while, and
it's acctually a good idea.

I'm only asking to change 3 macros, not 27. Or at very
least, don't assume it has never been defined before, do a
#ifdef, so I can make my own improved version.

Perhaps I'm the first person concerned with a clean public API.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 00:05

Message:
Logged In: YES 
user_id=31435

There are at least 27 macros in core Python that use this 
standard C idiom, and you're the first person to raise an 
objection.  I recommend closing this as "Won't Fix" -- unless 
you have a much simpler suggestion than rewriting all these 
things.  More mounds of C preprocessor convolution would 
harm maintainability and readablity for everyone, and if that's 
the tradeoff, I'd rather you learn how to set an appropriate 
warning level when compiling Python sources.

BTW, Python uses /W3.  As the MS docs say, "[/W4] should 
be used only to provide 'lint' level warnings and is not 
recommended as your usual warning level setting".  We 
promise no warnings at /W3, but that's all.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 23:26

Message:
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 22:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 21:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 12:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 08:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 19:28:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 19:28:14 2004
Subject: [ python-Bugs-995206 ] Deprecation Warning lies when it cannot
	parse your encoding
Message-ID: <E1BnKsy-0005bc-00@sc8-sf-web2.sourceforge.net>

Bugs item #995206, was opened at 2004-07-21 14:48
Message generated for change (Comment added) made by lcreighton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deprecation Warning lies when it cannot parse your encoding

Initial Comment:
The first line of my python file was:
# -*- coding: 'iso-8859-1' -*-

This is wrong, I need to drop the quotes.  But Python
2.3.4 (#2, Jun 19 2004, 18:15:30) is wrong, also, when it
complains:
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file test_stockdict.py on line 14, but no encoding
declared; see http://www.python.org/peps/pep-0263


----------------------------------------------------------------------

>Comment By: Laura Creighton (lcreighton)
Date: 2004-07-21 19:28

Message:
Logged In: YES 
user_id=376262

Hi Tim.

yes, this is part of the reason why I was opposed to
encoding directives as comments.  But be that as it
may,
' Neither matches the syntax for an 
  encoding directive' is overstated.

I simply ised Swedish as text in a file,
and I got the deprecation warning.

So I went and read the PEP 263.

In particular I read:
'''
1. Allow non-ASCII in string literals and comments, by
internally
       treating a missing encoding declaration as a
declaration of
       "iso-8859-1". This will cause arbitrary byte strings to
       correctly round-trip between step 2 and step 5 of the
       processing, and provide compatibility with Python 2.2 for
       Unicode literals that contain non-ASCII bytes.
''''

Ok, fine.  I had no clue my encoding was "iso-8859-1"
so I put that in.

This is wrong, and I am not blaming the PEP for not removing
the quotes there.  I think the PEP here is fine.

But, given that I made an error, I would expect to fail
as a different part of the PEP promised me:

    To define a source code encoding, a magic comment must
    be placed into the source files either as first or second
    line in the file:    

          #!/usr/bin/python
          # -*- coding: <encoding name> -*-

    More precisely, the first or second line must match the
regular
    expression "coding[:=]\s*([\w-_.]+)". The first group of
this
    expression is then interpreted as encoding name. If the  
    encoding is unknown to Python, an error is raised during 
    compilation.

-----------

The encoding was unknown, but no error was raised.  no warning
either.  



----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-21 18:50

Message:
Logged In: YES 
user_id=11105

It is even worse - pass the string contents of this file to
compile(), and you get a MemoryError.  See SF # 979739.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 18:02

Message:
Logged In: YES 
user_id=31435

Laura, you don't *have* an encoding directive here.  You 
thought you were writing one, but it's no more an encoding 
directive than, e.g.,

# I want this to be treated as some form of Finnish.

would have been.  Neither matches the syntax for an 
encoding directive, so both are treated as comments.

You want Python to guess that your line, which matches the 
syntax of a Python comment but not the syntax of an 
encoding directive (and so is treated as a comment), was 
*intended* to be an encoding directive.  That would be 
possible, but first needs a rigorous definition of 
what "intended to look like an encoding directive" means.  
Right now it's a binary "yes or no" decision, based on whether 
one of the first two lines matches (or not) the regexp given in 
the PEP.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 17:44

Message:
Logged In: YES 
user_id=38388

Laura, the problem is that the parser only checks for
encoding comments of a certain style. If it doesn't
find that particular style (defined in the PEP), then
is simply goes on with the processing as if there were
no encoding comment (because there isn't ;-).

Quotes are not allowed according to the PEP, so
using them will render the comment useless.

I don't see how the parser could give you a note in
the sense of "well, this may be an encoding comment,
but it is not what I expected, please check".

Of course, patches are welcome if they don't make
the implementation more complicated :-)


----------------------------------------------------------------------

Comment By: Laura Creighton (lcreighton)
Date: 2004-07-21 17:37

Message:
Logged In: YES 
user_id=376262

We'll see if this gets me what I want, a comment to
Marc-Andr?s comment.

That the parser, which cannot parse my encoding comment
ignores it and tries to continue work, may or may not be
admirable behaviour on the part of the parser.  I'd have
preferred a LookupError or a ValueError, or maybe a 
RuntimeWarning complaining that it couldn't make sense of my
encoding.

But when I get a Deprecation Warning, saying 'no encoding
declared' when there is one, and it's unusable, then that is
the wrong Warning to raise.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 15:20

Message:
Logged In: YES 
user_id=38388

I don't see why this should be wrong: if the parser cannot
parse the encoding comment, it simply ignores it and then
continues to work as if no encoding comment were given.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 19:46:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 19:46:53 2004
Subject: [ python-Bugs-995206 ] Deprecation Warning lies when it cannot
	parse your encoding
Message-ID: <E1BnLB1-0002i0-00@sc8-sf-web3.sourceforge.net>

Bugs item #995206, was opened at 2004-07-21 14:48
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470

Category: None
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Laura Creighton (lcreighton)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: Deprecation Warning lies when it cannot parse your encoding

Initial Comment:
The first line of my python file was:
# -*- coding: 'iso-8859-1' -*-

This is wrong, I need to drop the quotes.  But Python
2.3.4 (#2, Jun 19 2004, 18:15:30) is wrong, also, when it
complains:
sys:1: DeprecationWarning: Non-ASCII character '\xf6'
in file test_stockdict.py on line 14, but no encoding
declared; see http://www.python.org/peps/pep-0263


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 19:46

Message:
Logged In: YES 
user_id=38388

Laura, this is a bug tracker, not a discussion forum.
The PEP is cristal clear on what works and what doesn't.
Quotes are definitely not part of the allowed character
set for encoding names.

I'm closing this as won't fix. 

If you like you can continue the discussion on python-dev.


----------------------------------------------------------------------

Comment By: Laura Creighton (lcreighton)
Date: 2004-07-21 19:28

Message:
Logged In: YES 
user_id=376262

Hi Tim.

yes, this is part of the reason why I was opposed to
encoding directives as comments.  But be that as it
may,
' Neither matches the syntax for an 
  encoding directive' is overstated.

I simply ised Swedish as text in a file,
and I got the deprecation warning.

So I went and read the PEP 263.

In particular I read:
'''
1. Allow non-ASCII in string literals and comments, by
internally
       treating a missing encoding declaration as a
declaration of
       "iso-8859-1". This will cause arbitrary byte strings to
       correctly round-trip between step 2 and step 5 of the
       processing, and provide compatibility with Python 2.2 for
       Unicode literals that contain non-ASCII bytes.
''''

Ok, fine.  I had no clue my encoding was "iso-8859-1"
so I put that in.

This is wrong, and I am not blaming the PEP for not removing
the quotes there.  I think the PEP here is fine.

But, given that I made an error, I would expect to fail
as a different part of the PEP promised me:

    To define a source code encoding, a magic comment must
    be placed into the source files either as first or second
    line in the file:    

          #!/usr/bin/python
          # -*- coding: <encoding name> -*-

    More precisely, the first or second line must match the
regular
    expression "coding[:=]\s*([\w-_.]+)". The first group of
this
    expression is then interpreted as encoding name. If the  
    encoding is unknown to Python, an error is raised during 
    compilation.

-----------

The encoding was unknown, but no error was raised.  no warning
either.  



----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-21 18:50

Message:
Logged In: YES 
user_id=11105

It is even worse - pass the string contents of this file to
compile(), and you get a MemoryError.  See SF # 979739.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 18:02

Message:
Logged In: YES 
user_id=31435

Laura, you don't *have* an encoding directive here.  You 
thought you were writing one, but it's no more an encoding 
directive than, e.g.,

# I want this to be treated as some form of Finnish.

would have been.  Neither matches the syntax for an 
encoding directive, so both are treated as comments.

You want Python to guess that your line, which matches the 
syntax of a Python comment but not the syntax of an 
encoding directive (and so is treated as a comment), was 
*intended* to be an encoding directive.  That would be 
possible, but first needs a rigorous definition of 
what "intended to look like an encoding directive" means.  
Right now it's a binary "yes or no" decision, based on whether 
one of the first two lines matches (or not) the regexp given in 
the PEP.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 17:44

Message:
Logged In: YES 
user_id=38388

Laura, the problem is that the parser only checks for
encoding comments of a certain style. If it doesn't
find that particular style (defined in the PEP), then
is simply goes on with the processing as if there were
no encoding comment (because there isn't ;-).

Quotes are not allowed according to the PEP, so
using them will render the comment useless.

I don't see how the parser could give you a note in
the sense of "well, this may be an encoding comment,
but it is not what I expected, please check".

Of course, patches are welcome if they don't make
the implementation more complicated :-)


----------------------------------------------------------------------

Comment By: Laura Creighton (lcreighton)
Date: 2004-07-21 17:37

Message:
Logged In: YES 
user_id=376262

We'll see if this gets me what I want, a comment to
Marc-Andr?s comment.

That the parser, which cannot parse my encoding comment
ignores it and tries to continue work, may or may not be
admirable behaviour on the part of the parser.  I'd have
preferred a LookupError or a ValueError, or maybe a 
RuntimeWarning complaining that it couldn't make sense of my
encoding.

But when I get a Deprecation Warning, saying 'no encoding
declared' when there is one, and it's unusable, then that is
the wrong Warning to raise.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-21 15:20

Message:
Logged In: YES 
user_id=38388

I don't see why this should be wrong: if the parser cannot
parse the encoding comment, it simply ignores it and then
continues to work as if no encoding comment were given.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995206&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 19:56:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 19:56:11 2004
Subject: [ python-Bugs-995422 ] title case bug
Message-ID: <E1BnLK3-0004cy-00@sc8-sf-web4.sourceforge.net>

Bugs item #995422, was opened at 2004-07-21 12:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995422&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kimo Johnson (mkimojohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: title case bug

Initial Comment:
>>> "I'll be seeing tom's friend".title()
"I'Ll Be Seeing Tom'S Friend"

I would expect:
"I'll Be Seeing Tom's Friend"


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995422&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 20:37:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 20:37:32 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BnLxl-0004lm-00@sc8-sf-web3.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 23:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:37

Message:
Logged In: YES 
user_id=31435

Python is written to the C89 standard, and has to compile 
under a great many C compilers besides the one you use.  
There's no way we're going to accept preprocessor tricks that 
end up turning these macros into actual function calls under 
compilers that don't support "inline" (which isn't part of C89), 
so that idea was dead on arrival.

If you want to submit a patch to stuff #ifndef around the 
macro definitions you care about, and supply your own 
compiler-specific versions of those, that would be fine by me.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-21 12:53

Message:
Logged In: YES 
user_id=111587

Again, I'm not compiling python sources, I'm using the
public C API.

The tradeoff isn't maintainability at all nor readability,
unless you want to imply that there is a python developer
who can't understand the concepts of function call/definition ;)
The question is how the above solution differ from the one
in the current source. And that's the warning level,
considering that it's the compiler job to optimize out the
function call.

There is nothing wrong in using /W4 once in a while, and
it's acctually a good idea.

I'm only asking to change 3 macros, not 27. Or at very
least, don't assume it has never been defined before, do a
#ifdef, so I can make my own improved version.

Perhaps I'm the first person concerned with a clean public API.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 23:05

Message:
Logged In: YES 
user_id=31435

There are at least 27 macros in core Python that use this 
standard C idiom, and you're the first person to raise an 
objection.  I recommend closing this as "Won't Fix" -- unless 
you have a much simpler suggestion than rewriting all these 
things.  More mounds of C preprocessor convolution would 
harm maintainability and readablity for everyone, and if that's 
the tradeoff, I'd rather you learn how to set an appropriate 
warning level when compiling Python sources.

BTW, Python uses /W3.  As the MS docs say, "[/W4] should 
be used only to provide 'lint' level warnings and is not 
recommended as your usual warning level setting".  We 
promise no warnings at /W3, but that's all.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 22:26

Message:
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 21:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 20:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 11:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 07:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 20:46:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 20:47:53 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BnM6z-000091-00@sc8-sf-web1.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 23:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:46

Message:
Logged In: YES 
user_id=31435

One other idea for these:  Py_INCREF expands to (at worst) a 
comma-expression under all Python build types, so e.g.,

#define Py_RETURN_NONE     return Py_INCREF(Py_None), Py_None

should (untested) work.  Comma expressions don't create 
problems with if/else structures.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:37

Message:
Logged In: YES 
user_id=31435

Python is written to the C89 standard, and has to compile 
under a great many C compilers besides the one you use.  
There's no way we're going to accept preprocessor tricks that 
end up turning these macros into actual function calls under 
compilers that don't support "inline" (which isn't part of C89), 
so that idea was dead on arrival.

If you want to submit a patch to stuff #ifndef around the 
macro definitions you care about, and supply your own 
compiler-specific versions of those, that would be fine by me.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-21 12:53

Message:
Logged In: YES 
user_id=111587

Again, I'm not compiling python sources, I'm using the
public C API.

The tradeoff isn't maintainability at all nor readability,
unless you want to imply that there is a python developer
who can't understand the concepts of function call/definition ;)
The question is how the above solution differ from the one
in the current source. And that's the warning level,
considering that it's the compiler job to optimize out the
function call.

There is nothing wrong in using /W4 once in a while, and
it's acctually a good idea.

I'm only asking to change 3 macros, not 27. Or at very
least, don't assume it has never been defined before, do a
#ifdef, so I can make my own improved version.

Perhaps I'm the first person concerned with a clean public API.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 23:05

Message:
Logged In: YES 
user_id=31435

There are at least 27 macros in core Python that use this 
standard C idiom, and you're the first person to raise an 
objection.  I recommend closing this as "Won't Fix" -- unless 
you have a much simpler suggestion than rewriting all these 
things.  More mounds of C preprocessor convolution would 
harm maintainability and readablity for everyone, and if that's 
the tradeoff, I'd rather you learn how to set an appropriate 
warning level when compiling Python sources.

BTW, Python uses /W3.  As the MS docs say, "[/W4] should 
be used only to provide 'lint' level warnings and is not 
recommended as your usual warning level setting".  We 
promise no warnings at /W3, but that's all.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 22:26

Message:
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 21:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 20:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 11:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 07:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 20:55:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 20:55:41 2004
Subject: [ python-Bugs-995458 ] Does not build selected SGI specific modules
Message-ID: <E1BnMFe-0000cA-00@sc8-sf-web2.sourceforge.net>

Bugs item #995458, was opened at 2004-07-21 13:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce D. Ray (brucedray)
Assigned to: Nobody/Anonymous (nobody)
Summary: Does not build selected SGI specific modules

Initial Comment:
System is SGI R10K running Irix 6.5.15
Compiler is MIPSpro 7.3

Default configuration build sequence works and installs
a python
2.3.4 that does not support GL, audio, etc. because the
SGI specific
modules for those are not built in the default
configuration.  To
quote the README:

     On SGI IRIX, there are modules that interface to
many SGI
     specific system libraries, e.g. the GL library and
the audio
     hardware.  These modules will not be built by the
setup.py
     script.

Therefore, after the default configuration build and
install, I
uncommented the lines in Modules/Setup that read:

     gl glmodule.c cgensupport.c -I$(srcdir) $(GLHACK)
-lgl -lX11
     fm fmmodule.c $(GLHACK) -lfm -lgl
     sgi sgimodule.c
     al almodule.c -laudio
     cd cdmodule.c -lcdaudio -lds -lmediad
     cl clmodule.c -lcl -lawareaudio
     fpectl fpectlmodule.c -lfpe
     fpetest fpetestmodule.c

I then did a  make clean   followed by   make

Errors returned were:

         cc   -o python                         Modules/python.o                         libpython2.3.a -ldl  -lpthread
-lmpc   -lm  
ld32: WARNING 84 : /usr/lib32/libdl.so is not used for
resolving any symbol.
ld32: WARNING 84 : /usr/lib32/mips4/libmpc.a is not
used for resolving any symbol.
ld32: ERROR   33 : Unresolved text symbol "initgl" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initfm" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initsgi" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "inital" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initcd" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initcl" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.
ld32: ERROR   33 : Unresolved text symbol "initfpectl"
-- 1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.   
ld32: ERROR   33 : Unresolved text symbol "initfpetest"
-- 1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.    
ld32: INFO    152: Output file removed because of error.
*** Error code 2 (bu21)


A previous message on the build said that I would have
to rerun
make   Therefore, I again did a  make clean   followed
by make
and got the error message:

     don't know how to make glmodule.c


How is this build to be done?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 21:11:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 21:11:18 2004
Subject: [ python-Feature Requests-992967 ] array.array objects should
	support sequences
Message-ID: <E1BnMUh-00010k-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #992967, was opened at 2004-07-17 13:30
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: array.array objects should support sequences

Initial Comment:
array objects from the array module have an extend method that 
only takes arrays.  The implementation would be more useful if it 
accepted arbitrary sequences (generators, lists, strings, etc).  
Similarly, the initializer currently only accepts lists and strings, 
but it should also support arbitrary sequences.

>>> from array import array
>>> array('c', iter('1234'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: array initializer must be list or string
>>> array('c').extend('1234')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can only extend array with array (not "str")

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-21 14:11

Message:
Logged In: YES 
user_id=80475

Guido, do you have an opinion on this?

If you want the constructor to accept general iterables,
that is not hard to do.

The question is whether the change is desirable.  On the
plus side, it better matches the list API.  On the minus
side, it allows array construction to invisibly slip into a
lower performance mode for both speed and space (with a list
style over allocation scheme).  I find that to be at odds
with the performance oriented use cases for the module. So,
I'm -0 on the feature request since general iterables can
already be handled explicitly with array.extend(it) or
array.array(code, list(it)).





----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-21 08:02

Message:
Logged In: YES 
user_id=6656

Interesting how intuitions differ :-)

It's just a call to PySequence_FAST, hardly an intrusive
patch (which didn't you use that for array_extend?).

The error message is wrong, btw: tuples are accepted too.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 07:21

Message:
Logged In: YES 
user_id=139309

One can construct an empty list and extend it too, but for some reason 
they let you make them out of arbitrary iterables.  I wonder why! :)

----------------------------------------------------------------------

Comment By: Michael Chermside (mcherm)
Date: 2004-07-21 07:13

Message:
Logged In: YES 
user_id=99874

I'll just chime in to agree with Raymond's analysis... the
constructor doesn't need to take general iterables. One can
always construct an empty array and extend it if that's
what's needed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-19 14:23

Message:
Logged In: YES 
user_id=80475

In Py2.4, I already made extend() take a general iterable. 
The goal was to simplify code doing repeated appends.

By calling array_extend, it should be easy to do the same
for the constructor.  The question is whether there are use
cases to warrant a further API change.  Most needs can
already be met with extend() or with array.array(code,
list(it)).  

My preference is to leave the constructor for cases with a
known sequence length.   With a single pre-allocation and
copy step, the performance is optimal.  I don't think it
would be obvious that using a general iterable would be much
slower and consume more memory than expected.  That's okay
for lists, but people use array when they are tight for
space or have other performance goals.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-19 10:56

Message:
Logged In: YES 
user_id=6656

I agree with your first point.  Should be easy, too.

I'm /slightly/ less enthusiastic about the latter point.  sequence-
>array conversion is sufficiently complex that I'm not sure I want 
it happening automatically.

This is the sort of report that a patch would help immensely, btw 
:-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 21:17:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 21:17:21 2004
Subject: [ python-Bugs-947906 ] calendar.weekheader(n): n should mean chars
	not bytes
Message-ID: <E1BnMaW-0007iu-00@sc8-sf-web4.sourceforge.net>

Bugs item #947906, was opened at 2004-05-04 20:38
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 7
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Nobody/Anonymous (nobody)
Summary: calendar.weekheader(n): n should mean chars not bytes

Initial Comment:
calendar.weekheader(n) is locale aware, which is good
in principle. The parameter n, however, is interpreted
as meaning bytes, not chars, which can generate broken
strings for, e.g. localized weekday names:

>>> calendar.weekheader(2)
'Mo Tu We Th Fr Sa Su'
>>> locale.setlocale(locale.LC_ALL, "pt_BR.UTF-8")
'pt_BR.UTF-8'
>>> calendar.weekheader(2)
'Se Te Qu Qu Se S\xc3 Do'

Notice how "S?bado" (Saturday) above is missing the
second utf-8 byte for the encoding of "?":

>>> u"S?".encode("utf-8")
'S\xc3\xa1'

The implementation of weekheader (and of all of
calendar.py, it seems) is based on localized 8 bit
strings. I suppose the correct fix for this bug will
involve a roundtrip thru unicode.


----------------------------------------------------------------------

>Comment By: Walter D?rwald (doerwalter)
Date: 2004-07-21 21:17

Message:
Logged In: YES 
user_id=89016

The following patch doesn't fix the unicode problem, but it 
should enable us to have both 8bit and unicode calendars. It 
reimplements the calendar functionality as classes. This 
makes it possible to reuse the date calculation logic and 
extend or replace the string formatting logic. Implementing a 
unicode version would be done by subclassing TextCalendar 
and overwritting formatweekday() and formatmonthname().

The patch adds several other features:

A HTML version of a calendar can be output. (An example 
output can be found at 
http://styx.livinglogic.de/~walter/calendar/calendar.html).

The calendar module can be used as a script from the 
command line. Various options are available.

It's possible to specify the number of months per row (they 
were fixed at 3 in the old version).

If this patch is accepted I can provide documentation and 
tests.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-06-03 06:43

Message:
Logged In: YES 
user_id=21627

Adding an ucalendar module would be reasonable, IMO.
Introducing ustrftime is not necessary - we could just apply
the "unicode in/unicode out" procedure (i.e. if the format
is a Unicode string, return a Unicode result). The tricky
part of that is to convert the strftime result to Unicode.
We could try mbstowcs, but that would fail if the locale
doesn't use Unicode for wchar_t.

Once ucalendar is written, we could document that the
calendar module has known problems if the locale's encoding
is not Latin-1.

However, I'm not going to implement that any time soon, so
unassigning.

----------------------------------------------------------------------

Comment By: Walter D?rwald (doerwalter)
Date: 2004-06-02 21:08

Message:
Logged In: YES 
user_id=89016

Maybe we should have a second version of calendar (named 
ucalendar?) that works with unicode strings? Could those two 
modules be rewritten to use as much common functionality as 
possible? Or we could use a module global to configure 
whether str or unicode should be returned?

Most of the localization functionality in calendar seems to 
come from datetime.datetime.strftime(), so it probably would 
help to have a method datetime.datetime.ustrftime() that 
returns the formatted string as unicode (using the locale 
encoding).

Assigning to MvL as the locale/unicode expert.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-05-08 01:57

Message:
Logged In: YES 
user_id=55188

I think calendar.weekheader should mean not chars nor bytes
but width.
Because the function is currectly used for fixed width
representations
of calendars.
Yes. They are same for western alphabets. But, for many of CJK
characters are in full width. So, they need only 1 character for
calendar.weekheader(2); and it's conventional in real life, too.

But, we don't have unicode.width() support to implement the
feature yet.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=947906&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 21:23:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 21:23:39 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BnMgf-0001TS-00@sc8-sf-web1.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 22:36
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-21 14:23

Message:
Logged In: YES 
user_id=80475

Nick Bastin encountered this same issue with the SunPro C
compiler.  The solution was to add a compiler specific
pragma to pyport.h.  I recommend that you submit a similar
patch.  Assign it to me and I'll apply it for you.

Altering the macro itself is probably the wrong way to go. 
Python has no shortage of while statements with constant
conditions.  They are everywhere and IMO are a valid idiom.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 13:46

Message:
Logged In: YES 
user_id=31435

One other idea for these:  Py_INCREF expands to (at worst) a 
comma-expression under all Python build types, so e.g.,

#define Py_RETURN_NONE     return Py_INCREF(Py_None), Py_None

should (untested) work.  Comma expressions don't create 
problems with if/else structures.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 13:37

Message:
Logged In: YES 
user_id=31435

Python is written to the C89 standard, and has to compile 
under a great many C compilers besides the one you use.  
There's no way we're going to accept preprocessor tricks that 
end up turning these macros into actual function calls under 
compilers that don't support "inline" (which isn't part of C89), 
so that idea was dead on arrival.

If you want to submit a patch to stuff #ifndef around the 
macro definitions you care about, and supply your own 
compiler-specific versions of those, that would be fine by me.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-21 11:53

Message:
Logged In: YES 
user_id=111587

Again, I'm not compiling python sources, I'm using the
public C API.

The tradeoff isn't maintainability at all nor readability,
unless you want to imply that there is a python developer
who can't understand the concepts of function call/definition ;)
The question is how the above solution differ from the one
in the current source. And that's the warning level,
considering that it's the compiler job to optimize out the
function call.

There is nothing wrong in using /W4 once in a while, and
it's acctually a good idea.

I'm only asking to change 3 macros, not 27. Or at very
least, don't assume it has never been defined before, do a
#ifdef, so I can make my own improved version.

Perhaps I'm the first person concerned with a clean public API.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 22:05

Message:
Logged In: YES 
user_id=31435

There are at least 27 macros in core Python that use this 
standard C idiom, and you're the first person to raise an 
objection.  I recommend closing this as "Won't Fix" -- unless 
you have a much simpler suggestion than rewriting all these 
things.  More mounds of C preprocessor convolution would 
harm maintainability and readablity for everyone, and if that's 
the tradeoff, I'd rather you learn how to set an appropriate 
warning level when compiling Python sources.

BTW, Python uses /W3.  As the MS docs say, "[/W4] should 
be used only to provide 'lint' level warnings and is not 
recommended as your usual warning level setting".  We 
promise no warnings at /W3, but that's all.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 21:26

Message:
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 20:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 19:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 10:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 06:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 21:24:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 21:24:43 2004
Subject: [ python-Bugs-993601 ] optparse libref documentation missing "ref"
Message-ID: <E1BnMhg-0001VW-00@sc8-sf-web1.sourceforge.net>

Bugs item #993601, was opened at 2004-07-19 01:30
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
>Assigned to: Greg Ward (gward)
Summary: optparse libref documentation missing "ref"

Initial Comment:
The optparse libref documentation, while extensive, 
doesn't actually include an API reference. There's no way 
of knowing the valid parameter set of 
OptionParser.add_option() without going through the 
source. 
 
Please consider adding an API reference page for each of 
OptionParser (including OptionContainer), Values, Option 
(aka make_option) and OptionGroup. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 21:39:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 21:40:01 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BnMwG-0007Kv-00@sc8-sf-web3.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 23:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Correa (thiagocorrea)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-21 15:39

Message:
Logged In: YES 
user_id=31435

Which problem did Nick have?  Many of the "do {} while(0)" 
macros in Python are internal to C files, so aren't visible to 
people merely using the public API (as opposed to compiling 
Python itself).  The three thiagocorrea complains about are 
part of the public API.  I think it's easy to predict that he 
won't want to disable the "constant expression" message in 
pyport.h, because then it would be disabled too in all *his* 
code that merely includes Python.h in order to use the Python 
C API.

I certainly don't mind switching to a different C89 idiom where 
one is available.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-21 15:23

Message:
Logged In: YES 
user_id=80475

Nick Bastin encountered this same issue with the SunPro C
compiler.  The solution was to add a compiler specific
pragma to pyport.h.  I recommend that you submit a similar
patch.  Assign it to me and I'll apply it for you.

Altering the macro itself is probably the wrong way to go. 
Python has no shortage of while statements with constant
conditions.  They are everywhere and IMO are a valid idiom.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:46

Message:
Logged In: YES 
user_id=31435

One other idea for these:  Py_INCREF expands to (at worst) a 
comma-expression under all Python build types, so e.g.,

#define Py_RETURN_NONE     return Py_INCREF(Py_None), Py_None

should (untested) work.  Comma expressions don't create 
problems with if/else structures.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:37

Message:
Logged In: YES 
user_id=31435

Python is written to the C89 standard, and has to compile 
under a great many C compilers besides the one you use.  
There's no way we're going to accept preprocessor tricks that 
end up turning these macros into actual function calls under 
compilers that don't support "inline" (which isn't part of C89), 
so that idea was dead on arrival.

If you want to submit a patch to stuff #ifndef around the 
macro definitions you care about, and supply your own 
compiler-specific versions of those, that would be fine by me.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-21 12:53

Message:
Logged In: YES 
user_id=111587

Again, I'm not compiling python sources, I'm using the
public C API.

The tradeoff isn't maintainability at all nor readability,
unless you want to imply that there is a python developer
who can't understand the concepts of function call/definition ;)
The question is how the above solution differ from the one
in the current source. And that's the warning level,
considering that it's the compiler job to optimize out the
function call.

There is nothing wrong in using /W4 once in a while, and
it's acctually a good idea.

I'm only asking to change 3 macros, not 27. Or at very
least, don't assume it has never been defined before, do a
#ifdef, so I can make my own improved version.

Perhaps I'm the first person concerned with a clean public API.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 23:05

Message:
Logged In: YES 
user_id=31435

There are at least 27 macros in core Python that use this 
standard C idiom, and you're the first person to raise an 
objection.  I recommend closing this as "Won't Fix" -- unless 
you have a much simpler suggestion than rewriting all these 
things.  More mounds of C preprocessor convolution would 
harm maintainability and readablity for everyone, and if that's 
the tradeoff, I'd rather you learn how to set an appropriate 
warning level when compiling Python sources.

BTW, Python uses /W3.  As the MS docs say, "[/W4] should 
be used only to provide 'lint' level warnings and is not 
recommended as your usual warning level setting".  We 
promise no warnings at /W3, but that's all.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 22:26

Message:
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 21:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 20:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 11:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 07:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 22:52:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 22:52:08 2004
Subject: [ python-Bugs-995522 ] PEP 263 regular expression fails
Message-ID: <E1BnO4K-0001hF-00@sc8-sf-web3.sourceforge.net>

Bugs item #995522, was opened at 2004-07-21 22:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995522&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 263 regular expression fails

Initial Comment:
Bug 995206 triggered me in trying the regular
expression given in PEP 263 for the encoding syntax. 
This is the result (on Linux, with a failry up-to-date
Python):

Python 2.4a1+ (#1, Jul 19 2004, 08:51:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.compile(r"coding[:=]\s*([\w-_.]+)")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/sjoerd/src/python/Lib/sre.py", line 179,
in compile
    return _compile(pattern, flags)
  File "/home/sjoerd/src/python/Lib/sre.py", line 230,
in _compile
    raise error, v # invalid expression
sre_constants.error: bad character range
>>>

It seems to me that the PEP's regular expression should
be fixed (or re has a bug).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995522&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 23:22:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 23:22:09 2004
Subject: [ python-Bugs-995522 ] PEP 263 regular expression fails
Message-ID: <E1BnOXM-0003pc-00@sc8-sf-web4.sourceforge.net>

Bugs item #995522, was opened at 2004-07-21 16:52
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995522&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP 263 regular expression fails

Initial Comment:
Bug 995206 triggered me in trying the regular
expression given in PEP 263 for the encoding syntax. 
This is the result (on Linux, with a failry up-to-date
Python):

Python 2.4a1+ (#1, Jul 19 2004, 08:51:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.compile(r"coding[:=]\s*([\w-_.]+)")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/sjoerd/src/python/Lib/sre.py", line 179,
in compile
    return _compile(pattern, flags)
  File "/home/sjoerd/src/python/Lib/sre.py", line 230,
in _compile
    raise error, v # invalid expression
sre_constants.error: bad character range
>>>

It seems to me that the PEP's regular expression should
be fixed (or re has a bug).


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-21 17:22

Message:
Logged In: YES 
user_id=11375

Swap the \w and - in the second range, giving [-\w_.].  I'll
fix the PEP.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995522&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 23:23:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 23:23:34 2004
Subject: [ python-Bugs-995522 ] PEP 263 regular expression fails
Message-ID: <E1BnOYk-0005yz-00@sc8-sf-web2.sourceforge.net>

Bugs item #995522, was opened at 2004-07-21 16:52
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995522&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
>Assigned to: A.M. Kuchling (akuchling)
Summary: PEP 263 regular expression fails

Initial Comment:
Bug 995206 triggered me in trying the regular
expression given in PEP 263 for the encoding syntax. 
This is the result (on Linux, with a failry up-to-date
Python):

Python 2.4a1+ (#1, Jul 19 2004, 08:51:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.compile(r"coding[:=]\s*([\w-_.]+)")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/sjoerd/src/python/Lib/sre.py", line 179,
in compile
    return _compile(pattern, flags)
  File "/home/sjoerd/src/python/Lib/sre.py", line 230,
in _compile
    raise error, v # invalid expression
sre_constants.error: bad character range
>>>

It seems to me that the PEP's regular expression should
be fixed (or re has a bug).


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-21 17:23

Message:
Logged In: YES 
user_id=11375

Fix committed; closing.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-21 17:22

Message:
Logged In: YES 
user_id=11375

Swap the \w and - in the second range, giving [-\w_.].  I'll
fix the PEP.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995522&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 23:25:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 23:25:55 2004
Subject: [ python-Bugs-995109 ] logging.handlers.RotatingFileHandler missing
	error handling
Message-ID: <E1BnOaw-0006BI-00@sc8-sf-web1.sourceforge.net>

Bugs item #995109, was opened at 2004-07-21 05:40
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995109&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging.handlers.RotatingFileHandler missing error handling

Initial Comment:
If i open('logfile','r') in one shell and in my program
use a RotatingFileHandler using the same 'logfile', then 

os.rename(self.baseFilename, dfn) # line 86 in handlers.py

will fail and no log open, thus subsequent logging
attempts will  trigger a ValueError and render the
application in an unusable state.
(File "C:\Python23\lib\logging\handlers.py", line 103,
in emit
    self.stream.seek(0, 2)  #due to non-posix-compliant
Windows feature
ValueError: I/O operation on closed file)

I would have created a patch, but I am unsure of what
the correct behaviour should be?

- one possibility would be to continue logging to the
same file (skip rollover), but that is not ideal behaviour

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995109&group_id=5470
From noreply at sourceforge.net  Wed Jul 21 23:36:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 21 23:36:08 2004
Subject: [ python-Bugs-990524 ] online documentation says "Nac" in the link,
	"Nav" for mod
Message-ID: <E1BnOks-0006N9-00@sc8-sf-web2.sourceforge.net>

Bugs item #990524, was opened at 2004-07-13 18:18
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990524&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
>Assigned to: A.M. Kuchling (akuchling)
Summary: online documentation says "Nac" in the link, "Nav" for mod

Initial Comment:
For the following webpage:
http://www.python.org/doc/2.3.4/modindex.html
the link for the module says "Nac (Mac)", but on the 
linked page:
http://www.python.org/doc/2.3.4/mac/module-Nac.html
The module name is listed as "Nav".

One of these names must be wrong.  I haven't checked 
to see what the correct module name is.



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-21 17:36

Message:
Logged In: YES 
user_id=11375

It's a typo; 'Nav' is correct.  Fixed in 2.4 and 2.3 in CVS.
 Thanks for pointing this out.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990524&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 03:06:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 03:06:57 2004
Subject: [ python-Bugs-990325 ] testtar.tar is partially insane
Message-ID: <E1BnS2q-0008QJ-00@sc8-sf-web3.sourceforge.net>

Bugs item #990325, was opened at 2004-07-13 14:00
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990325&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: testtar.tar is partially insane

Initial Comment:
The test file testtar.tar is a binary file, but contains 
(seemingly by accident) CVS keywords, like $Date$ and 
$Revision$.  As a result, if Python is checked out with -
kk (don't expand keywords), test_tarfile fails.  I'm not 
clear on exactly why.

Binary files shouldn't have CVS keywords inside them, 
and tests shouldn't care whether keywords are 
expanded anyway.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-21 21:06

Message:
Logged In: YES 
user_id=31435

Patch 995225 has been checked in, so closing as Fixed.  
FWIW, I blame CVS too.

----------------------------------------------------------------------

Comment By: Lars Gust?bel (gustaebel)
Date: 2004-07-21 09:52

Message:
Logged In: YES 
user_id=642936

When I created testtar.tar I used a copy of pep-0000.txt as
dummy data, and that has CVS keywords in it. The problem is,
that -kk substitutes the keywords, although testtar.tar was
checked in with -kb. I blame CVS's rotten handling of binary
files for that one.

I opened a patch #995225 with a new testtar.tar that has no
keywords.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990325&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 03:49:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 03:49:28 2004
Subject: [ python-Bugs-994255 ] Py_RETURN_NONE causes too much warnings
Message-ID: <E1BnSi0-00026R-00@sc8-sf-web4.sourceforge.net>

Bugs item #994255, was opened at 2004-07-19 23:36
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Correa (thiagocorrea)
>Assigned to: Tim Peters (tim_one)
Summary: Py_RETURN_NONE causes too much warnings

Initial Comment:
It will make the compiler complain on each instance
about the conditional being constant ( while (0) )

why not use something like this instead?

The compiler will be able to optimize out the function
call.

#if !defined(Py_RETURN_NONE) // New in Python 2.4
inline PyObject* doPy_RETURN_NONE()
{	Py_INCREF(Py_None); return Py_None; }
#define Py_RETURN_NONE return doPy_RETURN_NONE()
#endif

#if !defined(Py_RETURN_TRUE) // New in Python 2.4
inline PyObject* doPy_RETURN_TRUE()
{Py_INCREF(Py_True); return Py_True;}
#	define Py_RETURN_TRUE return doPy_RETURN_TRUE()
#endif

#if !defined(Py_RETURN_FALSE) // New in Python 2.4
inline PyObject* doPy_RETURN_FALSE()
{Py_INCREF(Py_False); return Py_False;}
#define Py_RETURN_FALSE return doPy_RETURN_FALSE()
#endif


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-21 21:49

Message:
Logged In: YES 
user_id=31435

Rewrote Py_RETURN_{NONE, TRUE, FALSE} to expand to 
comma expressions:

Include/boolobject.h; new revision: 1.8
Include/object.h; new revision: 2.128

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 15:39

Message:
Logged In: YES 
user_id=31435

Which problem did Nick have?  Many of the "do {} while(0)" 
macros in Python are internal to C files, so aren't visible to 
people merely using the public API (as opposed to compiling 
Python itself).  The three thiagocorrea complains about are 
part of the public API.  I think it's easy to predict that he 
won't want to disable the "constant expression" message in 
pyport.h, because then it would be disabled too in all *his* 
code that merely includes Python.h in order to use the Python 
C API.

I certainly don't mind switching to a different C89 idiom where 
one is available.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-21 15:23

Message:
Logged In: YES 
user_id=80475

Nick Bastin encountered this same issue with the SunPro C
compiler.  The solution was to add a compiler specific
pragma to pyport.h.  I recommend that you submit a similar
patch.  Assign it to me and I'll apply it for you.

Altering the macro itself is probably the wrong way to go. 
Python has no shortage of while statements with constant
conditions.  They are everywhere and IMO are a valid idiom.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:46

Message:
Logged In: YES 
user_id=31435

One other idea for these:  Py_INCREF expands to (at worst) a 
comma-expression under all Python build types, so e.g.,

#define Py_RETURN_NONE     return Py_INCREF(Py_None), Py_None

should (untested) work.  Comma expressions don't create 
problems with if/else structures.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-21 14:37

Message:
Logged In: YES 
user_id=31435

Python is written to the C89 standard, and has to compile 
under a great many C compilers besides the one you use.  
There's no way we're going to accept preprocessor tricks that 
end up turning these macros into actual function calls under 
compilers that don't support "inline" (which isn't part of C89), 
so that idea was dead on arrival.

If you want to submit a patch to stuff #ifndef around the 
macro definitions you care about, and supply your own 
compiler-specific versions of those, that would be fine by me.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-21 12:53

Message:
Logged In: YES 
user_id=111587

Again, I'm not compiling python sources, I'm using the
public C API.

The tradeoff isn't maintainability at all nor readability,
unless you want to imply that there is a python developer
who can't understand the concepts of function call/definition ;)
The question is how the above solution differ from the one
in the current source. And that's the warning level,
considering that it's the compiler job to optimize out the
function call.

There is nothing wrong in using /W4 once in a while, and
it's acctually a good idea.

I'm only asking to change 3 macros, not 27. Or at very
least, don't assume it has never been defined before, do a
#ifdef, so I can make my own improved version.

Perhaps I'm the first person concerned with a clean public API.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 23:05

Message:
Logged In: YES 
user_id=31435

There are at least 27 macros in core Python that use this 
standard C idiom, and you're the first person to raise an 
objection.  I recommend closing this as "Won't Fix" -- unless 
you have a much simpler suggestion than rewriting all these 
things.  More mounds of C preprocessor convolution would 
harm maintainability and readablity for everyone, and if that's 
the tradeoff, I'd rather you learn how to set an appropriate 
warning level when compiling Python sources.

BTW, Python uses /W3.  As the MS docs say, "[/W4] should 
be used only to provide 'lint' level warnings and is not 
recommended as your usual warning level setting".  We 
promise no warnings at /W3, but that's all.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 22:26

Message:
Logged In: YES 
user_id=111587

I'm not building Python.
I use python embedded on my project ( sf.net/projects/wpdev
) for scripting.

I often build using Level 4 warning (/W4) setting, usefull
for finding bugs. Also, it's built using C++ compiler not C.

Well, I don't know much about C standards but I do know a
lot about C++, and for C++ inline is just a hint to the
compiler, it might very well completely ignore it or ( it
usually does ) inline functions that were not marked as
"inline". If that's the problem, then drop the "inline"...
or have a macro to detect that inline is supported by the
compiler.
#ifdef __cplusplus
#define INLINE inline
#else
#define INLINE
#endif

Other checks could be added as well to enable it on C99
compliant compilers.
The point here is that the compiler is right complainning
about the constant conditional there.
I know that a simple {} block doesn't work well, but a
function call will, and the call itself will also be
optimized out by the compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-20 21:26

Message:
Logged In: YES 
user_id=31435

"do {...} while(0)" is the standard C idiom for writing a multi-
statement macro; the reason "{...}" doesn't work is 
explained, e.g., here:

http://www.eskimo.com/~scs/C-faq/q10.4.html

thiagocorrea, we need more words from you.  Python is built 
every day using MSVC 6.0, and Visual Studio 7.1, with no 
warnings of any kind.  Indeed, "no warnings under MSVC" is a 
groundrule for the Python project.  Exactly how do you 
compile it?  Do you use the Visual Studio project files in the 
PCBuild subdirectory?

Brett is correct that we cannot use "inline" either.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-20 20:40

Message:
Logged In: YES 
user_id=357491

You can't use inline; that is not supported in C89 but only C99 which we 
do not support.

As for why we can't just make the macro ``{Py_INCREF(Py_None); 
return Py_None;}``, I don't know.  K&R seems to suggest that the syntax 
is at least legal.

----------------------------------------------------------------------

Comment By: Correa (thiagocorrea)
Date: 2004-07-20 11:27

Message:
Logged In: YES 
user_id=111587

Visual C++ 7.0, Win32



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-20 07:27

Message:
Logged In: YES 
user_id=80475

Which compiler and operating system are you using?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994255&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 09:22:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 09:22:30 2004
Subject: [ python-Bugs-995422 ] title case bug
Message-ID: <E1BnXuF-0001sk-00@sc8-sf-web3.sourceforge.net>

Bugs item #995422, was opened at 2004-07-21 20:56
Message generated for change (Comment added) made by tbmetin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995422&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kimo Johnson (mkimojohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: title case bug

Initial Comment:
>>> "I'll be seeing tom's friend".title()
"I'Ll Be Seeing Tom'S Friend"

I would expect:
"I'll Be Seeing Tom's Friend"


----------------------------------------------------------------------

Comment By: Baris Metin (tbmetin)
Date: 2004-07-22 10:22

Message:
Logged In: YES 
user_id=1045504

We have, the same kind of problem with non-asci characters. 
I've offered a solution in patch #995740 (fix for title case bug: 
#995422). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995422&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 10:26:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 10:26:15 2004
Subject: [ python-Bugs-888594 ] cPickle doesn't like protocol keyword
	argument, pickle does
Message-ID: <E1BnYu1-0008Fv-00@sc8-sf-web1.sourceforge.net>

Bugs item #888594, was opened at 2004-02-01 16:29
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=888594&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't like protocol keyword argument, pickle does

Initial Comment:
The dump and dumps functions from the "cPickle" module
don't accept the protocol keyword argument. The
"pickle" module does. This is an irritating API
difference that requires me to write different code to
deal with either cPickle or pickle (if cPickle is not
available).

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-07-22 08:26

Message:
Logged In: YES 
user_id=908995

Patch #995766 should take care of this

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=888594&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 13:18:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 13:18:51 2004
Subject: [ python-Bugs-995109 ] logging.handlers.RotatingFileHandler missing
	error handling
Message-ID: <E1Bnbb3-0006Em-00@sc8-sf-web1.sourceforge.net>

Bugs item #995109, was opened at 2004-07-21 09:40
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995109&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.handlers.RotatingFileHandler missing error handling

Initial Comment:
If i open('logfile','r') in one shell and in my program
use a RotatingFileHandler using the same 'logfile', then 

os.rename(self.baseFilename, dfn) # line 86 in handlers.py

will fail and no log open, thus subsequent logging
attempts will  trigger a ValueError and render the
application in an unusable state.
(File "C:\Python23\lib\logging\handlers.py", line 103,
in emit
    self.stream.seek(0, 2)  #due to non-posix-compliant
Windows feature
ValueError: I/O operation on closed file)

I would have created a patch, but I am unsure of what
the correct behaviour should be?

- one possibility would be to continue logging to the
same file (skip rollover), but that is not ideal behaviour

----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2004-07-22 11:18

Message:
Logged In: YES 
user_id=308438

Unfortunately, there is no ideal behaviour. There is a "fix" for 
this problem in CVS - the handler calls handleError() if an 
exception is raised during emitting. If raiseExceptions is true, 
the exception is propagated up. If not, the exception is 
swallowed silently. There is no one universally agreed way of 
dealing with something like this - the best approach is for the 
application developer to provide custom handling via an 
overridden handleError() method in a derived handler class.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995109&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 15:16:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 15:16:54 2004
Subject: [ python-Bugs-995907 ] memory leak with theads and enhancement of
	the timer class
Message-ID: <E1BndRM-0002GT-00@sc8-sf-web1.sourceforge.net>

Bugs item #995907, was opened at 2004-07-22 15:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995907&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Haar (thaar)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak with theads and enhancement of the timer class

Initial Comment:
If i use the Timer cyclically the  memory becomes
always less.


I found following problems::

1.) The thread is not clean deleted.=>
file:threading.py  class: Thread methode:__delete

del _active[_get_ident()] only delete the thead from
the list, not the thead self.  I think the call of the
destructor of the c++ based library need a explicit del.

The problem will be fixed with following lines:

    def __delete(self):
        _active_limbo_lock.acquire()
        t=_active[_get_ident()]
        del _active[_get_ident()]
        del t
        _active_limbo_lock.release()

2.) A cyclic timer is a needed feature and it should
not use a new thread every time.

So i made following enhancement (parameter cyclic) in the 
file:threading.py  class: _Timer  

class _Timer(Thread):
    """Call a function after a specified number of seconds:

    t = Timer(30.0, f, args=[], kwargs={})
    t.start()
    t.cancel() # stop the timer's action if it's still
waiting
    """

    def __init__(self, interval, function, cyclic=0,
args=[], kwargs={}):
        Thread.__init__(self)
        self.interval = interval
        self.function = function
        self.args = args
        self.kwargs = kwargs
        self.finished = Event()
        self.cyclic= Event()
        if cyclic:
            self.cyclic.set()

    def cancel(self):
        """Stop the timer if it hasn't finished yet"""
        self.cyclic.clear()
        self.finished.set()

    def run(self):
        flag =1
        while flag:
            self.finished.wait(self.interval)
            if not self.finished.isSet():
                self.function(*self.args, **self.kwargs)
            if not self.cyclic.isSet():
                self.finished.set()
                flag = 0         





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995907&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 15:28:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 15:28:43 2004
Subject: [ python-Bugs-995907 ] memory leak with theads and enhancement of
	the timer class
Message-ID: <E1Bndcl-0002ni-00@sc8-sf-web1.sourceforge.net>

Bugs item #995907, was opened at 2004-07-22 15:16
Message generated for change (Settings changed) made by thaar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995907&group_id=5470

Category: Threads
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Haar (thaar)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak with theads and enhancement of the timer class

Initial Comment:
If i use the Timer cyclically the  memory becomes
always less.


I found following problems::

1.) The thread is not clean deleted.=>
file:threading.py  class: Thread methode:__delete

del _active[_get_ident()] only delete the thead from
the list, not the thead self.  I think the call of the
destructor of the c++ based library need a explicit del.

The problem will be fixed with following lines:

    def __delete(self):
        _active_limbo_lock.acquire()
        t=_active[_get_ident()]
        del _active[_get_ident()]
        del t
        _active_limbo_lock.release()

2.) A cyclic timer is a needed feature and it should
not use a new thread every time.

So i made following enhancement (parameter cyclic) in the 
file:threading.py  class: _Timer  

class _Timer(Thread):
    """Call a function after a specified number of seconds:

    t = Timer(30.0, f, args=[], kwargs={})
    t.start()
    t.cancel() # stop the timer's action if it's still
waiting
    """

    def __init__(self, interval, function, cyclic=0,
args=[], kwargs={}):
        Thread.__init__(self)
        self.interval = interval
        self.function = function
        self.args = args
        self.kwargs = kwargs
        self.finished = Event()
        self.cyclic= Event()
        if cyclic:
            self.cyclic.set()

    def cancel(self):
        """Stop the timer if it hasn't finished yet"""
        self.cyclic.clear()
        self.finished.set()

    def run(self):
        flag =1
        while flag:
            self.finished.wait(self.interval)
            if not self.finished.isSet():
                self.function(*self.args, **self.kwargs)
            if not self.cyclic.isSet():
                self.finished.set()
                flag = 0         





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995907&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 15:48:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 15:48:59 2004
Subject: [ python-Bugs-995925 ] method after() and afer_idle() are not thead
	save
Message-ID: <E1BndwM-0002vh-00@sc8-sf-web2.sourceforge.net>

Bugs item #995925, was opened at 2004-07-22 15:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995925&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Haar (thaar)
Assigned to: Martin v. L?wis (loewis)
Summary: method after() and afer_idle() are not thead save

Initial Comment:
The methods afer() and after_idle() register the
callback function in the list self._tclCommands. This
List is member of the Misc class in the file tkinter.py
and is not protected by a lock. 
So it could be that the thread  access the list by
calling the function after() and to the same time the
tkinter mainloop access the list  by the methode
deletecommand() in the callback function.  The same
problem will occur if the function after() is called by
two theads.

solution: 
Create a lock object and save the list 
self._tclCommands in the methods :

misc.destroy()
misc.deletecommand()
misc._register()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995925&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 16:15:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 16:15:22 2004
Subject: [ python-Bugs-980352 ] coercion results used dangerously
Message-ID: <E1BneLt-0000Qr-00@sc8-sf-web4.sourceforge.net>

Bugs item #980352, was opened at 2004-06-26 17:26
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980352&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: coercion results used dangerously

Initial Comment:
The C core uses the result of PyNumber_CoerceEx() dangerously: it gets passed to tp_compare, and most tp_compare slots assume they get two objects of the same type.  This assumption is never checked, even when a user-defined __coerce__() is called:

>>> class X(object):
...   def __coerce__(self, other):
...     return 4, other
...
>>> slice(1,2,3) == X()
Segmentation fault


----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-07-22 14:15

Message:
Logged In: YES 
user_id=908995

I just filed patch #995939 which should address this. A review would be 
appreciated.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-26 22:42

Message:
Logged In: YES 
user_id=80475

I looked back at one of my ASPN recipes,
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/265894
, and saw that the use of __coerce__ dramatically simplified
the code.  

Also, the API for rich comparisons is not only complex, but
it is not entirely sef-consistent.  See Tim's "mini-bug"
comment in sets.py for an example.

IOW, I think it is premature to pull the plug.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2004-06-26 19:21

Message:
Logged In: YES 
user_id=35752

This bug should obviously get fixed but in long term I think
__coerce__ should go away.  Do you think deprecating it for
2.4 and then removing support for it in 2.5 or 2.6 is feasible?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980352&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 16:18:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 16:18:07 2004
Subject: [ python-Bugs-992017 ] code that generates a segfault on Python
	2.1-2.3
Message-ID: <E1BneOa-0000Z2-00@sc8-sf-web4.sourceforge.net>

Bugs item #992017, was opened at 2004-07-15 23:56
Message generated for change (Comment added) made by ddorfman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ted Bach (bachtor)
Assigned to: Nobody/Anonymous (nobody)
Summary: code that generates a segfault on Python 2.1-2.3

Initial Comment:
On a Redhat Linux 9 based system, the following causes
a segfault:


""" In python, you can call any expression.
"""

class foo:
  def __init__(s,times=1):
     s.times = times
  def __call__(s): print s.times
  def __mul__(s,o): return foo(o)
  def __coerce__(s,o):
    if isinstance(o,int):
      return o,s


(foo(3)*10)()   # no segfault
 
(10*foo(3))()   # segfaults
# prints 10

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-07-22 14:18

Message:
Logged In: YES 
user_id=908995

This is not the same problem as bug #980352; this one is an infinite recusion 
in the instance code (deriving foo from object makes the example work).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-16 13:45

Message:
Logged In: YES 
user_id=6656

Isn't this likely to be a dup of bug 

[ 980352 ] coercion results used dangerously

?  I haven't thought about either very hard, but both involve 
__coerce__ and core dumps...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 16:26:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 16:26:41 2004
Subject: [ python-Bugs-995925 ] method after() and afer_idle() are not
	thread save
Message-ID: <E1BneWp-0000zP-00@sc8-sf-web3.sourceforge.net>

Bugs item #995925, was opened at 2004-07-22 15:48
Message generated for change (Settings changed) made by thaar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995925&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Haar (thaar)
Assigned to: Martin v. L?wis (loewis)
>Summary: method after() and afer_idle() are not thread save

Initial Comment:
The methods afer() and after_idle() register the
callback function in the list self._tclCommands. This
List is member of the Misc class in the file tkinter.py
and is not protected by a lock. 
So it could be that the thread  access the list by
calling the function after() and to the same time the
tkinter mainloop access the list  by the methode
deletecommand() in the callback function.  The same
problem will occur if the function after() is called by
two theads.

solution: 
Create a lock object and save the list 
self._tclCommands in the methods :

misc.destroy()
misc.deletecommand()
misc._register()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995925&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 16:27:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 16:27:08 2004
Subject: [ python-Bugs-995907 ] memory leak with threads and enhancement of
	the timer class
Message-ID: <E1BneXG-00010a-00@sc8-sf-web3.sourceforge.net>

Bugs item #995907, was opened at 2004-07-22 15:16
Message generated for change (Settings changed) made by thaar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995907&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Haar (thaar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: memory leak with threads and enhancement of the timer class

Initial Comment:
If i use the Timer cyclically the  memory becomes
always less.


I found following problems::

1.) The thread is not clean deleted.=>
file:threading.py  class: Thread methode:__delete

del _active[_get_ident()] only delete the thead from
the list, not the thead self.  I think the call of the
destructor of the c++ based library need a explicit del.

The problem will be fixed with following lines:

    def __delete(self):
        _active_limbo_lock.acquire()
        t=_active[_get_ident()]
        del _active[_get_ident()]
        del t
        _active_limbo_lock.release()

2.) A cyclic timer is a needed feature and it should
not use a new thread every time.

So i made following enhancement (parameter cyclic) in the 
file:threading.py  class: _Timer  

class _Timer(Thread):
    """Call a function after a specified number of seconds:

    t = Timer(30.0, f, args=[], kwargs={})
    t.start()
    t.cancel() # stop the timer's action if it's still
waiting
    """

    def __init__(self, interval, function, cyclic=0,
args=[], kwargs={}):
        Thread.__init__(self)
        self.interval = interval
        self.function = function
        self.args = args
        self.kwargs = kwargs
        self.finished = Event()
        self.cyclic= Event()
        if cyclic:
            self.cyclic.set()

    def cancel(self):
        """Stop the timer if it hasn't finished yet"""
        self.cyclic.clear()
        self.finished.set()

    def run(self):
        flag =1
        while flag:
            self.finished.wait(self.interval)
            if not self.finished.isSet():
                self.function(*self.args, **self.kwargs)
            if not self.cyclic.isSet():
                self.finished.set()
                flag = 0         





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995907&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 16:46:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 16:47:18 2004
Subject: [ python-Bugs-995422 ] title case bug
Message-ID: <E1BneqP-0001sx-00@sc8-sf-web3.sourceforge.net>

Bugs item #995422, was opened at 2004-07-21 12:56
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995422&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Kimo Johnson (mkimojohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: title case bug

Initial Comment:
>>> "I'll be seeing tom's friend".title()
"I'Ll Be Seeing Tom'S Friend"

I would expect:
"I'll Be Seeing Tom's Friend"


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-22 09:46

Message:
Logged In: YES 
user_id=80475

MS Excel shows the exact same behavior.

IIRC, the reason is that the apostrophe is sometimes used as
a quotation mark and that the capitalization conventions
vary from language to language:  J'ai L'addition  etc.



----------------------------------------------------------------------

Comment By: Baris Metin (tbmetin)
Date: 2004-07-22 02:22

Message:
Logged In: YES 
user_id=1045504

We have, the same kind of problem with non-asci characters. 
I've offered a solution in patch #995740 (fix for title case bug: 
#995422). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995422&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 16:49:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 16:49:38 2004
Subject: [ python-Bugs-995956 ] TclError with intel's hypertheading
Message-ID: <E1Bnet4-0001wc-00@sc8-sf-web4.sourceforge.net>

Bugs item #995956, was opened at 2004-07-22 16:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995956&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Haar (thaar)
Assigned to: Martin v. L?wis (loewis)
Summary: TclError with intel's hypertheading

Initial Comment:
If i use the "intel hyperthreading technologie", my
python application make a coredump with the output:

  File "C:\PROGRA~2\PYTHON~2\lib\lib-tk\Tkinter.py",
line 472, in after
    return self.tk.call('after', ms, name)
TclError: expected integer but got "9118984callit"

The test runs at the following system.
Microsoft windows 2000 5.00.2195 Service Pack 4
Intel Pentium 4 CPU 2.5 Ghz
522.988 KB RAM.


The error never occur, if i turn the hyperthreading in
the bios off.
I made the self test at 2 other pc with the same
hardware and configurations.  The result was the same.

I made another test with a linux pc, a laptop with xp
and a laptop with win2000. All without hyperthreading.
The error has not occured.

I add the log file and the test as attachment.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995956&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 17:32:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 17:32:59 2004
Subject: [ python-Bugs-995983 ] Operations between sets
Message-ID: <E1BnfZ2-0000Bm-00@sc8-sf-web1.sourceforge.net>

Bugs item #995983, was opened at 2004-07-22 17:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995983&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Nobody/Anonymous (nobody)
Summary: Operations between sets

Initial Comment:
The documentation for the new Set types does not say 
anything about applying a binary operation between two 
sets of different type (i.e. one is a frozenset, the other 
is a normal set).

I suppose the result is always a nromal set, but this 
should be documented.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995983&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 17:37:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 17:37:45 2004
Subject: [ python-Bugs-995987 ] 'set' only operations
Message-ID: <E1Bnfde-0000Ok-00@sc8-sf-web1.sourceforge.net>

Bugs item #995987, was opened at 2004-07-22 17:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995987&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'set' only operations

Initial Comment:
In section 2.3.7, the paragraph near the end, beginning 
with "For convenience in implementation", should be put 
after the second table because it contains the remove() 
and discard() methods which are introduced in that 
table.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995987&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 18:55:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 18:55:46 2004
Subject: [ python-Bugs-991196 ] An inconsistency with nested scopes
Message-ID: <E1Bngr7-0006tn-00@sc8-sf-web3.sourceforge.net>

Bugs item #991196, was opened at 2004-07-14 14:30
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991196&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Jacobson (nickjacobson)
Assigned to: Nobody/Anonymous (nobody)
Summary: An inconsistency with nested scopes

Initial Comment:
There's an inconsistency with nested scopes.

>From the Python Ref. Manual:

"If [a local variable] definition occurs in a function block, 
the scope extends to any blocks contained within the 
defining one..."

i.e. So as long as code is not on the module level, 
scopes are extended.  Therefore this works:

def main():
	y = 3
	def execfunc():
		print y
	execfunc()

if __name__ == '__main__':
	main()

In addition, if code IS on the module level, its variables 
go in globals().  So this works too:

y = 3
def execfunc():
	print y
execfunc()

However, (here's the inconsistency) the following code 
fails, saying that y is undefined:

def main():
	s = """
y = 3
def execfunc():
	print y
execfunc()
"""
	d = {}
	e = {}
	exec s in d, e

if __name__ == '__main__':
	main()

In this case, the code in s is treated like it's on the 
module level, and the nested scope treatment of y 
doesn't occur.  BUT, unlike normal code on the module 
level, y doesn't go in globals().  I think globals() is 
locked or something?


Conclusion:

The latter piece of code should work; that is, y should 
be nested and therefore recognized by execfunc().


----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-07-22 09:55

Message:
Logged In: YES 
user_id=341410

>>> def f():
...     y = 5
...     print 'y' in globals(), 'y' in locals()
...     def i():
...         print 'y' in globals(), 'y' in locals()
...     i()
...
>>> f()
False True
False False
>>>
>>> def g():
...     gl = {};lo={}
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals()
... def i():
...     print 'y' in globals(), 'y' in locals()
... i()
... ''' in gl, lo
...
>>> g()
False True
False False

That looks constant...but what if we print out 'y'?

>>> def s():
...     y = 5
...     print 'y' in globals(), 'y' in locals(), y
...     def i():
...         print 'y' in globals(), 'y' in locals(), y
...     i()
...
>>> s()
False True 5
False True 5
>>>
>>> def t():
...     gl = {};lo = {}
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals(), y
... def i():
...     print 'y' in globals(), 'y' in locals(), y
... i()
... ''' in gl, lo
...
>>> t()
False True 5
False False
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in t
  File "<string>", line 5, in ?
  File "<string>", line 4, in i
NameError: global name 'y' is not defined

Now why did 'y' stick itself into the locals() of i() in
s()?  Is this another bug?

What if we remove the namespaces gl and lo?

>>> def u():
...     exec '''y = 5
... print 'y' in globals(), 'y' in locals(), y
... def i():
...     print 'y' in globals(), 'y' in locals(), y
... i()
... '''
...
>>> u()
False True 5
False False
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 2, in u
  File "<string>", line 5, in ?
  File "<string>", line 4, in i
NameError: global name 'y' is not defined

Nope, still dies.  It does seem to be a bug in exec.  I'm
still curious why 'y' was placed into i()'s local namespace
in s().

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991196&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 20:30:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 20:30:59 2004
Subject: [ python-Bugs-531205 ] Bugs in rfc822.parseaddr()
Message-ID: <E1BniLH-0006Zo-00@sc8-sf-web1.sourceforge.net>

Bugs item #531205, was opened at 2002-03-18 06:13
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Ben Gertzfield (che_fox)
Summary: Bugs in rfc822.parseaddr()

Initial Comment:
This bug is in rfc822.parseaddr(), and thus inherited
into email.Utils.parseaddr() since the latter does a
straight include of the former.  It has a nasty bug
when the email address contains embedded spaces: it
collapses the spaces:

&gt;&gt;&gt; from email.Utils import parseaddr
&gt;&gt;&gt; parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
&gt;&gt;&gt; parseaddr('&lt;foo bar@wooz.org&gt;')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more
involved to implement in an RFC 2822 compliant way, but
it would be very cool.

Note that I'm reporting this bug here instead of the
mimelib project because it's actually in rfc822.py. 
Once solution might include fixing it in the email
package only.




----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-22 20:30

Message:
Logged In: YES 
user_id=469548

Well, the docs say "unless the parse fails, in which case a
2-tuple of ('', '') is returned". I think it's reasonable to
say that non-compliant addresses like this should fail to
parse and thus that parseaddr('foo bar@wooz.org') should
returns ('', '')

----------------------------------------------------------------------

Comment By: Tim Roberts (timroberts)
Date: 2002-08-12 23:40

Message:
Logged In: YES 
user_id=265762

Interesting to note that RFC 822 (but not 2822) allows spaces 
around any periods in the address without quoting (2822 does 
allow spaces around the @), and those spaces are to be 
removed.  Section A.1.4 gives the example 
   Wilt  .  Chamberlain@NBA.US
and says it should be parsed as &quot;Wilt.Chamberlain&quot;.

Given that, it's hard for me to see that the current behavior 
should be changed at all, since there is no correct way to 
parse this non-compliant address.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-04-15 19:18

Message:
Logged In: YES 
user_id=12800

Note further that &quot;foo bar&quot;@wooz.org is properly parsed. 
The question is, what should parseaddr() do in this
non-compliant situation?  I can think of a couple of things:

- it could raise an exception
- it could return ('', 'bar@wooz.org')
- it could return ('foo', 'bar@wooz.org')
- it could return ('' '&quot;foo bar&quot;@wooz.org')

I'm not sure what the right thing to do is.  I'm assigning
to Ben Gertzfield to get his opinion.  Ben, feel free to add
a comment and re-assign the bug to me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 21:09:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 21:09:41 2004
Subject: [ python-Bugs-995983 ] Operations between sets
Message-ID: <E1Bniwk-00082X-00@sc8-sf-web1.sourceforge.net>

Bugs item #995983, was opened at 2004-07-22 10:32
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995983&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Operations between sets

Initial Comment:
The documentation for the new Set types does not say 
anything about applying a binary operation between two 
sets of different type (i.e. one is a frozenset, the other 
is a normal set).

I suppose the result is always a nromal set, but this 
should be documented.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-22 14:09

Message:
Logged In: YES 
user_id=80475

The result matches the type of the left-hand operand:

   set & frozenset --> set
   frozenset & set --> frozenset

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995983&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 21:13:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 21:13:06 2004
Subject: [ python-Bugs-995987 ] 'set' only operations
Message-ID: <E1Bnj00-0006za-00@sc8-sf-web2.sourceforge.net>

Bugs item #995987, was opened at 2004-07-22 10:37
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995987&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: 'set' only operations

Initial Comment:
In section 2.3.7, the paragraph near the end, beginning 
with "For convenience in implementation", should be put 
after the second table because it contains the remove() 
and discard() methods which are introduced in that 
table.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995987&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 21:34:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 21:34:11 2004
Subject: [ python-Bugs-995987 ] 'set' only operations
Message-ID: <E1BnjKR-0003wz-00@sc8-sf-web4.sourceforge.net>

Bugs item #995987, was opened at 2004-07-22 10:37
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995987&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Raymond Hettinger (rhettinger)
Summary: 'set' only operations

Initial Comment:
In section 2.3.7, the paragraph near the end, beginning 
with "For convenience in implementation", should be put 
after the second table because it contains the remove() 
and discard() methods which are introduced in that 
table.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995987&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 21:34:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 21:37:35 2004
Subject: [ python-Bugs-995983 ] Operations between sets
Message-ID: <E1BnjKg-0003xa-00@sc8-sf-web4.sourceforge.net>

Bugs item #995983, was opened at 2004-07-22 10:32
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995983&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Operations between sets

Initial Comment:
The documentation for the new Set types does not say 
anything about applying a binary operation between two 
sets of different type (i.e. one is a frozenset, the other 
is a normal set).

I suppose the result is always a nromal set, but this 
should be documented.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-22 14:09

Message:
Logged In: YES 
user_id=80475

The result matches the type of the left-hand operand:

   set & frozenset --> set
   frozenset & set --> frozenset

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995983&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 22:48:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 22:48:52 2004
Subject: [ python-Bugs-994101 ] urllib2: improper capitalization of headers
Message-ID: <E1BnkUh-0001xa-00@sc8-sf-web2.sourceforge.net>

Bugs item #994101, was opened at 2004-07-19 23:22
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Sayre (franklinmint)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2: improper capitalization of headers

Initial Comment:
urllib2.py version 1.72 uses capitalize() on HTTP
header names. This results in headers like "User-agent"
instead of "User-Agent". This causes HTTP 400 errors on
some servers when the request has a body, because there
are two content length headers placed in the request:

"Content-Length" (inserted by httplib)
"Content-length" (inserted by
Request.add_unredirected_header)

The capitalization is incorrect, and httplib inserts
Content-Length anyway, so I'm not sure why urllib2 is
bothering.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-22 22:48

Message:
Logged In: YES 
user_id=469548

Patch is available at http://python.org/sf/996159.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470
From noreply at sourceforge.net  Thu Jul 22 23:09:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 22 23:09:20 2004
Subject: [ python-Bugs-995019 ] Ensure -single_module on Mac OS X
Message-ID: <E1BnkoR-0007Kk-00@sc8-sf-web3.sourceforge.net>

Bugs item #995019, was opened at 2004-07-21 08:19
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jack Jansen (jackjansen)
Summary: Ensure -single_module on Mac OS X

Initial Comment:
When building Python (and disutils based extensions) on Mac OS 
X, Python should ensure that the -single_module flag is being 
passed to the linker.

This will ensure that any given .so, .dylib, or framework is linked 
as a single module.   This will vastly reduce the startup times of 
python, reduce the load times of modules, and shave a bit of a 
performance hit off the top at runtime.

This should also be applicable to the modules built by distutils.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-07-22 23:09

Message:
Logged In: YES 
user_id=45365

Am I doing something wrong? I see absolutely no difference in runtime 
with this option: I get 0.15 seconds realtime (0.08 user time, system 
time variable) both with the new OTHER_LIBTOOL_OPT and without it.
(This is on a 933Mhz G4 iBook running 10.3.4).

I've been trying this with 2.4a1+.

What sort of speedups are you guys seeing?

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 11:50

Message:
Logged In: YES 
user_id=139309

time python -c pass is probably sufficient..

I guess the patch is to line 114 of Makefile.pre.in.. should change from:

OTHER_LIBTOOL_OPT = -prebind -seg1addr 0x10000000

to

OTHER_LIBTOOL_OPT = -prebind -seg1addr 0xCFC00000 -single_module

Note I picked an arbitrary, probably unused, seg1addr.  0x10000000 is 
*NOT* correct!  It's in the Application Address Range!!!! See:
http://developer.apple.com/documentation/Performance/Conceptual/
LaunchTime/index.html

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-07-21 11:21

Message:
Logged In: YES 
user_id=45365

Could either of you come up with a patch? Also, how would I measure 
any improvement, "time python -c pass" or are there other things that 
are influenced as well?

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 10:25

Message:
Logged In: YES 
user_id=139309

Not in the least.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-21 08:57

Message:
Logged In: YES 
user_id=43607

Is this related to bug 799088?

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2004-07-21 08:35

Message:
Logged In: YES 
user_id=103811

This is not applicable to the distutils modules as they are built now;  
only applicable to Python.framework (and like builds).


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-07-21 08:29

Message:
Logged In: YES 
user_id=139309

[I'm closing 995023, because bbum filed first]

distutils extensions can not use -single_module because they are 
bundles, not dylibs.  Frameworks and dylibs are synonymous, of course.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995019&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 01:44:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 01:44:12 2004
Subject: [ python-Bugs-996259 ] readline function pointer with not tty's
Message-ID: <E1BnnEP-0008Tx-00@sc8-sf-web2.sourceforge.net>

Bugs item #996259, was opened at 2004-07-22 23:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996259&group_id=5470

Category: Parser/Compiler
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Lisandro Dalcin (dalcinl)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline function pointer with not tty's

Initial Comment:
In Python 2.3.x C/C++ API,  the souce file Parser/myreadline.c in 
function PyOS_Readline() says:
        
        /* This is needed to handle the unlikely case that the
         * interpreter is in interactive mode *and* stdin/out are not
         * a tty.  This can happen, for example if python is run like
         * this: python -i < test1.py
         */
        if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout)))
                rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt);
          else */
                rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout,
                                                     prompt);

When sys_stdin or sys_stdout are not a tty, there is not way of calling 
the readline function pointer.

I am working in a parallelized version of the Python interpreter, and I 
used the pointer to implement a specialized version of the readline 
function: it reads input in 'root' process (using the original readline 
function) and broadcasts string data to slaves. 

Some MPI implementations (i.e. MPICH) don seems to have stdin and 
stdout connected to a tty in processes other than the 'master' or 'root' 
one, being impossible to me to override the input mechanism.

My workaround was patching the sources, eliminating the if/else lines..

There is another way of handling the cases like
$ python -i < test1.py ????

Am I forgetting something?

Thanks in advance....

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996259&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 07:53:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 07:53:43 2004
Subject: [ python-Bugs-996359 ] Bug somewhere in email Parser or
	PortableUnixMailbox
Message-ID: <E1Bnt00-00063l-00@sc8-sf-web3.sourceforge.net>

Bugs item #996359, was opened at 2004-07-23 00:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996359&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Bug somewhere in email Parser or PortableUnixMailbox

Initial Comment:
When run under Python 2.3 and fed a unix mbox file
on stdin, this script prints the lengths of the messages
in the file and their subjects on stdout:

import sys
import mailbox
import email.Parser

for msg in mailbox.PortableUnixMailbox(sys.stdin, 
email.Parser.Parser().parse):
    print len(str(msg)), msg["subject"]

If run using Python from CVS it prints out "38" as the
length of each message and "None" as the subject.
Something clearly changed between 2.3 and 2.4.
I've not had a chance to dig into the problem yet.
Am I using PortableUnixMailbox or email.Parser.Parser
in some unsupported and now broken way?

Assigning to Barry since he's the obvious email guru,
but anyone can feel free to jump in here.  This would
seem to be a fairly serious bug.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996359&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 09:18:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 09:18:08 2004
Subject: [ python-Bugs-996392 ] math and cmath docs don't specify radians
Message-ID: <E1BnuJh-0001pH-00@sc8-sf-web4.sourceforge.net>

Bugs item #996392, was opened at 2004-07-23 07:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: math and cmath docs don't specify radians

Initial Comment:
The math and cmath functions take their parameters in 
radians, but there is nothing stating this.

The closest is "The math module consists mostly of thin 
wrappers around the platform C math library functions.".

For starters, are we guaranteed that the platform math 
functions take radians?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 09:51:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 09:51:35 2004
Subject: [ python-Bugs-736407 ] Problem With email.MIMEText Package
Message-ID: <E1Bnuq3-0007QE-00@sc8-sf-web1.sourceforge.net>

Bugs item #736407, was opened at 2003-05-12 09:41
Message generated for change (Comment added) made by judasiscariot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 5
Submitted By: John Abel (judasiscariot)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Problem With email.MIMEText Package

Initial Comment:
Problem with email.MIMEText.  I created a MIMEText
message (following the example in the documentation). 
The problem occurs when as_string() is called.  This is
the traceback:

  File &quot;/usr/local/lib/python2.3/email/Message.py&quot;,
line 113, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File &quot;/usr/local/lib/python2.3/email/Generator.py&quot;,
line 102, in flatten
    self._write(msg)
  File &quot;/usr/local/lib/python2.3/email/Generator.py&quot;,
line 137, in _write
    self._write_headers(msg)
  File &quot;/usr/local/lib/python2.3/email/Generator.py&quot;,
line 183, in _write_headers
    header_name=h, continuation_ws='\t').encode()
  File &quot;/usr/local/lib/python2.3/email/Header.py&quot;, line
415, in encode
    return self._encode_chunks(newchunks, maxlinelen)
  File &quot;/usr/local/lib/python2.3/email/Header.py&quot;, line
375, in _encode_chunks
    _max_append(chunks, s, maxlinelen, extra)
  File &quot;/usr/local/lib/python2.3/email/quopriMIME.py&quot;,
line 84, in _max_append
    L.append(s.lstrip())
AttributeError: 'list' object has no attribute 'lstrip'

I'm using 2.3b1, on RH9.  The same piece of code works
with 2.2.2.


----------------------------------------------------------------------

>Comment By: John Abel (judasiscariot)
Date: 2004-07-23 07:51

Message:
Logged In: YES 
user_id=221478

Since upgrading to 2.3.4, this problem has gone away.  I
have a 2.3.2 version somewhere, so I'll test on that, if
that helps?

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-05-10 15:13

Message:
Logged In: YES 
user_id=12800

I need to know what the value of oldFiles is when you run
BareMail.py.  I've had no problems with this example, but I
suppose it's possible you might if you were running on a
system with unicode file names and there were some funky
characters in your file names.

FWIW, this code works fine for me in Python 2.3.3 and Python
2.4cvs.  I'm re-pending this bug report for more information.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2004-03-22 11:35

Message:
Logged In: YES 
user_id=221478

OK, stripped everything down to a minimum.  I now have a
class, based upon the example from the email docs.  It still
gives the same error, when mailMessage.as_string() is called.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-21 20:29

Message:
Logged In: YES 
user_id=12800

There have no follow ups to this message in months, so I'm
moving it to Pending status.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-03 12:15

Message:
Logged In: YES 
user_id=12800

Sorry, but you're going to have to work harder at trying to
boil down the buggy code.  When I run ServerMonitor.py, I
get an immediate traceback

Traceback (most recent call last):
  File &quot;ServerMonitor.py&quot;, line 18, in ?
    import ThreadUtils, NetMon
ImportError: No module named ThreadUtils

Here's one thing you can try to do: catch the exception in
your code, then pickle the Message object up and post the
pickle.  I can at least reconstitute the pickle and look at
the structure.

Also, I'm guessing the problem is somewhere in ProcessMail()
in PostITControl.py.  Be sure that the mailBody argument is
a string and nothing else.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-21 08:16

Message:
Logged In: YES 
user_id=221478

The Config.ini will need to modifying to suit your machine
settings.  Run the ServerMonitor.py, and then run
PostITControl.py.  PostITControl.py crashes when trying to
send a mail.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-21 08:13

Message:
Logged In: YES 
user_id=221478

Sorry, been trying to narrow the code down.  If I have a
bare minimum script, it works, yet the original still fails.
 I'll upload the required files (3).

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-19 19:59

Message:
Logged In: YES 
user_id=12800

I'm moving this to Pending since wthout more information I
can't help. This starts the 14 day clock ticking.  After 2
weeks this bug report will be closed, unless someone follows
up with more information.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-15 14:07

Message:
Logged In: YES 
user_id=12800

Sorry, the attached code sample is incomplete.  It is not
sufficient for me to reproduce the problem.

Please boil down your example to a self-contained -- but as
small as possible -- example.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-15 09:32

Message:
Logged In: YES 
user_id=221478

Sorry, forgot the comment.  When running the script using
python2.2 (email 2.4.3), I don't receive any errors, mail
gets sent.  It only seems to happen with 2.3b.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-13 15:45

Message:
Logged In: YES 
user_id=12800

Can you upload the exact code that you wrote that caused
this crash?  Please don't paste it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 12:12:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 12:12:18 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1Bnx2E-0003DV-00@sc8-sf-web2.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:12

Message:
Logged In: YES 
user_id=38388

Hye-Shik, are you working on a patch to move the implementation
as suggested ?

Just asking, because I don't was the current layout to go
into the
Python 2.4 final...

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 19:36

Message:
Logged In: YES 
user_id=38388

Martin, you can code such a function in your application
based on the information you'd get from
unicodedata.east_asian_width(). As we've seen, there is no
generally sound way to define such a function.

As for the location of the data: the unicodedata module is
the place where any extra information related to Unicode
should go. unicodectype.c is reserved for data needed at C
level by the Python Unicode C API.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 19:24

Message:
Logged In: YES 
user_id=21627

I still think a function is useful which computes the number
of Ems that a conventional application would expect. That
function should raise an exception for a neutral character -
the example of the combining characters shows that such
characters should *not* be treated as narrow "for all
practical purposes".

Whether or not it is useful to include the entire UAX#11
classification in the database I don't know - it seems the
only application of the data would be computation of the
width, anyway.

It would not be wise to move the data to the unicode
database, as the extra data currently don't affect Python
programs that don't use the function, anyway - the data does
not consume any additional space.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 11:39

Message:
Logged In: YES 
user_id=38388

Hye-Shik, the patch only includes the move to unicodedata, but
not the full implementation of the EAW as per the TR. I would
much prefer to have the east_asian_width() function return
the strings defined in the TR because this allows users of the
function to read the information and implement their own 
interpretation of "width".

The new function should work very much like 
unicodedata.category().

It would also be wise to move the data itself over to the
unicode
database - that way the extra data does not affect Python
programs that don't use the function.

Thanks.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-14 17:15

Message:
Logged In: YES 
user_id=55188

Marc-Andre, here's a patch written as you've suggested.
Can you please give a review on this?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 21:41

Message:
Logged In: YES 
user_id=38388

Thanks for your descriptions, Hye-Shik.

Since the application space is very much targetted at East
Asian scripts, I would like the implementation to be moved
into unicodedata where all the other special Unicode
features are implemented. The .width() method should be removed.

Now that I understand better what the EAW is about, I would
also like to see the function be renamed to
east_asian_width() since that's what the function is based on.

If possible, I'd also rather like to see the full width
mapping implemented (as defined in the TR). The reduction to
narrow vs. wide seems to be oversimplified. The
east_asian_width() function should return the characters:
"N", "A", "H", "W", "F", "Na" and let the user decide how to
map these to character or string widths. We have followed
the same methodology for the other Unicode database
properties and this has not only given us much more
flexibility, it also is standards compliant and you can get
good documentation on these features.

Matthew, I suggest you write your own implementation of what
you think is right. In the face of ambiguity, there's no
such thing as the right approach to a certain problem.

Thanks.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 18:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 17:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 17:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 16:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 16:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 15:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 12:13:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 12:13:44 2004
Subject: [ python-Bugs-990743 ] Crash when importing encoded file
Message-ID: <E1Bnx3Z-0003Ff-00@sc8-sf-web2.sourceforge.net>

Bugs item #990743, was opened at 2004-07-14 11:05
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990743&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
>Assigned to: Martin v. L?wis (loewis)
Summary: Crash when importing encoded file

Initial Comment:
Python crashes (!) when it meets a non-ascii character in a file with 
encoding in use.

For example:
<file foo.py>
# encoding: mac-roman

...

<square root character>


<in Python>
>>> import user #so we can import 
>>> import foo
Parser/tokenizer.c:366: failed assertion `strlen(str) < (size_t)size'
Abort

When debugging, I found the StreamReader.readline() routine in 
codecs.py. It self.calls decode, which does return well; then readline 
returns, and then the inevitable happens.
Readline is called straight from the toplevel (from the viewpoint of 
the debugger), which probably means calling readline is part of the 
import logic in C.
So the bug must somewhere in there...
- Jurjen

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:13

Message:
Logged In: YES 
user_id=38388

Martin, could you have a look at this ? Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990743&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 12:23:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 12:23:21 2004
Subject: [ python-Bugs-967986 ] file.encoding doesn't apply to file.write
Message-ID: <E1BnxCw-0000CF-00@sc8-sf-web4.sourceforge.net>

Bugs item #967986, was opened at 2004-06-07 09:00
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967986&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: file.encoding doesn't apply to file.write

Initial Comment:
In python2.3 printing unicode to an appropriate terminal
actually works.  But using sys.stdout.write doesn't.

Ex:
Python 2.3.4 (#2, May 29 2004, 03:31:27) 
[GCC 3.3.3 (Debian 20040417)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> sys.stdout.encoding
'UTF-8'
>>> u=u'\u3053\u3093\u306b\u3061\u308f'
>>> print u
&#12371;&#12435;&#12395;&#12385;&#12431;
>>> sys.stdout.write(u)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 0-4: ordinal not in range(128)


The file object docs say:
"encoding
    The encoding that this file uses. When Unicode
strings are written to
    a file, they will be converted to byte strings
using this encoding.
    ..."
Which indicates to me that it is supposed to work.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:23

Message:
Logged In: YES 
user_id=38388

The encoding feature is currently only implemented for
printing. We could also add it to .write() and .writelines()
... patches are welcome.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967986&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 12:29:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 12:29:49 2004
Subject: [ python-Bugs-964929 ] Unicode String formatting does not correctly
	handle objects
Message-ID: <E1BnxJA-0004vx-00@sc8-sf-web1.sourceforge.net>

Bugs item #964929, was opened at 2004-06-02 12:48
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964929&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode String formatting does not correctly handle objects

Initial Comment:
I have a problem with the way '%s' is handled in
unicode strings when formatted. The Python Language
refrence states that a unicode serialisation of an
object should be in __unicode__, and I have seen python
break down if unicode data is returned in __str__.

The problem is that there does not appear to be a way
to interpolate the results from __unicode__ within a
string:

class EuroHolder:
    def __init__(self, price):
        self._price = price
    def __str__(self):
        return "%.02f euro" % self._price
    def __unicode__(self):
        return u"%.02f\u20ac" % self._price

>>> class EuroHolder:
...     def __init__(self, price):
...         self._price = price
...     def __str__(self):
...         return "%.02f euro" % self._price
...     def __unicode__(self):
...         return u"%.02f\u20ac" % self._price
... 
>>> e = EuroHolder(123.45)
>>> str(e)
'123.45 euro'
>>> unicode(e)
u'123.45\u20ac'
>>> "%s" % e
'123.45 euro'
>>> u"%s" % e #this is wrong
u'123.45 euro'
>>> u"%s" % unicode(e) # This is silly
u'123.45\u20ac'
>>> 

The first case is wrong, as I actually could cope with
unicode data in the string I was substituting into, and
I should be able to request the unicode data be put in.

The second case is silly, as the whole point of string
substion variables such as %s, %d and %f is to remove
the need for coercion on the right of the %.

Proposed solution #1:
Make %s in unicode string substitution automatically
check __unicode__() of the rvalue before trying
__str__(). This is the most logical thing to expect of
%s, if you insist on overloading it the way it
currently does when a unicode object in the rvalue will
ensure the result is unicode.

Proposed solution #2:
Make a new string conversion operator, such as %S or %U
which will explicitly call __unicode__() on the rvalue
even if the lvalue is a non-unicode string

Solution #2 has the advantage that it does not break
any previous behaviour of %s, and also allows for
explicit conversion to unicode of 8-bits string in the
lvalue.

I prefer solution #1 as I feel that the current
operation of %s is incorrect, and it's unliekly to
break much, whereas the "advantage" of converting 8-bit
strings in the lvalue to unicode which solution #2
advocates will just lead to encoding problems and
sloppy code.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:29

Message:
Logged In: YES 
user_id=38388

Good point.

I think the only change needed is to use PyObject_Unicode()
instead of PyObject_Str() in unicodeobject.c's
PyUnicode_Format(). This would then implement #1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964929&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 12:34:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 12:34:56 2004
Subject: [ python-Bugs-928297 ] platform.libc_ver() fails on Cygwin
Message-ID: <E1BnxO7-00042M-00@sc8-sf-web2.sourceforge.net>

Bugs item #928297, was opened at 2004-04-02 16:55
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: M.-A. Lemburg (lemburg)
Summary: platform.libc_ver() fails on Cygwin

Initial Comment:
>>> import platform
>>> platform.libc_ver()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/platform.py", line 134, in libc_ver
    f = open(executable,'rb')
IOError: [Errno 2] No such file or 
directory: '/usr/bin/python'

The problem is that on Cygwin sys.executable 
returns /path/to/python, but since Cygwin is running on 
Windows, sys.executable is a symbolic link 
to /path/to/python.exe.

>>> import os, sys
>>> os.path.exists(sys.executable)
True
>>> os.path.isfile(sys.executable)
True
>>> file(sys.executable)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or 
directory: '/usr/bin/python'
>>> os.path.islink(sys.executable)
True
>>> os.path.realpath(sys.executable)
'/usr/bin/python2.3.exe'
>>> file(sys.executable + '.exe')
<open file '/usr/bin/python.exe', mode 'r' at 0xa100ca0>

Following is the info about the machine I tested:

>>> from platform import *
>>> platform()
'CYGWIN_NT-5.0-1.5.7-0.109-3-2-i686-32bit'
>>> python_compiler()
'GCC 3.3.1 (cygming special)'
>>> python_build()
(1, 'Dec 30 2003 08:29:25')
>>> python_version()
'2.3.3'
>>> uname()
('CYGWIN_NT-5.0', 'my_user_name', '1.5.7
(0.109/3/2)', '2004-01-30 19:32', 'i686', '')


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:34

Message:
Logged In: YES 
user_id=38388

Would applying os.path.realpath() to sys.executable before
trying to open that file fix the problem on Cygwin ?

Another question: does using libc_ver() even make sense on
cygwin ?

libc_ver() was never intended to be used on non-*nix
platforms. I don't even know whether it works on other
platforms than Linux.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2004-04-03 06:20

Message:
Logged In: YES 
user_id=671362

First, I need to correct my previous post. 'symbolic' was 
unrelated.
Python on Cygwin does't like exe files that doesn't end 
with '.exe'.
I think changing fileobject.c to support I/O exe files on 
Cygwin whether it ends with '.exe' or not is the way to go.

Is there anyone who can do that? It's beyoond my skill level.

$ ls -l /usr/bin/python*
lrwxrwxrwx  1 abel  Users    24 Jan  1 01:34 /usr/bin/python -
> python2.3.exe
lrwxrwxrwx  1 abel  Users    24 Jan  1 
01:34 /usr/bin/python.exe -> python2.3.exe
-rwxrwxrwx  1 abel  Users  4608 Dec 30 
22:32 /usr/bin/python2.3.exe

>>> file('/usr/bin/python')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: '/usr/bin/python'
>>> file('/usr/bin/python.exe')
<open file '/usr/bin/python.exe', mode 'r' at 0xa069320>
>>> file('/usr/bin/python2.3')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or 
directory: '/usr/bin/python2.3'
>>> file('/usr/bin/python2.3.exe')
<open file '/usr/bin/python2.3.exe', mode 'r' at 0xa0c8de0>

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-04-02 17:59

Message:
Logged In: YES 
user_id=38388

Patches are welcome :-)

I don't have cygwin installed, so there's nothing much
I can do about this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 14:27:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 14:27:25 2004
Subject: [ python-Bugs-991834 ] Warning in cjkcodecs/iso2022common.h
Message-ID: <E1Bnz8y-0000wj-00@sc8-sf-web1.sourceforge.net>

Bugs item #991834, was opened at 2004-07-16 04:27
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991834&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Hye-Shik Chang (perky)
Summary: Warning in cjkcodecs/iso2022common.h

Initial Comment:
I get a warning (MacOSX 10.3, gcc 3.3) in cjkcodecs/
iso2022common.h about an uninitialized variable, and it looks 
bona-fide:

/Users/jack/src/python/Modules/cjkcodecs/codecentry.h: In 
function `iso2022processesc':
/Users/jack/src/python/Modules/cjkcodecs/iso2022common.h:186: 
warning: `esclen' might be used uninitialized in this function


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-07-23 21:27

Message:
Logged In: YES 
user_id=55188

iso2022common.h gone away by importing CJKCodecs 1.1.
Do you have any warnings still there?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991834&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 14:29:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 14:29:24 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1BnzAq-00012z-00@sc8-sf-web1.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 12:59
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-07-23 21:29

Message:
Logged In: YES 
user_id=55188

Yes. I am.
I was little bit busy. I'll submit new patch after this weekend.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 19:12

Message:
Logged In: YES 
user_id=38388

Hye-Shik, are you working on a patch to move the implementation
as suggested ?

Just asking, because I don't was the current layout to go
into the
Python 2.4 final...

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-16 02:36

Message:
Logged In: YES 
user_id=38388

Martin, you can code such a function in your application
based on the information you'd get from
unicodedata.east_asian_width(). As we've seen, there is no
generally sound way to define such a function.

As for the location of the data: the unicodedata module is
the place where any extra information related to Unicode
should go. unicodectype.c is reserved for data needed at C
level by the Python Unicode C API.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-16 02:24

Message:
Logged In: YES 
user_id=21627

I still think a function is useful which computes the number
of Ems that a conventional application would expect. That
function should raise an exception for a neutral character -
the example of the combining characters shows that such
characters should *not* be treated as narrow "for all
practical purposes".

Whether or not it is useful to include the entire UAX#11
classification in the database I don't know - it seems the
only application of the data would be computation of the
width, anyway.

It would not be wise to move the data to the unicode
database, as the extra data currently don't affect Python
programs that don't use the function, anyway - the data does
not consume any additional space.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 18:39

Message:
Logged In: YES 
user_id=38388

Hye-Shik, the patch only includes the move to unicodedata, but
not the full implementation of the EAW as per the TR. I would
much prefer to have the east_asian_width() function return
the strings defined in the TR because this allows users of the
function to read the information and implement their own 
interpretation of "width".

The new function should work very much like 
unicodedata.category().

It would also be wise to move the data itself over to the
unicode
database - that way the extra data does not affect Python
programs that don't use the function.

Thanks.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-15 00:15

Message:
Logged In: YES 
user_id=55188

Marc-Andre, here's a patch written as you've suggested.
Can you please give a review on this?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-13 04:41

Message:
Logged In: YES 
user_id=38388

Thanks for your descriptions, Hye-Shik.

Since the application space is very much targetted at East
Asian scripts, I would like the implementation to be moved
into unicodedata where all the other special Unicode
features are implemented. The .width() method should be removed.

Now that I understand better what the EAW is about, I would
also like to see the function be renamed to
east_asian_width() since that's what the function is based on.

If possible, I'd also rather like to see the full width
mapping implemented (as defined in the TR). The reduction to
narrow vs. wide seems to be oversimplified. The
east_asian_width() function should return the characters:
"N", "A", "H", "W", "F", "Na" and let the user decide how to
map these to character or string widths. We have followed
the same methodology for the other Unicode database
properties and this has not only given us much more
flexibility, it also is standards compliant and you can get
good documentation on these features.

Matthew, I suggest you write your own implementation of what
you think is right. In the face of ambiguity, there's no
such thing as the right approach to a certain problem.

Thanks.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-13 01:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-13 00:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-13 00:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 23:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 23:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 22:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 18:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 13:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 14:31:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 14:31:34 2004
Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters
Message-ID: <E1BnzD0-00019v-00@sc8-sf-web1.sourceforge.net>

Bugs item #989185, was opened at 2004-07-12 05:59
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode.width broken for combining characters

Initial Comment:
Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) 
[GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> u'\u3060'.width()
2
>>> u'\u305f\u3099'.width()
4

Width should be two in both cases.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 14:31

Message:
Logged In: YES 
user_id=38388

Great ! Thanks.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-23 14:29

Message:
Logged In: YES 
user_id=55188

Yes. I am.
I was little bit busy. I'll submit new patch after this weekend.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:12

Message:
Logged In: YES 
user_id=38388

Hye-Shik, are you working on a patch to move the implementation
as suggested ?

Just asking, because I don't was the current layout to go
into the
Python 2.4 final...

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 19:36

Message:
Logged In: YES 
user_id=38388

Martin, you can code such a function in your application
based on the information you'd get from
unicodedata.east_asian_width(). As we've seen, there is no
generally sound way to define such a function.

As for the location of the data: the unicodedata module is
the place where any extra information related to Unicode
should go. unicodectype.c is reserved for data needed at C
level by the Python Unicode C API.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-15 19:24

Message:
Logged In: YES 
user_id=21627

I still think a function is useful which computes the number
of Ems that a conventional application would expect. That
function should raise an exception for a neutral character -
the example of the combining characters shows that such
characters should *not* be treated as narrow "for all
practical purposes".

Whether or not it is useful to include the entire UAX#11
classification in the database I don't know - it seems the
only application of the data would be computation of the
width, anyway.

It would not be wise to move the data to the unicode
database, as the extra data currently don't affect Python
programs that don't use the function, anyway - the data does
not consume any additional space.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-15 11:39

Message:
Logged In: YES 
user_id=38388

Hye-Shik, the patch only includes the move to unicodedata, but
not the full implementation of the EAW as per the TR. I would
much prefer to have the east_asian_width() function return
the strings defined in the TR because this allows users of the
function to read the information and implement their own 
interpretation of "width".

The new function should work very much like 
unicodedata.category().

It would also be wise to move the data itself over to the
unicode
database - that way the extra data does not affect Python
programs that don't use the function.

Thanks.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-14 17:15

Message:
Logged In: YES 
user_id=55188

Marc-Andre, here's a patch written as you've suggested.
Can you please give a review on this?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 21:41

Message:
Logged In: YES 
user_id=38388

Thanks for your descriptions, Hye-Shik.

Since the application space is very much targetted at East
Asian scripts, I would like the implementation to be moved
into unicodedata where all the other special Unicode
features are implemented. The .width() method should be removed.

Now that I understand better what the EAW is about, I would
also like to see the function be renamed to
east_asian_width() since that's what the function is based on.

If possible, I'd also rather like to see the full width
mapping implemented (as defined in the TR). The reduction to
narrow vs. wide seems to be oversimplified. The
east_asian_width() function should return the characters:
"N", "A", "H", "W", "F", "Na" and let the user decide how to
map these to character or string widths. We have followed
the same methodology for the other Unicode database
properties and this has not only given us much more
flexibility, it also is standards compliant and you can get
good documentation on these features.

Matthew, I suggest you write your own implementation of what
you think is right. In the face of ambiguity, there's no
such thing as the right approach to a certain problem.

Thanks.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 18:03

Message:
Logged In: YES 
user_id=65253

My complaint was that you were attacking my example using
non-asian characters, when the TR specifically says they are
handled as narrow.

I write Asian characters the same as anything else.  If it's
a unicode string python converts it with sys.stdout.encoding
(for print anyway).  Otherwise you just have to write in
whatever encoding the terminal expects.

And when you are talking about a fixed-width text terminal,
wide characters take 2 columns, narrow take 1. Assuming you
ignore combining characters, which is what this is all
about.  You said the width is only a "hint for rendering
engines", but I cannot think of any rendering engine that
would benefit from a hint that can be 2-3x wider (due to
counting combining characters) than when you actually
display it.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 17:53

Message:
Logged In: YES 
user_id=55188

Major usages that I expected for width() are:

- Hints for terminal-based applications (for cursor position
and layouts)

- To generate fixed-width text documents not ugly: eg.
printing "------" decoration under each subjects.

- More readable limit for table columns: eg. topics in web
bulletins; limiting by same 'characters' will recur very
wide some topic lines full of East Asian characters and
narrow snipped english topics.

- To locate "^" in correct position on Python tracebacks.
This isn't implemented in standard traceback, but width()
allows 3rd party can implement sys.excepthook for East Asian
easily.

In fact, I don't known if width() can easily modified to
support variety of combining characters from Western
characters. But if it isn't too heavy or complicated, I
would volunteer to extend the width() implemention to make
it provide generic fixed-width rendering hint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 17:23

Message:
Logged In: YES 
user_id=38388

I don't understand your complaint: width 1 means "narrow"
just as defined in the TR ?!

How do you write Asian characters to a terminal ?

I think you are mixing glyphs with code points here.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 16:28

Message:
Logged In: YES 
user_id=65253

TR11 says "Strictly speaking, it makes no sense to talk of
narrow and wide for neutral characters, but since for all
practical purposes they behave like Na, they are treated as
narrow characters (the same as Na) under the recommendations
below."  

In addition, the current implementation gives a width of 1
to not east asian characters.  So talking about fixing the
effect of combining characters on non-east asian charecters
is IMHO, just as applicable as combining characters on asian
text.

And for display width, I'd say it is useful when writing to
a terminal.  But not it its current form. Combining
characters obviously have no width, whether they are
"wide"(which just means they are normally combined with wide
characters) or not.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 16:00

Message:
Logged In: YES 
user_id=38388

It would help if you would include the Unicode code point
descriptions...

01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN
CAPITAL LETTER Z BAR;;;01B6;

0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;;

0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING
DIAERESIS;Dialytika;;;

Ie. your example does not even include East Asian characters.

If you read the TR11, you'll find that:
"""
ED7. Not East Asian (Neutral) - all other characters.
Neutral characters do not occur in legacy East Asian
character sets. By extension, they also do not occur in East
Asian typography.  For example, there is no traditional
Japanese way of typesetting Devanagari.

    Strictly speaking, it makes no sense to talk of narrow
and wide for neutral characters, but since for all practical
purposes they behave like Na, they are treated as narrow
characters (the same as Na) under the recommendations below.
"""

Combining marks as the ones that your example uses cannot be
processed by doing a simple database lookup. The two marks
you include are marked as A -- Ambiguous.

Furthermore, you should not mistake the East Asian Width for
the display width. It is merely a hint for rendering
engines. See the TR for details.

Hye-Shik, could you give an example of where the EAS is
actually useful in Python programming ? I hvae a feeling
that it is going to cause more confusion than do good. It
may also be wise to rename the function to
east_asian_width() to signal that the return value does not
have anything to do with a display with, glyphs, etc.

----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2004-07-12 15:06

Message:
Logged In: YES 
user_id=65253

I don't think normalization is sufficient.  For example,
consider:

>>> u'\u01b5\u0327\u0308'.width()
3
>>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width()
3

But width should be one.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-12 11:45

Message:
Logged In: YES 
user_id=38388

To be honest: I don't really know how .width() ended up as
method.
The use context seems to be rather limited in that it only
applies to East Asian code points according to Unicode
Standard Annex #11.

I'd suggest to move the whole implementation to unicodedata
instead
(and then apply normalization before looking up the width).

Reading the UAX11 (http://www.unicode.org/reports/tr11/)
I also have a feeling that taking the sum of all
widths in a string of Unicode code points is not a very useful
approach. Since the width is mainly used for rendering East
Asian
text, only the per code point information is useful.
I think that it would be more appropriate to raise an
exception if you pass in more than one code point to the
function.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-07-12 06:46

Message:
Logged In: YES 
user_id=55188

This sounds that we need to normalize to NFC before
evaluations for unicode.width().
So, I think we'll need to choose how to use normalization
database from width() method.

1. export normalization CAPI functions from unicodedata
module like ucnhash_CAPI and unicodeobject uses it when
width() is first called.

2. move unicode.width() to unicodedata module and use
normalization functions statically.

I would prefer 2. ;)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 16:22:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 16:24:23 2004
Subject: [ python-Bugs-996359 ] Bug somewhere in email Parser or
	PortableUnixMailbox
Message-ID: <E1Bo0wO-0005Yv-00@sc8-sf-web1.sourceforge.net>

Bugs item #996359, was opened at 2004-07-23 00:53
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996359&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Bug somewhere in email Parser or PortableUnixMailbox

Initial Comment:
When run under Python 2.3 and fed a unix mbox file
on stdin, this script prints the lengths of the messages
in the file and their subjects on stdout:

import sys
import mailbox
import email.Parser

for msg in mailbox.PortableUnixMailbox(sys.stdin, 
email.Parser.Parser().parse):
    print len(str(msg)), msg["subject"]

If run using Python from CVS it prints out "38" as the
length of each message and "None" as the subject.
Something clearly changed between 2.3 and 2.4.
I've not had a chance to dig into the problem yet.
Am I using PortableUnixMailbox or email.Parser.Parser
in some unsupported and now broken way?

Assigning to Barry since he's the obvious email guru,
but anyone can feel free to jump in here.  This would
seem to be a fairly serious bug.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-23 09:22

Message:
Logged In: YES 
user_id=44345

Further investigation shows this simpler script demonstrates
the problem:

import sys
import mailbox

for msg in mailbox.PortableUnixMailbox(sys.stdin):
    print len(str(msg))

Looking at mailbox.py it appears v 1.42 is the culprit. 
Reverting to 1.41
solves the problem.  Reassigning to Andrew since he checked
in that
version.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996359&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 16:30:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 16:30:32 2004
Subject: [ python-Bugs-736407 ] Problem With email.MIMEText Package
Message-ID: <E1Bo148-0004rX-00@sc8-sf-web2.sourceforge.net>

Bugs item #736407, was opened at 2003-05-12 05:41
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 5
Submitted By: John Abel (judasiscariot)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Problem With email.MIMEText Package

Initial Comment:
Problem with email.MIMEText.  I created a MIMEText
message (following the example in the documentation). 
The problem occurs when as_string() is called.  This is
the traceback:

  File &quot;/usr/local/lib/python2.3/email/Message.py&quot;,
line 113, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File &quot;/usr/local/lib/python2.3/email/Generator.py&quot;,
line 102, in flatten
    self._write(msg)
  File &quot;/usr/local/lib/python2.3/email/Generator.py&quot;,
line 137, in _write
    self._write_headers(msg)
  File &quot;/usr/local/lib/python2.3/email/Generator.py&quot;,
line 183, in _write_headers
    header_name=h, continuation_ws='\t').encode()
  File &quot;/usr/local/lib/python2.3/email/Header.py&quot;, line
415, in encode
    return self._encode_chunks(newchunks, maxlinelen)
  File &quot;/usr/local/lib/python2.3/email/Header.py&quot;, line
375, in _encode_chunks
    _max_append(chunks, s, maxlinelen, extra)
  File &quot;/usr/local/lib/python2.3/email/quopriMIME.py&quot;,
line 84, in _max_append
    L.append(s.lstrip())
AttributeError: 'list' object has no attribute 'lstrip'

I'm using 2.3b1, on RH9.  The same piece of code works
with 2.2.2.


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-07-23 10:30

Message:
Logged In: YES 
user_id=12800

Probably not.  If the problem doesn't occur for you in 2.3.4
then consider it fixed :)

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2004-07-23 03:51

Message:
Logged In: YES 
user_id=221478

Since upgrading to 2.3.4, this problem has gone away.  I
have a 2.3.2 version somewhere, so I'll test on that, if
that helps?

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-05-10 11:13

Message:
Logged In: YES 
user_id=12800

I need to know what the value of oldFiles is when you run
BareMail.py.  I've had no problems with this example, but I
suppose it's possible you might if you were running on a
system with unicode file names and there were some funky
characters in your file names.

FWIW, this code works fine for me in Python 2.3.3 and Python
2.4cvs.  I'm re-pending this bug report for more information.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2004-03-22 06:35

Message:
Logged In: YES 
user_id=221478

OK, stripped everything down to a minimum.  I now have a
class, based upon the example from the email docs.  It still
gives the same error, when mailMessage.as_string() is called.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-21 15:29

Message:
Logged In: YES 
user_id=12800

There have no follow ups to this message in months, so I'm
moving it to Pending status.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-03 08:15

Message:
Logged In: YES 
user_id=12800

Sorry, but you're going to have to work harder at trying to
boil down the buggy code.  When I run ServerMonitor.py, I
get an immediate traceback

Traceback (most recent call last):
  File &quot;ServerMonitor.py&quot;, line 18, in ?
    import ThreadUtils, NetMon
ImportError: No module named ThreadUtils

Here's one thing you can try to do: catch the exception in
your code, then pickle the Message object up and post the
pickle.  I can at least reconstitute the pickle and look at
the structure.

Also, I'm guessing the problem is somewhere in ProcessMail()
in PostITControl.py.  Be sure that the mailBody argument is
a string and nothing else.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-21 04:16

Message:
Logged In: YES 
user_id=221478

The Config.ini will need to modifying to suit your machine
settings.  Run the ServerMonitor.py, and then run
PostITControl.py.  PostITControl.py crashes when trying to
send a mail.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-21 04:13

Message:
Logged In: YES 
user_id=221478

Sorry, been trying to narrow the code down.  If I have a
bare minimum script, it works, yet the original still fails.
 I'll upload the required files (3).

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-19 15:59

Message:
Logged In: YES 
user_id=12800

I'm moving this to Pending since wthout more information I
can't help. This starts the 14 day clock ticking.  After 2
weeks this bug report will be closed, unless someone follows
up with more information.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-15 10:07

Message:
Logged In: YES 
user_id=12800

Sorry, the attached code sample is incomplete.  It is not
sufficient for me to reproduce the problem.

Please boil down your example to a self-contained -- but as
small as possible -- example.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-15 05:32

Message:
Logged In: YES 
user_id=221478

Sorry, forgot the comment.  When running the script using
python2.2 (email 2.4.3), I don't receive any errors, mail
gets sent.  It only seems to happen with 2.3b.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-13 11:45

Message:
Logged In: YES 
user_id=12800

Can you upload the exact code that you wrote that caused
this crash?  Please don't paste it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 17:45:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 17:45:17 2004
Subject: [ python-Bugs-996626 ] normpath symlinks doc warning (bug #990669)
Message-ID: <E1Bo2EU-0007uo-00@sc8-sf-web2.sourceforge.net>

Bugs item #996626, was opened at 2004-07-23 17:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996626&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: normpath symlinks doc warning (bug #990669)

Initial Comment:
normpath may alter the meaning of a path if it contains
symbolic links. This has been documented in a comment
since 1992, but it should be in the library reference
as well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996626&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 17:45:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 17:45:24 2004
Subject: [ python-Bugs-996627 ] realpath: resolve symlinks before
	normalizing (bug #990669)
Message-ID: <E1Bo2Eb-0003Fp-00@sc8-sf-web3.sourceforge.net>

Bugs item #996627, was opened at 2004-07-23 17:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996627&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: realpath: resolve symlinks before normalizing (bug #990669)

Initial Comment:
This patch fixes the problem described in
http://python.org/sf/990669 and adds tests for realpath.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996627&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 17:45:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 17:45:54 2004
Subject: [ python-Bugs-990669 ] os.path.realpath() does not handle symlinks
	correctly
Message-ID: <E1Bo2F0-0003Gn-00@sc8-sf-web3.sourceforge.net>

Bugs item #990669, was opened at 2004-07-14 06:58
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990669&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Anton Koinov (dave0000)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.realpath() does not handle symlinks correctly

Initial Comment:
os.path.realpath() does not handle symlinks properly on
Linux (at least, does not do it the same way as the
Linux file functions do).

To reproduce follow these steps:

mkdir a
mkdir a/k
mkdir a/l
mkdir a/k/x
mkdir a/k/y
cd a
ln -s k/y link-y
ls link-y/..

This outputs: x/  y/
In other words, link-y/.. == a/k

Now, while still in directory 'a' (in bash) execute on
one line: 
python -c 'import os.path'$'\n''print
os.path.realpath("link-y/..")'

This will print: /path/to/a
In other words: os.path.realpath('link-y/..') == a

That is, the link link-y has not been expanded to the
directory it points to before .. (go to parent
directory) has been applied to the path.

os.path.normpath() has the same problem.

This may be a potential security risk if one uses
realpath to check if a requested path is inside a
certain restricted subdirectory.

----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 17:45

Message:
Logged In: YES 
user_id=469548

I've created a patch for realpath
(http://python.org/sf/996627) and a doc patch for normpath
(http://python.org/sf/996626). There's a comment in
posixpath.py warning for this problem with normpath, and
it's been there since 1992, so I don't think we should go
around changing it now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990669&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 17:49:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 17:49:25 2004
Subject: [ python-Bugs-996627 ] realpath: resolve symlinks before
	normalizing (bug #990669)
Message-ID: <E1Bo2IT-0000b5-00@sc8-sf-web1.sourceforge.net>

Bugs item #996627, was opened at 2004-07-23 17:45
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996627&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: realpath: resolve symlinks before normalizing (bug #990669)

Initial Comment:
This patch fixes the problem described in
http://python.org/sf/990669 and adds tests for realpath.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 17:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996627&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 17:49:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 17:49:35 2004
Subject: [ python-Bugs-996626 ] normpath symlinks doc warning (bug #990669)
Message-ID: <E1Bo2Id-0004J3-00@sc8-sf-web4.sourceforge.net>

Bugs item #996626, was opened at 2004-07-23 17:45
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996626&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: normpath symlinks doc warning (bug #990669)

Initial Comment:
normpath may alter the meaning of a path if it contains
symbolic links. This has been documented in a comment
since 1992, but it should be in the library reference
as well.

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 17:49

Message:
Logged In: YES 
user_id=469548

This should have been filed as a patch, my apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996626&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 18:21:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 18:21:30 2004
Subject: [ python-Bugs-964929 ] Unicode String formatting does not correctly
	handle objects
Message-ID: <E1Bo2nV-0005V5-00@sc8-sf-web4.sourceforge.net>

Bugs item #964929, was opened at 2004-06-02 12:48
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964929&group_id=5470

Category: Unicode
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode String formatting does not correctly handle objects

Initial Comment:
I have a problem with the way '%s' is handled in
unicode strings when formatted. The Python Language
refrence states that a unicode serialisation of an
object should be in __unicode__, and I have seen python
break down if unicode data is returned in __str__.

The problem is that there does not appear to be a way
to interpolate the results from __unicode__ within a
string:

class EuroHolder:
    def __init__(self, price):
        self._price = price
    def __str__(self):
        return "%.02f euro" % self._price
    def __unicode__(self):
        return u"%.02f\u20ac" % self._price

>>> class EuroHolder:
...     def __init__(self, price):
...         self._price = price
...     def __str__(self):
...         return "%.02f euro" % self._price
...     def __unicode__(self):
...         return u"%.02f\u20ac" % self._price
... 
>>> e = EuroHolder(123.45)
>>> str(e)
'123.45 euro'
>>> unicode(e)
u'123.45\u20ac'
>>> "%s" % e
'123.45 euro'
>>> u"%s" % e #this is wrong
u'123.45 euro'
>>> u"%s" % unicode(e) # This is silly
u'123.45\u20ac'
>>> 

The first case is wrong, as I actually could cope with
unicode data in the string I was substituting into, and
I should be able to request the unicode data be put in.

The second case is silly, as the whole point of string
substion variables such as %s, %d and %f is to remove
the need for coercion on the right of the %.

Proposed solution #1:
Make %s in unicode string substitution automatically
check __unicode__() of the rvalue before trying
__str__(). This is the most logical thing to expect of
%s, if you insist on overloading it the way it
currently does when a unicode object in the rvalue will
ensure the result is unicode.

Proposed solution #2:
Make a new string conversion operator, such as %S or %U
which will explicitly call __unicode__() on the rvalue
even if the lvalue is a non-unicode string

Solution #2 has the advantage that it does not break
any previous behaviour of %s, and also allows for
explicit conversion to unicode of 8-bits string in the
lvalue.

I prefer solution #1 as I feel that the current
operation of %s is incorrect, and it's unliekly to
break much, whereas the "advantage" of converting 8-bit
strings in the lvalue to unicode which solution #2
advocates will just lead to encoding problems and
sloppy code.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 18:21

Message:
Logged In: YES 
user_id=38388

I've checked in the proposed solution:

Checking in Objects/unicodeobject.c;
/cvsroot/python/python/dist/src/Objects/unicodeobject.c,v 
<--  unicodeobject.c
new revision: 2.218; previous revision: 2.217


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:29

Message:
Logged In: YES 
user_id=38388

Good point.

I think the only change needed is to use PyObject_Unicode()
instead of PyObject_Str() in unicodeobject.c's
PyUnicode_Format(). This would then implement #1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964929&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 18:22:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 18:22:45 2004
Subject: [ python-Bugs-964929 ] Unicode String formatting does not correctly
	handle objects
Message-ID: <E1Bo2oi-0005Xb-00@sc8-sf-web4.sourceforge.net>

Bugs item #964929, was opened at 2004-06-02 12:48
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964929&group_id=5470

Category: Unicode
>Group: Python 2.4
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode String formatting does not correctly handle objects

Initial Comment:
I have a problem with the way '%s' is handled in
unicode strings when formatted. The Python Language
refrence states that a unicode serialisation of an
object should be in __unicode__, and I have seen python
break down if unicode data is returned in __str__.

The problem is that there does not appear to be a way
to interpolate the results from __unicode__ within a
string:

class EuroHolder:
    def __init__(self, price):
        self._price = price
    def __str__(self):
        return "%.02f euro" % self._price
    def __unicode__(self):
        return u"%.02f\u20ac" % self._price

>>> class EuroHolder:
...     def __init__(self, price):
...         self._price = price
...     def __str__(self):
...         return "%.02f euro" % self._price
...     def __unicode__(self):
...         return u"%.02f\u20ac" % self._price
... 
>>> e = EuroHolder(123.45)
>>> str(e)
'123.45 euro'
>>> unicode(e)
u'123.45\u20ac'
>>> "%s" % e
'123.45 euro'
>>> u"%s" % e #this is wrong
u'123.45 euro'
>>> u"%s" % unicode(e) # This is silly
u'123.45\u20ac'
>>> 

The first case is wrong, as I actually could cope with
unicode data in the string I was substituting into, and
I should be able to request the unicode data be put in.

The second case is silly, as the whole point of string
substion variables such as %s, %d and %f is to remove
the need for coercion on the right of the %.

Proposed solution #1:
Make %s in unicode string substitution automatically
check __unicode__() of the rvalue before trying
__str__(). This is the most logical thing to expect of
%s, if you insist on overloading it the way it
currently does when a unicode object in the rvalue will
ensure the result is unicode.

Proposed solution #2:
Make a new string conversion operator, such as %S or %U
which will explicitly call __unicode__() on the rvalue
even if the lvalue is a non-unicode string

Solution #2 has the advantage that it does not break
any previous behaviour of %s, and also allows for
explicit conversion to unicode of 8-bits string in the
lvalue.

I prefer solution #1 as I feel that the current
operation of %s is incorrect, and it's unliekly to
break much, whereas the "advantage" of converting 8-bit
strings in the lvalue to unicode which solution #2
advocates will just lead to encoding problems and
sloppy code.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 18:22

Message:
Logged In: YES 
user_id=38388

Note that this will no go into 2.3.x since it is a new
feature. Changing the scope to Python 2.4.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 18:21

Message:
Logged In: YES 
user_id=38388

I've checked in the proposed solution:

Checking in Objects/unicodeobject.c;
/cvsroot/python/python/dist/src/Objects/unicodeobject.c,v 
<--  unicodeobject.c
new revision: 2.218; previous revision: 2.217


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:29

Message:
Logged In: YES 
user_id=38388

Good point.

I think the only change needed is to use PyObject_Unicode()
instead of PyObject_Str() in unicodeobject.c's
PyUnicode_Format(). This would then implement #1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964929&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 18:36:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 18:36:17 2004
Subject: [ python-Bugs-964929 ] Unicode String formatting does not correctly
	handle objects
Message-ID: <E1Bo31m-0005Po-00@sc8-sf-web3.sourceforge.net>

Bugs item #964929, was opened at 2004-06-02 12:48
Message generated for change (Settings changed) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964929&group_id=5470

Category: Unicode
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Giles Antonio Radford (mewf)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode String formatting does not correctly handle objects

Initial Comment:
I have a problem with the way '%s' is handled in
unicode strings when formatted. The Python Language
refrence states that a unicode serialisation of an
object should be in __unicode__, and I have seen python
break down if unicode data is returned in __str__.

The problem is that there does not appear to be a way
to interpolate the results from __unicode__ within a
string:

class EuroHolder:
    def __init__(self, price):
        self._price = price
    def __str__(self):
        return "%.02f euro" % self._price
    def __unicode__(self):
        return u"%.02f\u20ac" % self._price

>>> class EuroHolder:
...     def __init__(self, price):
...         self._price = price
...     def __str__(self):
...         return "%.02f euro" % self._price
...     def __unicode__(self):
...         return u"%.02f\u20ac" % self._price
... 
>>> e = EuroHolder(123.45)
>>> str(e)
'123.45 euro'
>>> unicode(e)
u'123.45\u20ac'
>>> "%s" % e
'123.45 euro'
>>> u"%s" % e #this is wrong
u'123.45 euro'
>>> u"%s" % unicode(e) # This is silly
u'123.45\u20ac'
>>> 

The first case is wrong, as I actually could cope with
unicode data in the string I was substituting into, and
I should be able to request the unicode data be put in.

The second case is silly, as the whole point of string
substion variables such as %s, %d and %f is to remove
the need for coercion on the right of the %.

Proposed solution #1:
Make %s in unicode string substitution automatically
check __unicode__() of the rvalue before trying
__str__(). This is the most logical thing to expect of
%s, if you insist on overloading it the way it
currently does when a unicode object in the rvalue will
ensure the result is unicode.

Proposed solution #2:
Make a new string conversion operator, such as %S or %U
which will explicitly call __unicode__() on the rvalue
even if the lvalue is a non-unicode string

Solution #2 has the advantage that it does not break
any previous behaviour of %s, and also allows for
explicit conversion to unicode of 8-bits string in the
lvalue.

I prefer solution #1 as I feel that the current
operation of %s is incorrect, and it's unliekly to
break much, whereas the "advantage" of converting 8-bit
strings in the lvalue to unicode which solution #2
advocates will just lead to encoding problems and
sloppy code.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 18:22

Message:
Logged In: YES 
user_id=38388

Note that this will no go into 2.3.x since it is a new
feature. Changing the scope to Python 2.4.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 18:21

Message:
Logged In: YES 
user_id=38388

I've checked in the proposed solution:

Checking in Objects/unicodeobject.c;
/cvsroot/python/python/dist/src/Objects/unicodeobject.c,v 
<--  unicodeobject.c
new revision: 2.218; previous revision: 2.217


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 12:29

Message:
Logged In: YES 
user_id=38388

Good point.

I think the only change needed is to use PyObject_Unicode()
instead of PyObject_Str() in unicodeobject.c's
PyUnicode_Format(). This would then implement #1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=964929&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 20:41:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 20:41:19 2004
Subject: [ python-Bugs-996748 ] os.environ documentation should indicate
	unreliability
Message-ID: <E1Bo4yp-00080G-00@sc8-sf-web1.sourceforge.net>

Bugs item #996748, was opened at 2004-07-23 14:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Tibbetts (tibbetts)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ documentation should indicate unreliability

Initial Comment:
Looking at the documenation for the os module, nothing
in the documentation of os.environ would indicate that
it is unreliable. But then looking at os.putenv, we see
that os.environ will not reflect changes made to the
environment through other means.

To me, this makes os.environ much less useful. In fact,
it makes it somewhat harmful. I would argue for
deprecating it, or at least documenting this problem.

Thanks,
Richard


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470
From noreply at sourceforge.net  Fri Jul 23 21:20:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 23 21:20:58 2004
Subject: [ python-Bugs-996359 ] Bug somewhere in email Parser or
	PortableUnixMailbox
Message-ID: <E1Bo5b0-00014X-00@sc8-sf-web1.sourceforge.net>

Bugs item #996359, was opened at 2004-07-23 07:53
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996359&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: A.M. Kuchling (akuchling)
Summary: Bug somewhere in email Parser or PortableUnixMailbox

Initial Comment:
When run under Python 2.3 and fed a unix mbox file
on stdin, this script prints the lengths of the messages
in the file and their subjects on stdout:

import sys
import mailbox
import email.Parser

for msg in mailbox.PortableUnixMailbox(sys.stdin, 
email.Parser.Parser().parse):
    print len(str(msg)), msg["subject"]

If run using Python from CVS it prints out "38" as the
length of each message and "None" as the subject.
Something clearly changed between 2.3 and 2.4.
I've not had a chance to dig into the problem yet.
Am I using PortableUnixMailbox or email.Parser.Parser
in some unsupported and now broken way?

Assigning to Barry since he's the obvious email guru,
but anyone can feel free to jump in here.  This would
seem to be a fairly serious bug.

Skip


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 21:20

Message:
Logged In: YES 
user_id=469548

That was my patch, and it was my fault. I forgot to stick
the return calls in the read() and readline() functions. A
patch is unnecessary, I presume? 

This must be my dumbest mistake yet. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-23 16:22

Message:
Logged In: YES 
user_id=44345

Further investigation shows this simpler script demonstrates
the problem:

import sys
import mailbox

for msg in mailbox.PortableUnixMailbox(sys.stdin):
    print len(str(msg))

Looking at mailbox.py it appears v 1.42 is the culprit. 
Reverting to 1.41
solves the problem.  Reassigning to Andrew since he checked
in that
version.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996359&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 14:30:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 14:30:21 2004
Subject: [ python-Bugs-997050 ] ConfigParser behavior change
Message-ID: <E1BoLfN-0008Qi-00@sc8-sf-web2.sourceforge.net>

Bugs item #997050, was opened at 2004-07-24 08:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ConfigParser behavior change

Initial Comment:
ConfigParser.set() doesn't allow non-string arguments
for 'value' any
more.  This breaks Docutils code.  I submit that the
behavior should
not have been changed, rather that the documentation
needed updating.
I volunteer to undo the change and update the
documentation.

ConfigParser.py rev. 1.65 implements the fix detailed
in bug report
810843 (http://python.org/sf/810843):

    Fixed using methods (2) and (3): ConfigParser.set()
now checks
    that the value is some flavor of string, and raises
TypeError if
    it isn't.  This is documented behavior; regression
tests have been
    added.

"This is documented behavior": where was this behavior
documented
before the bug fix?  I couldn't find it.  If it wasn't
documented,
wouldn't method 4 (from the bug report, below) have
been more
appropriate?

    (4) Stating in the documentation that the raw parameter
    should be used when an option's value might not be of
    type string (this might be the intended usage, but it
    isn't made clear).

IOW, perhaps it wasn't a code bug but rather an
omission in the docs.
By adding the restriction and raising TypeError, it
breaks Docutils,
which subclasses ConfigParser.  If the string-only
restriction *was*
documented and I just missed it, I'll accept that the
Docutils code
was at fault (it's not the first time ;-) and rework
it.  But if that
restriction wasn't documented, I don't think
ConfigParser's behavior
should change.

See also
<http://article.gmane.org/gmane.text.docutils.devel/2073>.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 17:20:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 17:20:43 2004
Subject: [ python-Bugs-997100 ] optparse.py:668 triggers FutureWarning
Message-ID: <E1BoOKG-0007i2-00@sc8-sf-web4.sourceforge.net>

Bugs item #997100, was opened at 2004-07-24 09:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles (melicertes)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse.py:668 triggers FutureWarning

Initial Comment:
In Python 2.3.3, importing optparse triggers a
FutureWarning on line 668:

> /usr/local/lib/python2.3/optparse.py:668:
FutureWarning:                  
> %u/%o/%x/%X of negative int will return a signed
string in 
> Python 2.4 and up 
>   return ("<%s at 0x%x: %r>" 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 20:48:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 20:48:57 2004
Subject: [ python-Bugs-997166 ] What's New in 2.4: sorted(): doc bug?
Message-ID: <E1BoRZm-0004lg-00@sc8-sf-web4.sourceforge.net>

Bugs item #997166, was opened at 2004-07-24 11:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997166&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Dyck (jmdyck)
Assigned to: Nobody/Anonymous (nobody)
Summary: What's New in 2.4: sorted(): doc bug?

Initial Comment:
http://www.python.org/dev/doc/devel/whatsnew/node7.html
("What's New in Python 2.4": "Other Language Changes")
In the blurb for sorted(), it has:

>>> L = [9,7,8,3,2,4,1,6,5]
>>> [10+i for i in sorted(L)]       # usable in a list 
comprehension
[11, 12, 13, 14, 15, 16, 17, 18, 19]
>>> L = [9,7,8,3,2,4,1,6,5]         # original is left 
unchanged
[9,7,8,3,2,4,1,6,5]

I think the second-last line should just be
>>> L    # original is left unchanged

----

Also, in

>>> sorted('Monte Python')

it might be less distracting to use the 'standard' 
spelling "Monty".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997166&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 21:57:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 21:57:19 2004
Subject: [ python-Bugs-996359 ] Bug somewhere in email Parser or
	PortableUnixMailbox
Message-ID: <E1BoSdr-0002xE-00@sc8-sf-web2.sourceforge.net>

Bugs item #996359, was opened at 2004-07-23 00:53
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996359&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: Bug somewhere in email Parser or PortableUnixMailbox

Initial Comment:
When run under Python 2.3 and fed a unix mbox file
on stdin, this script prints the lengths of the messages
in the file and their subjects on stdout:

import sys
import mailbox
import email.Parser

for msg in mailbox.PortableUnixMailbox(sys.stdin, 
email.Parser.Parser().parse):
    print len(str(msg)), msg["subject"]

If run using Python from CVS it prints out "38" as the
length of each message and "None" as the subject.
Something clearly changed between 2.3 and 2.4.
I've not had a chance to dig into the problem yet.
Am I using PortableUnixMailbox or email.Parser.Parser
in some unsupported and now broken way?

Assigning to Barry since he's the obvious email guru,
but anyone can feel free to jump in here.  This would
seem to be a fairly serious bug.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-24 14:57

Message:
Logged In: YES 
user_id=44345

Perhaps it's your dumbest mistake yet, but I'm sure I've made dumber. 
;-)

Checked in mailbox.py as v1.43. Also added simple test case to 
test_mailbox.py v1.10.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-23 14:20

Message:
Logged In: YES 
user_id=469548

That was my patch, and it was my fault. I forgot to stick
the return calls in the read() and readline() functions. A
patch is unnecessary, I presume? 

This must be my dumbest mistake yet. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-23 09:22

Message:
Logged In: YES 
user_id=44345

Further investigation shows this simpler script demonstrates
the problem:

import sys
import mailbox

for msg in mailbox.PortableUnixMailbox(sys.stdin):
    print len(str(msg))

Looking at mailbox.py it appears v 1.42 is the culprit. 
Reverting to 1.41
solves the problem.  Reassigning to Andrew since he checked
in that
version.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996359&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 22:23:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 22:23:55 2004
Subject: [ python-Bugs-878453 ] optparse indents without respect to $COLUMNS
Message-ID: <E1BoT3g-0003fm-00@sc8-sf-web2.sourceforge.net>

Bugs item #878453, was opened at 2004-01-16 13:50
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878453&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Ian Bicking (ianbicking)
Assigned to: Greg Ward (gward)
Summary: optparse indents without respect to $COLUMNS

Initial Comment:
optparse should pay attention to the $COLUMNS
environmental variable if it is available. 
optparse.IndentedHelpFormatter.__init__ should take
None as the default for width, and do something like:

if width is None: width = os.environ.get('COLUMNS', 80)

Better if it's put in HelpFormatter, so that
IndentedHelpFormatter and TitledHelpFormatter both act
the same.

(Python 2.3.3, FreeBSD)


----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2004-07-24 16:23

Message:
Logged In: YES 
user_id=14422

OK, just checked in a fix in the Optik CVS:
  lib/help.py rev 1.13
  test/test_optik.py rev rev 1.29

Marking this bug fixed but still open, since it's not in
Python's CVS yet.  If I hustle, I should be able to get it
into Python 2.4...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878453&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 22:24:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 22:24:40 2004
Subject: [ python-Bugs-997100 ] optparse.py:668 triggers FutureWarning
Message-ID: <E1BoT4J-0003hM-00@sc8-sf-web2.sourceforge.net>

Bugs item #997100, was opened at 2004-07-24 11:20
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: Charles (melicertes)
>Assigned to: Greg Ward (gward)
Summary: optparse.py:668 triggers FutureWarning

Initial Comment:
In Python 2.3.3, importing optparse triggers a
FutureWarning on line 668:

> /usr/local/lib/python2.3/optparse.py:668:
FutureWarning:                  
> %u/%o/%x/%X of negative int will return a signed
string in 
> Python 2.4 and up 
>   return ("<%s at 0x%x: %r>" 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997100&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 22:25:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 22:25:45 2004
Subject: [ python-Bugs-878453 ] optparse indents without respect to $COLUMNS
Message-ID: <E1BoT5R-0003ix-00@sc8-sf-web2.sourceforge.net>

Bugs item #878453, was opened at 2004-01-16 13:50
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878453&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: Fixed
>Priority: 4
Submitted By: Ian Bicking (ianbicking)
Assigned to: Greg Ward (gward)
Summary: optparse indents without respect to $COLUMNS

Initial Comment:
optparse should pay attention to the $COLUMNS
environmental variable if it is available. 
optparse.IndentedHelpFormatter.__init__ should take
None as the default for width, and do something like:

if width is None: width = os.environ.get('COLUMNS', 80)

Better if it's put in HelpFormatter, so that
IndentedHelpFormatter and TitledHelpFormatter both act
the same.

(Python 2.3.3, FreeBSD)


----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2004-07-24 16:23

Message:
Logged In: YES 
user_id=14422

OK, just checked in a fix in the Optik CVS:
  lib/help.py rev 1.13
  test/test_optik.py rev rev 1.29

Marking this bug fixed but still open, since it's not in
Python's CVS yet.  If I hustle, I should be able to get it
into Python 2.4...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878453&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 22:25:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 22:25:53 2004
Subject: [ python-Bugs-996748 ] os.environ documentation should indicate
	unreliability
Message-ID: <E1BoT5Y-0007JS-00@sc8-sf-web4.sourceforge.net>

Bugs item #996748, was opened at 2004-07-23 13:41
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Tibbetts (tibbetts)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ documentation should indicate unreliability

Initial Comment:
Looking at the documenation for the os module, nothing
in the documentation of os.environ would indicate that
it is unreliable. But then looking at os.putenv, we see
that os.environ will not reflect changes made to the
environment through other means.

To me, this makes os.environ much less useful. In fact,
it makes it somewhat harmful. I would argue for
deprecating it, or at least documenting this problem.

Thanks,
Richard


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 15:25

Message:
Logged In: YES 
user_id=80475

FWIW, os.environ is reliable; it is putenv that is not doing
what you expect.

putenv() is there for updating the environment of
sub-processes. There doesn't appear to be a reliable cross
platform approach having any program update its own environment.

Look on ASPN for my recipe that shows an o.s. trick for
solving this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 22:26:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 22:26:45 2004
Subject: [ python-Bugs-997166 ] What's New in 2.4: sorted(): doc bug?
Message-ID: <E1BoT6N-0007Lq-00@sc8-sf-web4.sourceforge.net>

Bugs item #997166, was opened at 2004-07-24 13:48
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997166&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Dyck (jmdyck)
>Assigned to: A.M. Kuchling (akuchling)
Summary: What's New in 2.4: sorted(): doc bug?

Initial Comment:
http://www.python.org/dev/doc/devel/whatsnew/node7.html
("What's New in Python 2.4": "Other Language Changes")
In the blurb for sorted(), it has:

>>> L = [9,7,8,3,2,4,1,6,5]
>>> [10+i for i in sorted(L)]       # usable in a list 
comprehension
[11, 12, 13, 14, 15, 16, 17, 18, 19]
>>> L = [9,7,8,3,2,4,1,6,5]         # original is left 
unchanged
[9,7,8,3,2,4,1,6,5]

I think the second-last line should just be
>>> L    # original is left unchanged

----

Also, in

>>> sorted('Monte Python')

it might be less distracting to use the 'standard' 
spelling "Monty".


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997166&group_id=5470
From noreply at sourceforge.net  Sat Jul 24 22:27:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 24 22:27:56 2004
Subject: [ python-Bugs-996392 ] math and cmath docs don't specify radians
Message-ID: <E1BoT7X-0007OD-00@sc8-sf-web4.sourceforge.net>

Bugs item #996392, was opened at 2004-07-23 02:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: math and cmath docs don't specify radians

Initial Comment:
The math and cmath functions take their parameters in 
radians, but there is nothing stating this.

The closest is "The math module consists mostly of thin 
wrappers around the platform C math library functions.".

For starters, are we guaranteed that the platform math 
functions take radians?

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 15:27

Message:
Logged In: YES 
user_id=80475

Yes, the platform math lib will be in radians.

You're welcome to submit a clarifying doc patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 01:04:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 01:05:06 2004
Subject: [ python-Bugs-996392 ] math and cmath docs don't specify radians
Message-ID: <E1BoVZa-0003eA-00@sc8-sf-web4.sourceforge.net>

Bugs item #996392, was opened at 2004-07-23 03:18
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: math and cmath docs don't specify radians

Initial Comment:
The math and cmath functions take their parameters in 
radians, but there is nothing stating this.

The closest is "The math module consists mostly of thin 
wrappers around the platform C math library functions.".

For starters, are we guaranteed that the platform math 
functions take radians?

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-24 19:04

Message:
Logged In: YES 
user_id=31435

I checked in a major rewrite of the math module docs, as 
Doc/lib/libmath.tex revision 1.32.  This stuffed in "radians" as 
appropriate (among other things).

Note that the function docstrings already told the radiaion 
story; e.g.,

>>> print math.cos.__doc__
cos(x)

Return the cosine of x (measured in radians).
>>>

I didn't change the cmath docs, and don't intend to.  Anyone 
using complex "angles" who doesn't already know they're 
working in radians shouldn't be allowed to import cmath <0.6 
wink>.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 16:27

Message:
Logged In: YES 
user_id=80475

Yes, the platform math lib will be in radians.

You're welcome to submit a clarifying doc patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 05:59:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 05:59:56 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1BoaAz-00023L-00@sc8-sf-web3.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 23:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 12:23:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 12:23:55 2004
Subject: [ python-Bugs-990945 ] python24.dll installation problems
Message-ID: <E1BogAW-0001xp-00@sc8-sf-web3.sourceforge.net>

Bugs item #990945, was opened at 2004-07-14 17:32
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990945&group_id=5470

Category: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Martin v. L?wis (loewis)
Summary: python24.dll installation problems

Initial Comment:
It seems that the msi installer does not overwrite an
existing python24.dll in the system directory.
Also, removing the 2.4 installation doesn't seem to
remove the python24.dll from the system directory.

I've seen both in win2k and winXP.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 12:23

Message:
Logged In: YES 
user_id=21627

This is now fixed in msi.py 1.17. python24.dll is in a
separate component from msvcr71.dll; apparently, MSI cannot
uninstall a component if one of its files is still used
according to the SharedDlls reference counters.

I also put the version number of python24.dll into the File
table; this causes msiexec to overwrite an existing DLL if
the new one has a newer version. It still won't overwrite
the file if it has the same version, add REINSTALLMODE=emus
to force overwriting files with the same version.

See "File versioning rules" in MSDN for the exact procedures
wrt. overwriting existing files.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990945&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 15:56:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 15:56:54 2004
Subject: [ python-Bugs-997533 ] "disjunct" should be "disjoint"
Message-ID: <E1BojUg-0007zu-00@sc8-sf-web4.sourceforge.net>

Bugs item #997533, was opened at 2004-07-25 06:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997533&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Freeman (timfreeman)
Assigned to: Nobody/Anonymous (nobody)
Summary: "disjunct" should be "disjoint"

Initial Comment:
At http://www.python.org/doc/2.3.4/lib/built-in-funcs.html,
the first occurrence of "disjunct" should be "disjoint".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997533&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 19:34:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 19:34:37 2004
Subject: [ python-Bugs-924703 ] test_unicode_file fails on Win98SE
Message-ID: <E1BomtN-0000p0-00@sc8-sf-web2.sourceforge.net>

Bugs item #924703, was opened at 2004-03-28 03:48
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

Category: Unicode
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. L?wis (loewis)
Summary: test_unicode_file fails on Win98SE

Initial Comment:
In current CVS, test_unicode_file fails on Win98SE.  This 
has been going on for some time, actually.

ERROR: test_single_files (__main__.TestUnicodeFiles)

Traceback (most recent call last):
  File ".../lib/test/test_unicode_file.py", line 162, in 
test_single_files
    self._test_single(TESTFN_UNICODE)
  File ".../lib/test/test_unicode_file.py", line 136, in 
_test_single
    self._do_single(filename)
  File ".../lib/test/test_unicode_file.py", line 49, in 
_do_single
    new_base = unicodedata.normalize("NFD", new_base)
TypeError: normalized() argument 2 must be unicode, 
not str

At this point,

filename is TESTFN_UNICODE is
u'@test-\xe0\xf2'

os.path.abspath(filename) is
'C:\Code\python\PC\VC6\@test-\xe0\xf2'

new_base is
'@test-\xe0\xf2

So abspath() removed the "Unicodeness" of filename, 
and new_base is indeed not a Unicode string at this 
point.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 19:34

Message:
Logged In: YES 
user_id=21627

This apparently got fixed with test_unicode_file.py 1.15, by
converting the listdir result to unicode if necessary.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-17 18:11

Message:
Logged In: YES 
user_id=31435

Reopened, because the same test is still failing on Win98SE, 
but for a different reason.

The traceback is identical, except that it's now failing in the 
listcomp on the line following the line it used to fail on:

  File ".../lib/test/test_unicode_file.py", line 50, in _do_single
    file_list = [unicodedata.normalize("NFD", f) for f in file_list]
TypeError: normalized() argument 2 must be unicode, not str


filename is
u'@test-\xe0\xf2'

os.path.abspath(filename) is
u'C:\Code\python\PC\VC6\@test-\xe0\xf2'

new_base is
u'@test-a\u0300o\u0300'

The problem now is that the first name in file_list is
'CVS'

so

[unicodedata.normalize("NFD", f) for f in file_list]

is passing an 8-bit string to normalize().  Earlier code in the 
test *appears* to assume that if filename is Unicode, then 
os.listdir() will return a list of Unicode strings.  But file_list is a 
list of 153 8-bit strings on this box.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-06-15 20:50

Message:
Logged In: YES 
user_id=21627

This should be fixed with posixmodule.c 2.321.
Unfortunately, I cannot test it, because I don't have W9X.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-06-12 09:11

Message:
Logged In: YES 
user_id=80475

This is still failing.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-30 07:44

Message:
Logged In: YES 
user_id=31435

Just a guess:  the os.path functions are generally just string 
manipulation, and on Windows I sometimes import 
posixpath.py directly to do Unixish path manipulations.  So it's 
conceivable that someone (not me) on a non-Windows box 
imports ntpath directly to manipulate Windows paths.

In fact, I see that Fredrik's "Python Standard Library" book 
explicitly mentions this use case for importing ntpath directly.  
So maybe he actually did it -- once <wink>.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 07:25

Message:
Logged In: YES 
user_id=21627

I see. I'll look into changing _getfullpathname to return
Unicode output for Unicode input even if
unicode_file_names() is false.

However,  I do wonder what the purpose of _abspath then is:
On what system would it be used???

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-30 01:11

Message:
Logged In: YES 
user_id=31435

Nope, that can't help -- ntpath.py's _abspath doesn't exist 
on Win98SE (the "from nt import _getfullpathname" succeeds, 
so _abspath is never defined).  It's _getfullpathname() that's 
taking a Unicode input and returning a str output here.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:17

Message:
Logged In: YES 
user_id=21627

abspath(unicode) should return a Unicode path.

Does it help if _abspath (in ntpath.py) is changed to contain

            if not isabs(path):
                if isinstance(path, unicode): cwd = os.getcwdu()
                else: cwd = os.getcwd()
                path = join(cwd, path)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 19:52:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 19:52:27 2004
Subject: [ python-Bugs-996748 ] os.environ documentation should indicate
	unreliability
Message-ID: <E1BonAc-0005uM-00@sc8-sf-web4.sourceforge.net>

Bugs item #996748, was opened at 2004-07-23 20:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Tibbetts (tibbetts)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ documentation should indicate unreliability

Initial Comment:
Looking at the documenation for the os module, nothing
in the documentation of os.environ would indicate that
it is unreliable. But then looking at os.putenv, we see
that os.environ will not reflect changes made to the
environment through other means.

To me, this makes os.environ much less useful. In fact,
it makes it somewhat harmful. I would argue for
deprecating it, or at least documenting this problem.

Thanks,
Richard


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 19:52

Message:
Logged In: YES 
user_id=21627

rhettinger: why are you saying that putenv does not modify
the current environment? According to

http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html

it does modify the current environment; more specifically,
it modifies environ.

tibbetts, can you please explain what other means of
modifying the environment may occur? In a Python program,
the only way of modifying the environment is through
modifying os.environ, which calls putenv, or through
directly using putenv. If anything should be changed, we
should advise people not to call putenv directly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 22:25

Message:
Logged In: YES 
user_id=80475

FWIW, os.environ is reliable; it is putenv that is not doing
what you expect.

putenv() is there for updating the environment of
sub-processes. There doesn't appear to be a reliable cross
platform approach having any program update its own environment.

Look on ASPN for my recipe that shows an o.s. trick for
solving this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 20:06:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 20:06:41 2004
Subject: [ python-Bugs-996748 ] os.environ documentation should indicate
	unreliability
Message-ID: <E1BonOO-0001kO-00@sc8-sf-web2.sourceforge.net>

Bugs item #996748, was opened at 2004-07-23 20:41
Message generated for change (Comment added) made by sjoerd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Tibbetts (tibbetts)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ documentation should indicate unreliability

Initial Comment:
Looking at the documenation for the os module, nothing
in the documentation of os.environ would indicate that
it is unreliable. But then looking at os.putenv, we see
that os.environ will not reflect changes made to the
environment through other means.

To me, this makes os.environ much less useful. In fact,
it makes it somewhat harmful. I would argue for
deprecating it, or at least documenting this problem.

Thanks,
Richard


----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-25 20:06

Message:
Logged In: YES 
user_id=43607

On Linux:

>>> import os
>>> os.system('printenv x')
256
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.putenv('x', 'y')
>>> os.system('printenv x')
y
0
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.environ['x'] = 'z'
>>> os.system('printenv x')
z
0
>>> os.environ['x']
'z'
>>>

This seems clear enough: os.putenv modifies the environment
(look at the printenv output), but does not modify
os.environ.  Modifying os.environ also modifies the
environment for child processes.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 19:52

Message:
Logged In: YES 
user_id=21627

rhettinger: why are you saying that putenv does not modify
the current environment? According to

http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html

it does modify the current environment; more specifically,
it modifies environ.

tibbetts, can you please explain what other means of
modifying the environment may occur? In a Python program,
the only way of modifying the environment is through
modifying os.environ, which calls putenv, or through
directly using putenv. If anything should be changed, we
should advise people not to call putenv directly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 22:25

Message:
Logged In: YES 
user_id=80475

FWIW, os.environ is reliable; it is putenv that is not doing
what you expect.

putenv() is there for updating the environment of
sub-processes. There doesn't appear to be a reliable cross
platform approach having any program update its own environment.

Look on ASPN for my recipe that shows an o.s. trick for
solving this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 20:06:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 20:06:53 2004
Subject: [ python-Bugs-994101 ] urllib2: improper capitalization of headers
Message-ID: <E1BonOb-0006JY-00@sc8-sf-web4.sourceforge.net>

Bugs item #994101, was opened at 2004-07-19 22:22
Message generated for change (Comment added) made by jjlee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Sayre (franklinmint)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2: improper capitalization of headers

Initial Comment:
urllib2.py version 1.72 uses capitalize() on HTTP
header names. This results in headers like "User-agent"
instead of "User-Agent". This causes HTTP 400 errors on
some servers when the request has a body, because there
are two content length headers placed in the request:

"Content-Length" (inserted by httplib)
"Content-length" (inserted by
Request.add_unredirected_header)

The capitalization is incorrect, and httplib inserts
Content-Length anyway, so I'm not sure why urllib2 is
bothering.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2004-07-25 19:06

Message:
Logged In: YES 
user_id=261020

I've added a comment to 996159 which explains what's wrong 
and points to a new patch.


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-07-22 21:48

Message:
Logged In: YES 
user_id=469548

Patch is available at http://python.org/sf/996159.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 20:57:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 20:57:27 2004
Subject: [ python-Bugs-996748 ] os.environ documentation should indicate
	unreliability
Message-ID: <E1BooBW-0007fa-00@sc8-sf-web4.sourceforge.net>

Bugs item #996748, was opened at 2004-07-23 14:41
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Tibbetts (tibbetts)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ documentation should indicate unreliability

Initial Comment:
Looking at the documenation for the os module, nothing
in the documentation of os.environ would indicate that
it is unreliable. But then looking at os.putenv, we see
that os.environ will not reflect changes made to the
environment through other means.

To me, this makes os.environ much less useful. In fact,
it makes it somewhat harmful. I would argue for
deprecating it, or at least documenting this problem.

Thanks,
Richard


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-25 14:57

Message:
Logged In: YES 
user_id=31435

Martin, to judge from what Raymond's recipe does, by "its 
own environment" he means the environment of the parent 
process:  his recipe uses the Windows-specific quirk that 
a .bat script *can* change its invoker's (parent process's) 
environment (under Unixy shells you use a "source" command 
to get this effect).

Sjoerd, your example works the same way under Windows:

>>> import os
>>> os.system('SET X')
Environment variable X not defined
1
>>> os.environ['X']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python23\lib\os.py", line 417, in __getitem__
    return self.data[key.upper()]
KeyError: 'X'
>>> os.putenv('X', 'Y')
>>> os.system('SET X')
X=Y
0
>>> os.environ['X']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python23\lib\os.py", line 417, in __getitem__
    return self.data[key.upper()]
KeyError: 'X'
>>> os.environ['X'] = 'Z'
>>> os.system('SET X')
X=Z
0
>>> os.environ['X']
'Z'
>>>

All, what's missing in the docs is a statement that os.environ 
captures the state of the environment at a particular point in 
time, so that os.environ[key] doesn't *necessarily* reflect 
the current binding of key in the OS's notion of environment.  
I'd add that info, except I'm not exactly sure at which 
specific point in time we capture it (it's when we initialize 
posixmodule.c, but I'm not sure when that happens).

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-25 14:06

Message:
Logged In: YES 
user_id=43607

On Linux:

>>> import os
>>> os.system('printenv x')
256
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.putenv('x', 'y')
>>> os.system('printenv x')
y
0
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.environ['x'] = 'z'
>>> os.system('printenv x')
z
0
>>> os.environ['x']
'z'
>>>

This seems clear enough: os.putenv modifies the environment
(look at the printenv output), but does not modify
os.environ.  Modifying os.environ also modifies the
environment for child processes.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 13:52

Message:
Logged In: YES 
user_id=21627

rhettinger: why are you saying that putenv does not modify
the current environment? According to

http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html

it does modify the current environment; more specifically,
it modifies environ.

tibbetts, can you please explain what other means of
modifying the environment may occur? In a Python program,
the only way of modifying the environment is through
modifying os.environ, which calls putenv, or through
directly using putenv. If anything should be changed, we
should advise people not to call putenv directly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 16:25

Message:
Logged In: YES 
user_id=80475

FWIW, os.environ is reliable; it is putenv that is not doing
what you expect.

putenv() is there for updating the environment of
sub-processes. There doesn't appear to be a reliable cross
platform approach having any program update its own environment.

Look on ASPN for my recipe that shows an o.s. trick for
solving this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470
From noreply at sourceforge.net  Sun Jul 25 22:53:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Jul 25 22:53:15 2004
Subject: [ python-Bugs-996748 ] os.environ documentation should indicate
	unreliability
Message-ID: <E1BopzY-0002U5-00@sc8-sf-web4.sourceforge.net>

Bugs item #996748, was opened at 2004-07-23 20:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Tibbetts (tibbetts)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ documentation should indicate unreliability

Initial Comment:
Looking at the documenation for the os module, nothing
in the documentation of os.environ would indicate that
it is unreliable. But then looking at os.putenv, we see
that os.environ will not reflect changes made to the
environment through other means.

To me, this makes os.environ much less useful. In fact,
it makes it somewhat harmful. I would argue for
deprecating it, or at least documenting this problem.

Thanks,
Richard


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 22:53

Message:
Logged In: YES 
user_id=21627

That's easy to answer: posixinit/ntinit is called when the
module posix/nt is first imported.

Now, one may wonder when that happens for the first time.
That depends very much on the application, but typically
posix is imported first through os, and os is first imported
through site.py, right after sys is imported.

Tim, with that information, can you add text to the docs?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-25 20:57

Message:
Logged In: YES 
user_id=31435

Martin, to judge from what Raymond's recipe does, by "its 
own environment" he means the environment of the parent 
process:  his recipe uses the Windows-specific quirk that 
a .bat script *can* change its invoker's (parent process's) 
environment (under Unixy shells you use a "source" command 
to get this effect).

Sjoerd, your example works the same way under Windows:

>>> import os
>>> os.system('SET X')
Environment variable X not defined
1
>>> os.environ['X']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python23\lib\os.py", line 417, in __getitem__
    return self.data[key.upper()]
KeyError: 'X'
>>> os.putenv('X', 'Y')
>>> os.system('SET X')
X=Y
0
>>> os.environ['X']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python23\lib\os.py", line 417, in __getitem__
    return self.data[key.upper()]
KeyError: 'X'
>>> os.environ['X'] = 'Z'
>>> os.system('SET X')
X=Z
0
>>> os.environ['X']
'Z'
>>>

All, what's missing in the docs is a statement that os.environ 
captures the state of the environment at a particular point in 
time, so that os.environ[key] doesn't *necessarily* reflect 
the current binding of key in the OS's notion of environment.  
I'd add that info, except I'm not exactly sure at which 
specific point in time we capture it (it's when we initialize 
posixmodule.c, but I'm not sure when that happens).

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-25 20:06

Message:
Logged In: YES 
user_id=43607

On Linux:

>>> import os
>>> os.system('printenv x')
256
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.putenv('x', 'y')
>>> os.system('printenv x')
y
0
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.environ['x'] = 'z'
>>> os.system('printenv x')
z
0
>>> os.environ['x']
'z'
>>>

This seems clear enough: os.putenv modifies the environment
(look at the printenv output), but does not modify
os.environ.  Modifying os.environ also modifies the
environment for child processes.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 19:52

Message:
Logged In: YES 
user_id=21627

rhettinger: why are you saying that putenv does not modify
the current environment? According to

http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html

it does modify the current environment; more specifically,
it modifies environ.

tibbetts, can you please explain what other means of
modifying the environment may occur? In a Python program,
the only way of modifying the environment is through
modifying os.environ, which calls putenv, or through
directly using putenv. If anything should be changed, we
should advise people not to call putenv directly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 22:25

Message:
Logged In: YES 
user_id=80475

FWIW, os.environ is reliable; it is putenv that is not doing
what you expect.

putenv() is there for updating the environment of
sub-processes. There doesn't appear to be a reliable cross
platform approach having any program update its own environment.

Look on ASPN for my recipe that shows an o.s. trick for
solving this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 00:21:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 00:21:41 2004
Subject: [ python-Bugs-997726 ] dircache fix;
	raise like os.listdir, plus optimization
Message-ID: <E1BorNC-0002mG-00@sc8-sf-web1.sourceforge.net>

Bugs item #997726, was opened at 2004-07-25 22:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997726&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl Henrik Holth Lunde (chlunde)
Assigned to: Nobody/Anonymous (nobody)
Summary: dircache fix; raise like os.listdir, plus optimization

Initial Comment:
I think it would be better if dircache.listdir acts
like os.listdir on missing 
directories; raise os.error

Additionally, I rewrote the logic so it's about 15%
faster.  If you remove 
the outer try-except-block which purges the cache for a
folder on a 
miss it's 30% faster. This makes if five times as fast
as os.listdir (with
my program).

Not sure if anybody cares about the speed, the thing I
was surprised
about was that dircache wasn't a drop-in replacement
for listdir.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997726&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 02:27:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 02:27:31 2004
Subject: [ python-Bugs-996748 ] os.environ documentation should indicate
	unreliability
Message-ID: <E1BotKv-0003Dl-00@sc8-sf-web2.sourceforge.net>

Bugs item #996748, was opened at 2004-07-23 14:41
Message generated for change (Comment added) made by tibbetts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Tibbetts (tibbetts)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.environ documentation should indicate unreliability

Initial Comment:
Looking at the documenation for the os module, nothing
in the documentation of os.environ would indicate that
it is unreliable. But then looking at os.putenv, we see
that os.environ will not reflect changes made to the
environment through other means.

To me, this makes os.environ much less useful. In fact,
it makes it somewhat harmful. I would argue for
deprecating it, or at least documenting this problem.

Thanks,
Richard


----------------------------------------------------------------------

>Comment By: Richard Tibbetts (tibbetts)
Date: 2004-07-25 20:27

Message:
Logged In: YES 
user_id=18317

It seems to me that one would reasonably expect the
os.environ map to reflect the current state of the
environment, that it would be identical to using putenv/setenv.

I think it is very important that it either be
removed/deprecated in favor of people using interfaces they
are likely to understand (putenv, getenv), or that at
minimum it be very well documented.

Just a note from the lowly user.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 16:53

Message:
Logged In: YES 
user_id=21627

That's easy to answer: posixinit/ntinit is called when the
module posix/nt is first imported.

Now, one may wonder when that happens for the first time.
That depends very much on the application, but typically
posix is imported first through os, and os is first imported
through site.py, right after sys is imported.

Tim, with that information, can you add text to the docs?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-25 14:57

Message:
Logged In: YES 
user_id=31435

Martin, to judge from what Raymond's recipe does, by "its 
own environment" he means the environment of the parent 
process:  his recipe uses the Windows-specific quirk that 
a .bat script *can* change its invoker's (parent process's) 
environment (under Unixy shells you use a "source" command 
to get this effect).

Sjoerd, your example works the same way under Windows:

>>> import os
>>> os.system('SET X')
Environment variable X not defined
1
>>> os.environ['X']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python23\lib\os.py", line 417, in __getitem__
    return self.data[key.upper()]
KeyError: 'X'
>>> os.putenv('X', 'Y')
>>> os.system('SET X')
X=Y
0
>>> os.environ['X']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python23\lib\os.py", line 417, in __getitem__
    return self.data[key.upper()]
KeyError: 'X'
>>> os.environ['X'] = 'Z'
>>> os.system('SET X')
X=Z
0
>>> os.environ['X']
'Z'
>>>

All, what's missing in the docs is a statement that os.environ 
captures the state of the environment at a particular point in 
time, so that os.environ[key] doesn't *necessarily* reflect 
the current binding of key in the OS's notion of environment.  
I'd add that info, except I'm not exactly sure at which 
specific point in time we capture it (it's when we initialize 
posixmodule.c, but I'm not sure when that happens).

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-25 14:06

Message:
Logged In: YES 
user_id=43607

On Linux:

>>> import os
>>> os.system('printenv x')
256
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.putenv('x', 'y')
>>> os.system('printenv x')
y
0
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.environ['x'] = 'z'
>>> os.system('printenv x')
z
0
>>> os.environ['x']
'z'
>>>

This seems clear enough: os.putenv modifies the environment
(look at the printenv output), but does not modify
os.environ.  Modifying os.environ also modifies the
environment for child processes.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 13:52

Message:
Logged In: YES 
user_id=21627

rhettinger: why are you saying that putenv does not modify
the current environment? According to

http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html

it does modify the current environment; more specifically,
it modifies environ.

tibbetts, can you please explain what other means of
modifying the environment may occur? In a Python program,
the only way of modifying the environment is through
modifying os.environ, which calls putenv, or through
directly using putenv. If anything should be changed, we
should advise people not to call putenv directly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 16:25

Message:
Logged In: YES 
user_id=80475

FWIW, os.environ is reliable; it is putenv that is not doing
what you expect.

putenv() is there for updating the environment of
sub-processes. There doesn't appear to be a reliable cross
platform approach having any program update its own environment.

Look on ASPN for my recipe that shows an o.s. trick for
solving this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 02:50:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 02:50:43 2004
Subject: [ python-Bugs-996748 ] os.environ documentation should indicate
	unreliability
Message-ID: <E1BothK-00060c-00@sc8-sf-web1.sourceforge.net>

Bugs item #996748, was opened at 2004-07-23 14:41
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470

>Category: Documentation
>Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Tibbetts (tibbetts)
>Assigned to: Tim Peters (tim_one)
Summary: os.environ documentation should indicate unreliability

Initial Comment:
Looking at the documenation for the os module, nothing
in the documentation of os.environ would indicate that
it is unreliable. But then looking at os.putenv, we see
that os.environ will not reflect changes made to the
environment through other means.

To me, this makes os.environ much less useful. In fact,
it makes it somewhat harmful. I would argue for
deprecating it, or at least documenting this problem.

Thanks,
Richard


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-25 20:50

Message:
Logged In: YES 
user_id=31435

Closed with a doc patch, Doc/lib/libos.tex revision 1.140.

tibbetts, I don't know what use case you have in mind, and 
you didn't respond to Martin's request to clarify.  I can tell 
you that in more than a decade of using Python, I've never 
heard of anyone getting into any trouble using os.environ, 
except for the irrelevant (wrt what you're saying) problem 
than C putenv() leaks memory on some platforms.

We're certainly not going to deprecate this useful feature, 
and you've made no case here for complicating and slowing it 
by crawling over the OS environment structures each time a 
new query is made (getenv() is slo*, and the relatively 
greater speed of an os.environ lookup (typically constant-
time regardless of the number of environment keys) is 
important to some Python programs).

----------------------------------------------------------------------

Comment By: Richard Tibbetts (tibbetts)
Date: 2004-07-25 20:27

Message:
Logged In: YES 
user_id=18317

It seems to me that one would reasonably expect the
os.environ map to reflect the current state of the
environment, that it would be identical to using putenv/setenv.

I think it is very important that it either be
removed/deprecated in favor of people using interfaces they
are likely to understand (putenv, getenv), or that at
minimum it be very well documented.

Just a note from the lowly user.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 16:53

Message:
Logged In: YES 
user_id=21627

That's easy to answer: posixinit/ntinit is called when the
module posix/nt is first imported.

Now, one may wonder when that happens for the first time.
That depends very much on the application, but typically
posix is imported first through os, and os is first imported
through site.py, right after sys is imported.

Tim, with that information, can you add text to the docs?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-25 14:57

Message:
Logged In: YES 
user_id=31435

Martin, to judge from what Raymond's recipe does, by "its 
own environment" he means the environment of the parent 
process:  his recipe uses the Windows-specific quirk that 
a .bat script *can* change its invoker's (parent process's) 
environment (under Unixy shells you use a "source" command 
to get this effect).

Sjoerd, your example works the same way under Windows:

>>> import os
>>> os.system('SET X')
Environment variable X not defined
1
>>> os.environ['X']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python23\lib\os.py", line 417, in __getitem__
    return self.data[key.upper()]
KeyError: 'X'
>>> os.putenv('X', 'Y')
>>> os.system('SET X')
X=Y
0
>>> os.environ['X']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\python23\lib\os.py", line 417, in __getitem__
    return self.data[key.upper()]
KeyError: 'X'
>>> os.environ['X'] = 'Z'
>>> os.system('SET X')
X=Z
0
>>> os.environ['X']
'Z'
>>>

All, what's missing in the docs is a statement that os.environ 
captures the state of the environment at a particular point in 
time, so that os.environ[key] doesn't *necessarily* reflect 
the current binding of key in the OS's notion of environment.  
I'd add that info, except I'm not exactly sure at which 
specific point in time we capture it (it's when we initialize 
posixmodule.c, but I'm not sure when that happens).

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-07-25 14:06

Message:
Logged In: YES 
user_id=43607

On Linux:

>>> import os
>>> os.system('printenv x')
256
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.putenv('x', 'y')
>>> os.system('printenv x')
y
0
>>> os.environ['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/home/sjoerd/src/python/build.linux/../Lib/UserDict.py",
line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'x'
>>> os.environ['x'] = 'z'
>>> os.system('printenv x')
z
0
>>> os.environ['x']
'z'
>>>

This seems clear enough: os.putenv modifies the environment
(look at the printenv output), but does not modify
os.environ.  Modifying os.environ also modifies the
environment for child processes.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-07-25 13:52

Message:
Logged In: YES 
user_id=21627

rhettinger: why are you saying that putenv does not modify
the current environment? According to

http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html

it does modify the current environment; more specifically,
it modifies environ.

tibbetts, can you please explain what other means of
modifying the environment may occur? In a Python program,
the only way of modifying the environment is through
modifying os.environ, which calls putenv, or through
directly using putenv. If anything should be changed, we
should advise people not to call putenv directly.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-07-24 16:25

Message:
Logged In: YES 
user_id=80475

FWIW, os.environ is reliable; it is putenv that is not doing
what you expect.

putenv() is there for updating the environment of
sub-processes. There doesn't appear to be a reliable cross
platform approach having any program update its own environment.

Look on ASPN for my recipe that shows an o.s. trick for
solving this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996748&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 03:36:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 03:36:25 2004
Subject: [ python-Bugs-997768 ] LC_CTYPE locale and strings
Message-ID: <E1BouPd-0000bz-00@sc8-sf-web4.sourceforge.net>

Bugs item #997768, was opened at 2004-07-26 04:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997768&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pekka Pessi (ppessi)
Assigned to: Nobody/Anonymous (nobody)
Summary: LC_CTYPE locale and strings

Initial Comment:
It would be nice to get access to complete
locale-specific ctype information:

iscntrl()
isgraph()
isprint()
ispunct()

Also, the string.uppercase and string.lowercase depend
on LC_CTYPE locale. The string module has two other
members that could depend on LC_CTYPE,
string.punctuation and string.printable.

The current docs (in
http://www.python.org/doc/2.3.4/lib/module-string.html)
on string.printable is misleading, as string.printable
is not changed after LC_CTYPE locale changes, and it is
always
printable = digits + ascii_letters + punctuation +
whitespace

My approach is to create string.printable and
string.punctuation based on locale information, just
like string.uppercase and string.lowercase is done, and
add string.ascii_punctuation and string.ascii_printable
for the C locale values.

Patch containing proposed changes in stringobject,
string and _locale modules attached. No tests nor
changes to the docs, sorry.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997768&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 04:39:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 04:39:48 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1BovOv-00004r-00@sc8-sf-web1.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 20:59
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 19:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 06:45:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 06:45:40 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1BoxMl-0004wk-00@sc8-sf-web4.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 23:59
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-26 00:45

Message:
Logged In: YES 
user_id=31435

JP, can you define which nonsense values "are needed"?  We 
can't go back to allowing garbage everywhere, because doing 
so did cause crashes in platform C libraries.

The only thing it complains about in the specific example you 
gave is the middle 0.  I agree that one is irritating, and is due 
to Python inexplicably saying that tm_yday must be in 1 .. 
366 (instead of C's 0 .. 365) -- so Python subtracts one from 
the middle 0, giving a -1 that we can't afford to pass on to 
the C library.

If the only thing you really need is to allow a 0 for tm_yday, 
perhaps that could be allowed without whining.  0 is fine for 
tm_wday already, and for tm_isdst.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 22:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 07:25:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 07:25:41 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1BoxzV-0007Jw-00@sc8-sf-web3.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 23:59
Message generated for change (Comment added) made by kuran
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

>Comment By: Jp Calderone (kuran)
Date: 2004-07-26 01:25

Message:
Logged In: YES 
user_id=366566

The more I think about it the more I want to suggest that
strftime just be implemented in Python so that garbage
values that are never required can be accepted, safe in the
knowledge that they won't be used by the implementation. 
I'm not sure how feasible this is.  I know strptime is now
provided by Python and not the underlying library, so it
seems at least in the ballpark of plausibility.

On the other hand, looking more closely at what my
requirements really are, it seems that the input to
strftime() is actually coming from rfc822.parsedate_tz(),
which builds up a tuple containing all the interesting
values, and uses 0s for the nonsense ones.

Would a patch for parsedate_tz() (and similarly behaving
functions, I suppose, though I can't think of any off the
top of my head) to generate values acceptable to strftime()
be more acceptable?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 00:45

Message:
Logged In: YES 
user_id=31435

JP, can you define which nonsense values "are needed"?  We 
can't go back to allowing garbage everywhere, because doing 
so did cause crashes in platform C libraries.

The only thing it complains about in the specific example you 
gave is the middle 0.  I agree that one is irritating, and is due 
to Python inexplicably saying that tm_yday must be in 1 .. 
366 (instead of C's 0 .. 365) -- so Python subtracts one from 
the middle 0, giving a -1 that we can't afford to pass on to 
the C library.

If the only thing you really need is to allow a 0 for tm_yday, 
perhaps that could be allowed without whining.  0 is fine for 
tm_wday already, and for tm_isdst.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 22:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 11:39:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 11:39:42 2004
Subject: [ python-Bugs-997912 ] Enclosing Scope missing from namespace in
	Tutorial
Message-ID: <E1Bp1xK-00068e-00@sc8-sf-web4.sourceforge.net>

Bugs item #997912, was opened at 2004-07-26 05:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997912&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian vdB (brianvanden)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enclosing Scope missing from namespace in Tutorial

Initial Comment:
In the docs to Python 2.3.4 (#53, May 25 2004,
21:17:02), Section 4.6 of the Python Tutorial says:

The execution of a function introduces a new symbol
table used for the local variables of the function.
More precisely, all variable assignments in a function
store the value in the local symbol table; whereas
variable 
references first look in the local symbol table, then
in the global symbol table, and then in the table of
built-in names. Thus, global variables cannot be
directly assigned a value within a function (unless
named in a
 global statement), although they may be referenced. 

This doesn't make it clear that in the following sort
of case, the nested def can 'see' the varriables in the
topmost function:

>>> spam = 1
>>> def foo():
	spam = 2
	ham = 3
	def bar():
		print spam, ham
	bar()

	
>>> foo()
2 3

I suggest the following ammendment:

. . . whereas variable references first look in the
local symbol table, then in the local scope of the
enclosing function defs (if any), then in the global
symbol table, . . .

Thanks,

Brian vdB

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997912&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 13:23:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 13:23:43 2004
Subject: [ python-Bugs-756104 ] Calling socket.recv() with a large number
	breaks
Message-ID: <E1Bp3Zr-0003Qm-00@sc8-sf-web3.sourceforge.net>

Bugs item #756104, was opened at 2003-06-18 00:25
Message generated for change (Comment added) made by potterru
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex R.M. Turner (plexq)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling socket.recv() with a large number breaks

Initial Comment:
I have a backup script that calls socket.recv() passing
the amount of data that is left to get for a given file
as the argument.  For very large files (I have one here
that is 1.9Gig) it seems to break horribly after
receiving about 130Meg.  I have tried to track it down
precisely with basic debugging (putting in print
statements in the python code) but it just seams to
freak out around the 130meg mark, and it just doesn't
make sense.  If I change the argument passed to recv to
32767 it works just fine.  I have attatched the loop
that reads data from the socket (In a working state,
the bad code is commented out).

----------------------------------------------------------------------

Comment By: Igor E. Poteryaev (potterru)
Date: 2004-07-26 17:23

Message:
Logged In: YES 
user_id=48596

It looks like bug in module socket.py in _fileobject.read method. 
... 
while True: 
&nbsp;&nbsp;&nbsp;&nbsp;left = size - buf_len 
&nbsp;&nbsp;&nbsp;&nbsp;recv_size = max(self._rbufsize, left) 
&nbsp;&nbsp;&nbsp;&nbsp;data = self._sock.recv(recv_size) 
 
This code should read not more than *left* or *buffer size* 
 
So, it should be min instead of max ! 
 
Should I file a bug/patch for this ? 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-19 00:51

Message:
Logged In: YES 
user_id=31435

I assume you're running on Linux.  Python's implementation of 
recv asks the platform malloc for a buffer of the size 
requested, and raises an exception if malloc returns NULL.  
Unfortunately, malloc on Linux has a nasty habit of returning 
non-NULL even if there's no chance you can actually use the 
amount of memory requested.  There's really nothing Python 
can do about that.

So back to Jeremy's comment:  try the same thing in C.  If 
you get ridiculous behavior there too, it's a platform C/OS 
bug, and Python won't be able to hide it from you.

----------------------------------------------------------------------

Comment By: Alex R.M. Turner (plexq)
Date: 2003-06-19 00:22

Message:
Logged In: YES 
user_id=60034

That as maybe - it might be worth putting a suggested
maximum in the docs.  However I would say that given that an
IPv6 packet could be as large as 2Gig, it's not unreasonable
to ask for a packet as large as 1 Gig.  Wether the problem
is in glibc or python I don't know, although it seems that
asking for a buffer of 1.3 Gig in size, and passing that to
recv() would be odd behaviour on a current system in C given
that most systems couldn't allocate that much memory to a
buffer ;).  I have written fairly extensive socket code in
C/C++ before, and I never used anything larger than 65536
for the obvious reason that you can't receive anything
bigger than that in IPv4 (and most NICs can't handle
anything that big either).  I figured it would be
interesting to see what happened :).  I have a penchant for
being the only person in history to do quite a few things
apparently!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-18 22:29

Message:
Logged In: YES 
user_id=31435

BTW, if you're new to socket programming, do read Python's 
socket programming HOWTO:

http://www.amk.ca/python/howto/sockets/

I expect you're the only person in history to try passing such 
a large value to recv() -- even if it worked, you'd almost 
certainly run out of memory trying to allocate buffer space for 
1.9GB.  sockets are a low-level facility, and it's common to 
pass a relatively small power of 2 (for best match with 
hardware and network realities).

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 22:02

Message:
Logged In: YES 
user_id=31392

What happens when you write a C program that does the same
thing?  I expect you'll see similar problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 14:13:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 14:13:54 2004
Subject: [ python-Bugs-998001 ] bsddb has default flag of c, not r
Message-ID: <E1Bp4MZ-0008Dc-00@sc8-sf-web2.sourceforge.net>

Bugs item #998001, was opened at 2004-07-26 12:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998001&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: kim bruning (kimbruning)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb has default flag of c, not r

Initial Comment:
python 2.3.3 has a discrepancy with the documentation
at http://docs.python.org/lib/module-bsddb.htm

In section:
> 7.13 bsddb -- Interface to Berkeley DB library

for hashopen, btopen and rnopen, the documentation
states that:

> The optional flag identifies the mode used to open
the file. It >may be "r" (read only, default)

It turns out that 'r' is in fact not the default option
for any of
these 3 in Python 2.3.3.
The default option for the flag parameter turns out to
be 'c'. I had
some trouble with using the bsddb module in conjunction
with make, and finally resorted to reading the source
code to find out what was wrong.

The actual source code has:

def hashopen(file, flag='c', mode=0666, pgsize=None,
ffactor=None, nelem=None,
            cachesize=None, lorder=None, hflags=0):

def btopen(file, flag='c', mode=0666,
            btflags=0, cachesize=None, maxkeypage=None,
minkeypage=None,
            pgsize=None, lorder=None):

def rnopen(file, flag='c', mode=0666,
            rnflags=0, cachesize=None, pgsize=None,
lorder=None,
            rlen=None, delim=None, source=None, pad=None):


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998001&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 16:04:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 16:04:07 2004
Subject: [ python-Bugs-998066 ] typo in documentation
Message-ID: <E1Bp65F-0004iN-00@sc8-sf-web2.sourceforge.net>

Bugs item #998066, was opened at 2004-07-26 09:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998066&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Chen (chen23)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in documentation

Initial Comment:
on the page:

http://www.python.org/doc/2.3.4/lib/module-popen2.html

it lists os.popen4 return as:

Returns the file objects (child_stdout_and_stderr, child_stdin)

in practice it would appear to be (Solaris):

Returns the file objects (child_stdin,child_stdout_and_stderr)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998066&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 16:06:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 16:06:20 2004
Subject: [ python-Bugs-998066 ] typo in os.popen4 documentation
Message-ID: <E1Bp67L-0004ow-00@sc8-sf-web2.sourceforge.net>

Bugs item #998066, was opened at 2004-07-26 09:04
Message generated for change (Settings changed) made by chen23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998066&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Chen (chen23)
Assigned to: Nobody/Anonymous (nobody)
>Summary: typo in os.popen4 documentation

Initial Comment:
on the page:

http://www.python.org/doc/2.3.4/lib/module-popen2.html

it lists os.popen4 return as:

Returns the file objects (child_stdout_and_stderr, child_stdin)

in practice it would appear to be (Solaris):

Returns the file objects (child_stdin,child_stdout_and_stderr)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998066&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 17:30:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 17:30:22 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1Bp7Qe-0003Pq-00@sc8-sf-web1.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 23:59
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: Jp Calderone (kuran)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-26 11:30

Message:
Logged In: YES 
user_id=31435

Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste 
duplicate bug in email._parseaddr.parsedate_tz().  Assigning 
this report to Barry hoping he'll fix those, and boosted the 
priority:  Barry, 0 is an illegal value for tm_yday in a Python 
time tuple.  Python 2.4 cares about this.  You want 1 there 
instead.  I'd do it, but am not familiar with the test suites for 
those modules.

C99's strftime is a large and complicated function, so it would 
take a peculiar kind of masochism for someone to want to 
rewrite it in Python.  Brett did the Python strptime, but he's 
older now, and has presumably learned better <wink>.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2004-07-26 01:25

Message:
Logged In: YES 
user_id=366566

The more I think about it the more I want to suggest that
strftime just be implemented in Python so that garbage
values that are never required can be accepted, safe in the
knowledge that they won't be used by the implementation. 
I'm not sure how feasible this is.  I know strptime is now
provided by Python and not the underlying library, so it
seems at least in the ballpark of plausibility.

On the other hand, looking more closely at what my
requirements really are, it seems that the input to
strftime() is actually coming from rfc822.parsedate_tz(),
which builds up a tuple containing all the interesting
values, and uses 0s for the nonsense ones.

Would a patch for parsedate_tz() (and similarly behaving
functions, I suppose, though I can't think of any off the
top of my head) to generate values acceptable to strftime()
be more acceptable?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 00:45

Message:
Logged In: YES 
user_id=31435

JP, can you define which nonsense values "are needed"?  We 
can't go back to allowing garbage everywhere, because doing 
so did cause crashes in platform C libraries.

The only thing it complains about in the specific example you 
gave is the middle 0.  I agree that one is irritating, and is due 
to Python inexplicably saying that tm_yday must be in 1 .. 
366 (instead of C's 0 .. 365) -- so Python subtracts one from 
the middle 0, giving a -1 that we can't afford to pass on to 
the C library.

If the only thing you really need is to allow a 0 for tm_yday, 
perhaps that could be allowed without whining.  0 is fine for 
tm_wday already, and for tm_isdst.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 22:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 19:38:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 19:38:45 2004
Subject: [ python-Bugs-998170 ] Typo in
	http://docs.python.org/lib/module-locale.html
Message-ID: <E1Bp9Qw-0002nn-00@sc8-sf-web3.sourceforge.net>

Bugs item #998170, was opened at 2004-07-26 19:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998170&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Laura Creighton (lcreighton)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in http://docs.python.org/lib/module-locale.html

Initial Comment:
localeconv( ) table spells negative with 2 'nn's in
'meaning'

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998170&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 20:00:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 20:00:21 2004
Subject: [ python-Bugs-998001 ] bsddb has default flag of c, not r
Message-ID: <E1Bp9lp-0003b0-00@sc8-sf-web3.sourceforge.net>

Bugs item #998001, was opened at 2004-07-26 12:13
Message generated for change (Comment added) made by kimbruning
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998001&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: kim bruning (kimbruning)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb has default flag of c, not r

Initial Comment:
python 2.3.3 has a discrepancy with the documentation
at http://docs.python.org/lib/module-bsddb.htm

In section:
> 7.13 bsddb -- Interface to Berkeley DB library

for hashopen, btopen and rnopen, the documentation
states that:

> The optional flag identifies the mode used to open
the file. It >may be "r" (read only, default)

It turns out that 'r' is in fact not the default option
for any of
these 3 in Python 2.3.3.
The default option for the flag parameter turns out to
be 'c'. I had
some trouble with using the bsddb module in conjunction
with make, and finally resorted to reading the source
code to find out what was wrong.

The actual source code has:

def hashopen(file, flag='c', mode=0666, pgsize=None,
ffactor=None, nelem=None,
            cachesize=None, lorder=None, hflags=0):

def btopen(file, flag='c', mode=0666,
            btflags=0, cachesize=None, maxkeypage=None,
minkeypage=None,
            pgsize=None, lorder=None):

def rnopen(file, flag='c', mode=0666,
            rnflags=0, cachesize=None, pgsize=None,
lorder=None,
            rlen=None, delim=None, source=None, pad=None):


----------------------------------------------------------------------

>Comment By: kim bruning (kimbruning)
Date: 2004-07-26 18:00

Message:
Logged In: YES 
user_id=1091452

Fred Drake has fixed this in the documentation source

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998001&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 20:15:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 20:15:10 2004
Subject: [ python-Bugs-997912 ] Enclosing Scope missing from namespace in
	Tutorial
Message-ID: <E1BpA0A-00045Z-00@sc8-sf-web3.sourceforge.net>

Bugs item #997912, was opened at 2004-07-26 05:39
Message generated for change (Comment added) made by brianvanden
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997912&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian vdB (brianvanden)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enclosing Scope missing from namespace in Tutorial

Initial Comment:
In the docs to Python 2.3.4 (#53, May 25 2004,
21:17:02), Section 4.6 of the Python Tutorial says:

The execution of a function introduces a new symbol
table used for the local variables of the function.
More precisely, all variable assignments in a function
store the value in the local symbol table; whereas
variable 
references first look in the local symbol table, then
in the global symbol table, and then in the table of
built-in names. Thus, global variables cannot be
directly assigned a value within a function (unless
named in a
 global statement), although they may be referenced. 

This doesn't make it clear that in the following sort
of case, the nested def can 'see' the varriables in the
topmost function:

>>> spam = 1
>>> def foo():
	spam = 2
	ham = 3
	def bar():
		print spam, ham
	bar()

	
>>> foo()
2 3

I suggest the following ammendment:

. . . whereas variable references first look in the
local symbol table, then in the local scope of the
enclosing function defs (if any), then in the global
symbol table, . . .

Thanks,

Brian vdB

----------------------------------------------------------------------

>Comment By: Brian vdB (brianvanden)
Date: 2004-07-26 14:15

Message:
Logged In: YES 
user_id=1015686

Hi,

I'm new to SF. I meant the e.g. to read like:

>>> spam = 1
>>> def foo():
....spam = 2
....ham = 3
....def bar():
........print spam, ham
....bar()

>>> foo()
2 3

(where '.' are spaces.)

Thanks,

brian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997912&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 20:40:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 20:41:01 2004
Subject: [ python-Bugs-997166 ] What's New in 2.4: sorted(): doc bug?
Message-ID: <E1BpAP7-0002fH-00@sc8-sf-web4.sourceforge.net>

Bugs item #997166, was opened at 2004-07-24 14:48
Message generated for change (Settings changed) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997166&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Dyck (jmdyck)
Assigned to: A.M. Kuchling (akuchling)
Summary: What's New in 2.4: sorted(): doc bug?

Initial Comment:
http://www.python.org/dev/doc/devel/whatsnew/node7.html
("What's New in Python 2.4": "Other Language Changes")
In the blurb for sorted(), it has:

>>> L = [9,7,8,3,2,4,1,6,5]
>>> [10+i for i in sorted(L)]       # usable in a list 
comprehension
[11, 12, 13, 14, 15, 16, 17, 18, 19]
>>> L = [9,7,8,3,2,4,1,6,5]         # original is left 
unchanged
[9,7,8,3,2,4,1,6,5]

I think the second-last line should just be
>>> L    # original is left unchanged

----

Also, in

>>> sorted('Monte Python')

it might be less distracting to use the 'standard' 
spelling "Monty".


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-07-26 14:40

Message:
Logged In: YES 
user_id=11375

Fixed in CVS; thanks!


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997166&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 21:14:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 21:15:06 2004
Subject: [ python-Bugs-998246 ] Popen3.poll race condition
Message-ID: <E1BpAw7-0006D1-00@sc8-sf-web3.sourceforge.net>

Bugs item #998246, was opened at 2004-07-26 15:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tres Seaver (tseaver)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen3.poll race condition

Initial Comment:
poll() swallows all IOErrors, including ENOCHILD;  if
the child process exits before poll is called, then an
applications which loops on
poll() will never exit.

I am working around this (against Python 2.3.3) via the
following:


                try:
                    pid, status = os.waitpid(proc.pid,
os.WNOHANG)
                except os.error, e:
                    if e.errno == 10:  # ENOCHILD
                        result = 0
                    else:
                        raise
                else:
                    if pid == proc.pid:
                        result = status


where 'proc' is an instance of Popen3.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998246&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 23:03:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 23:03:43 2004
Subject: [ python-Bugs-998307 ] replace file() with open() in libcvs.tex
Message-ID: <E1BpCdE-0007x4-00@sc8-sf-web1.sourceforge.net>

Bugs item #998307, was opened at 2004-07-26 23:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998307&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Fedor Baart (siggyf)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace file() with open() in libcvs.tex

Initial Comment:
It was suggested by BDFL that open() should be prefered
above file(). The libcsv.tex documentation uses file()
to open files instead of open(). For the cause of
consistency they should be changed to open(). See lines
317,326 and 335.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998307&group_id=5470
From noreply at sourceforge.net  Mon Jul 26 23:07:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Jul 26 23:08:04 2004
Subject: [ python-Bugs-998307 ] replace file() with open() in libcvs.tex
Message-ID: <E1BpChQ-000575-00@sc8-sf-web2.sourceforge.net>

Bugs item #998307, was opened at 2004-07-26 23:03
Message generated for change (Settings changed) made by siggyf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998307&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 3
Submitted By: Fedor Baart (siggyf)
Assigned to: Nobody/Anonymous (nobody)
Summary: replace file() with open() in libcvs.tex

Initial Comment:
It was suggested by BDFL that open() should be prefered
above file(). The libcsv.tex documentation uses file()
to open files instead of open(). For the cause of
consistency they should be changed to open(). See lines
317,326 and 335.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998307&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 02:41:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 02:41:39 2004
Subject: [ python-Bugs-756104 ] Calling socket.recv() with a large number
	breaks
Message-ID: <E1BpG2B-0006Q9-00@sc8-sf-web4.sourceforge.net>

Bugs item #756104, was opened at 2003-06-17 14:25
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex R.M. Turner (plexq)
Assigned to: Nobody/Anonymous (nobody)
Summary: Calling socket.recv() with a large number breaks

Initial Comment:
I have a backup script that calls socket.recv() passing
the amount of data that is left to get for a given file
as the argument.  For very large files (I have one here
that is 1.9Gig) it seems to break horribly after
receiving about 130Meg.  I have tried to track it down
precisely with basic debugging (putting in print
statements in the python code) but it just seams to
freak out around the 130meg mark, and it just doesn't
make sense.  If I change the argument passed to recv to
32767 it works just fine.  I have attatched the loop
that reads data from the socket (In a working state,
the bad code is commented out).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-26 20:41

Message:
Logged In: YES 
user_id=31435

potterru, I don't believe plexq was using _fileobject.read() -- 
he said he was using socket.recv(), and all the comments 
later were consistent with that.

The code you found does appear to *intend* max():  code 
following the snippet you quoted clearly expects that it may 
have read more than "left" bytes, and it would not be 
worrying about that had min() been intended.  I agree the 
code is pretty inscrutable regardless, but we'd have to ask 
Guido why he wrote it that way.

In any case, since this bug report is about socket.recv(), if 
you want to make a case that _fileobject.read() is buggy you 
should open a new report for that.

----------------------------------------------------------------------

Comment By: Igor E. Poteryaev (potterru)
Date: 2004-07-26 07:23

Message:
Logged In: YES 
user_id=48596

It looks like bug in module socket.py in _fileobject.read method. 
... 
while True: 
&nbsp;&nbsp;&nbsp;&nbsp;left = size - buf_len 
&nbsp;&nbsp;&nbsp;&nbsp;recv_size = max(self._rbufsize, left) 
&nbsp;&nbsp;&nbsp;&nbsp;data = self._sock.recv(recv_size) 
 
This code should read not more than *left* or *buffer size* 
 
So, it should be min instead of max ! 
 
Should I file a bug/patch for this ? 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-18 14:51

Message:
Logged In: YES 
user_id=31435

I assume you're running on Linux.  Python's implementation of 
recv asks the platform malloc for a buffer of the size 
requested, and raises an exception if malloc returns NULL.  
Unfortunately, malloc on Linux has a nasty habit of returning 
non-NULL even if there's no chance you can actually use the 
amount of memory requested.  There's really nothing Python 
can do about that.

So back to Jeremy's comment:  try the same thing in C.  If 
you get ridiculous behavior there too, it's a platform C/OS 
bug, and Python won't be able to hide it from you.

----------------------------------------------------------------------

Comment By: Alex R.M. Turner (plexq)
Date: 2003-06-18 14:22

Message:
Logged In: YES 
user_id=60034

That as maybe - it might be worth putting a suggested
maximum in the docs.  However I would say that given that an
IPv6 packet could be as large as 2Gig, it's not unreasonable
to ask for a packet as large as 1 Gig.  Wether the problem
is in glibc or python I don't know, although it seems that
asking for a buffer of 1.3 Gig in size, and passing that to
recv() would be odd behaviour on a current system in C given
that most systems couldn't allocate that much memory to a
buffer ;).  I have written fairly extensive socket code in
C/C++ before, and I never used anything larger than 65536
for the obvious reason that you can't receive anything
bigger than that in IPv4 (and most NICs can't handle
anything that big either).  I figured it would be
interesting to see what happened :).  I have a penchant for
being the only person in history to do quite a few things
apparently!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-06-18 12:29

Message:
Logged In: YES 
user_id=31435

BTW, if you're new to socket programming, do read Python's 
socket programming HOWTO:

http://www.amk.ca/python/howto/sockets/

I expect you're the only person in history to try passing such 
a large value to recv() -- even if it worked, you'd almost 
certainly run out of memory trying to allocate buffer space for 
1.9GB.  sockets are a low-level facility, and it's common to 
pass a relatively small power of 2 (for best match with 
hardware and network realities).

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-18 12:02

Message:
Logged In: YES 
user_id=31392

What happens when you write a C program that does the same
thing?  I expect you'll see similar problems.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756104&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 02:53:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 02:53:35 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1BpGDi-0003gi-00@sc8-sf-web2.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 20:59
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Jp Calderone (kuran)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-26 17:53

Message:
Logged In: YES 
user_id=357491

=)  No need to presume; I know better.

Writing strftime in Python would be rather difficult since there is no other 
consistent way to get at all of that locale info.  Yes, you could use the 
locale module, but even that is iffy at times on some platforms.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 08:30

Message:
Logged In: YES 
user_id=31435

Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste 
duplicate bug in email._parseaddr.parsedate_tz().  Assigning 
this report to Barry hoping he'll fix those, and boosted the 
priority:  Barry, 0 is an illegal value for tm_yday in a Python 
time tuple.  Python 2.4 cares about this.  You want 1 there 
instead.  I'd do it, but am not familiar with the test suites for 
those modules.

C99's strftime is a large and complicated function, so it would 
take a peculiar kind of masochism for someone to want to 
rewrite it in Python.  Brett did the Python strptime, but he's 
older now, and has presumably learned better <wink>.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2004-07-25 22:25

Message:
Logged In: YES 
user_id=366566

The more I think about it the more I want to suggest that
strftime just be implemented in Python so that garbage
values that are never required can be accepted, safe in the
knowledge that they won't be used by the implementation. 
I'm not sure how feasible this is.  I know strptime is now
provided by Python and not the underlying library, so it
seems at least in the ballpark of plausibility.

On the other hand, looking more closely at what my
requirements really are, it seems that the input to
strftime() is actually coming from rfc822.parsedate_tz(),
which builds up a tuple containing all the interesting
values, and uses 0s for the nonsense ones.

Would a patch for parsedate_tz() (and similarly behaving
functions, I suppose, though I can't think of any off the
top of my head) to generate values acceptable to strftime()
be more acceptable?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-25 21:45

Message:
Logged In: YES 
user_id=31435

JP, can you define which nonsense values "are needed"?  We 
can't go back to allowing garbage everywhere, because doing 
so did cause crashes in platform C libraries.

The only thing it complains about in the specific example you 
gave is the middle 0.  I agree that one is irritating, and is due 
to Python inexplicably saying that tm_yday must be in 1 .. 
366 (instead of C's 0 .. 365) -- so Python subtracts one from 
the middle 0, giving a -1 that we can't afford to pass on to 
the C library.

If the only thing you really need is to allow a 0 for tm_yday, 
perhaps that could be allowed without whining.  0 is fine for 
tm_wday already, and for tm_isdst.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 19:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 17:01:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 17:01:14 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1BpTS2-0003q7-00@sc8-sf-web1.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 23:59
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Jp Calderone (kuran)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:01

Message:
Logged In: YES 
user_id=764593

What about a python wrapper to the C function that accepted 
either short tuples or None in trailing (or any?) positions and 
automatically filled in a default value.

Some can be computed from other fields; if not, the same 
defaults used in strptime seem as reasonable as any.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-26 20:53

Message:
Logged In: YES 
user_id=357491

=)  No need to presume; I know better.

Writing strftime in Python would be rather difficult since there is no other 
consistent way to get at all of that locale info.  Yes, you could use the 
locale module, but even that is iffy at times on some platforms.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 11:30

Message:
Logged In: YES 
user_id=31435

Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste 
duplicate bug in email._parseaddr.parsedate_tz().  Assigning 
this report to Barry hoping he'll fix those, and boosted the 
priority:  Barry, 0 is an illegal value for tm_yday in a Python 
time tuple.  Python 2.4 cares about this.  You want 1 there 
instead.  I'd do it, but am not familiar with the test suites for 
those modules.

C99's strftime is a large and complicated function, so it would 
take a peculiar kind of masochism for someone to want to 
rewrite it in Python.  Brett did the Python strptime, but he's 
older now, and has presumably learned better <wink>.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2004-07-26 01:25

Message:
Logged In: YES 
user_id=366566

The more I think about it the more I want to suggest that
strftime just be implemented in Python so that garbage
values that are never required can be accepted, safe in the
knowledge that they won't be used by the implementation. 
I'm not sure how feasible this is.  I know strptime is now
provided by Python and not the underlying library, so it
seems at least in the ballpark of plausibility.

On the other hand, looking more closely at what my
requirements really are, it seems that the input to
strftime() is actually coming from rfc822.parsedate_tz(),
which builds up a tuple containing all the interesting
values, and uses 0s for the nonsense ones.

Would a patch for parsedate_tz() (and similarly behaving
functions, I suppose, though I can't think of any off the
top of my head) to generate values acceptable to strftime()
be more acceptable?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 00:45

Message:
Logged In: YES 
user_id=31435

JP, can you define which nonsense values "are needed"?  We 
can't go back to allowing garbage everywhere, because doing 
so did cause crashes in platform C libraries.

The only thing it complains about in the specific example you 
gave is the middle 0.  I agree that one is irritating, and is due 
to Python inexplicably saying that tm_yday must be in 1 .. 
366 (instead of C's 0 .. 365) -- so Python subtracts one from 
the middle 0, giving a -1 that we can't afford to pass on to 
the C library.

If the only thing you really need is to allow a 0 for tm_yday, 
perhaps that could be allowed without whining.  0 is fine for 
tm_wday already, and for tm_isdst.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 22:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 22:55:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 22:55:44 2004
Subject: [ python-Bugs-998998 ] pickle bug - recursively memoizing class?
Message-ID: <E1BpYz7-00027W-00@sc8-sf-web3.sourceforge.net>

Bugs item #998998, was opened at 2004-07-27 15:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle bug - recursively memoizing class?

Initial Comment:
The attached script (picklecycle.py) gives me an
assertion error
in Pickler.memoize().  Maybe I'm just doing something dumb.
I have very little experience with pickle and even less
experience
pickling new-style class instances.  I'm just trying to
adapt an
existing messy object graph to allow it to be pickled.
 I realize the
two instances refer to each other, but I thought pickle was
supposed to gracefully handle cyclic object graphs.

I can worm around the problem a couple ways.  First,
getting
rid of new-style classes does the trick.  Also
modifying B.__reduce__
to not return self.__dict__ seems to do the trick.

Output (cycle.out) and a modified version of
Pickler.memoize
(memoize.py) will be attached momentarily.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 22:56:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 22:57:04 2004
Subject: [ python-Bugs-998998 ] pickle bug - recursively memoizing class?
Message-ID: <E1BpZ06-0002KD-00@sc8-sf-web1.sourceforge.net>

Bugs item #998998, was opened at 2004-07-27 15:55
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle bug - recursively memoizing class?

Initial Comment:
The attached script (picklecycle.py) gives me an
assertion error
in Pickler.memoize().  Maybe I'm just doing something dumb.
I have very little experience with pickle and even less
experience
pickling new-style class instances.  I'm just trying to
adapt an
existing messy object graph to allow it to be pickled.
 I realize the
two instances refer to each other, but I thought pickle was
supposed to gracefully handle cyclic object graphs.

I can worm around the problem a couple ways.  First,
getting
rid of new-style classes does the trick.  Also
modifying B.__reduce__
to not return self.__dict__ seems to do the trick.

Output (cycle.out) and a modified version of
Pickler.memoize
(memoize.py) will be attached momentarily.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-27 15:56

Message:
Logged In: YES 
user_id=44345

Attaching chatty version of Pickler.memoize()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470
From noreply at sourceforge.net  Tue Jul 27 22:57:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Jul 27 22:57:55 2004
Subject: [ python-Bugs-998998 ] pickle bug - recursively memoizing class?
Message-ID: <E1BpZ14-0002BQ-00@sc8-sf-web3.sourceforge.net>

Bugs item #998998, was opened at 2004-07-27 15:55
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle bug - recursively memoizing class?

Initial Comment:
The attached script (picklecycle.py) gives me an
assertion error
in Pickler.memoize().  Maybe I'm just doing something dumb.
I have very little experience with pickle and even less
experience
pickling new-style class instances.  I'm just trying to
adapt an
existing messy object graph to allow it to be pickled.
 I realize the
two instances refer to each other, but I thought pickle was
supposed to gracefully handle cyclic object graphs.

I can worm around the problem a couple ways.  First,
getting
rid of new-style classes does the trick.  Also
modifying B.__reduce__
to not return self.__dict__ seems to do the trick.

Output (cycle.out) and a modified version of
Pickler.memoize
(memoize.py) will be attached momentarily.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-27 15:57

Message:
Logged In: YES 
user_id=44345

Attaching the output I see when running picklecycle.py w/ the
modified memoize() method (cycle.out).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-27 15:56

Message:
Logged In: YES 
user_id=44345

Attaching chatty version of Pickler.memoize()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998998&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 00:15:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 00:16:00 2004
Subject: [ python-Bugs-999042 ] Compiler module doesn't handle global
	statement correctly
Message-ID: <E1BpaEo-0005L0-00@sc8-sf-web1.sourceforge.net>

Bugs item #999042, was opened at 2004-07-27 22:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler module doesn't handle global statement correctly

Initial Comment:
If we don't use the compiler module:

>>> code = 'global x\nx=1'
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}, 'x': 1}, {})

with the compiler module:

>>> code = compiler.compile('global x\nx=1', 'd', 'exec') 
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}}, {'x': 1})

global is ignored

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 00:41:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 00:42:00 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1Bpadw-0006D6-00@sc8-sf-web1.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 20:59
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Jp Calderone (kuran)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-07-27 15:41

Message:
Logged In: YES 
user_id=357491

I could live with the None option but not the short tuple option.  The 
former is explicitly not a number and nothing returns that for time tuples 
to my knowledge.  The latter, though, might mask bugs in code when you 
accidentally truncated your tuple too much.

And yes, other values can be computed from other fields (strptime has 
the code for some slots and I think datetime can do some as well).  But 
why waste the overhead?  While strptime has to care since you are 
getting a time tuple and thus it can't guess what fields you care about, 
strftime shouldn't need to care since it is assumed that you are passing 
in as much info as needed for the format directive to have what it needs.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 08:01

Message:
Logged In: YES 
user_id=764593

What about a python wrapper to the C function that accepted 
either short tuples or None in trailing (or any?) positions and 
automatically filled in a default value.

Some can be computed from other fields; if not, the same 
defaults used in strptime seem as reasonable as any.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-26 17:53

Message:
Logged In: YES 
user_id=357491

=)  No need to presume; I know better.

Writing strftime in Python would be rather difficult since there is no other 
consistent way to get at all of that locale info.  Yes, you could use the 
locale module, but even that is iffy at times on some platforms.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 08:30

Message:
Logged In: YES 
user_id=31435

Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste 
duplicate bug in email._parseaddr.parsedate_tz().  Assigning 
this report to Barry hoping he'll fix those, and boosted the 
priority:  Barry, 0 is an illegal value for tm_yday in a Python 
time tuple.  Python 2.4 cares about this.  You want 1 there 
instead.  I'd do it, but am not familiar with the test suites for 
those modules.

C99's strftime is a large and complicated function, so it would 
take a peculiar kind of masochism for someone to want to 
rewrite it in Python.  Brett did the Python strptime, but he's 
older now, and has presumably learned better <wink>.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2004-07-25 22:25

Message:
Logged In: YES 
user_id=366566

The more I think about it the more I want to suggest that
strftime just be implemented in Python so that garbage
values that are never required can be accepted, safe in the
knowledge that they won't be used by the implementation. 
I'm not sure how feasible this is.  I know strptime is now
provided by Python and not the underlying library, so it
seems at least in the ballpark of plausibility.

On the other hand, looking more closely at what my
requirements really are, it seems that the input to
strftime() is actually coming from rfc822.parsedate_tz(),
which builds up a tuple containing all the interesting
values, and uses 0s for the nonsense ones.

Would a patch for parsedate_tz() (and similarly behaving
functions, I suppose, though I can't think of any off the
top of my head) to generate values acceptable to strftime()
be more acceptable?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-25 21:45

Message:
Logged In: YES 
user_id=31435

JP, can you define which nonsense values "are needed"?  We 
can't go back to allowing garbage everywhere, because doing 
so did cause crashes in platform C libraries.

The only thing it complains about in the specific example you 
gave is the middle 0.  I agree that one is irritating, and is due 
to Python inexplicably saying that tm_yday must be in 1 .. 
366 (instead of C's 0 .. 365) -- so Python subtracts one from 
the middle 0, giving a -1 that we can't afford to pass on to 
the C library.

If the only thing you really need is to allow a 0 for tm_yday, 
perhaps that could be allowed without whining.  0 is fine for 
tm_wday already, and for tm_isdst.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 19:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 00:58:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 00:59:05 2004
Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility
Message-ID: <E1BpauR-00030U-00@sc8-sf-web2.sourceforge.net>

Bugs item #997368, was opened at 2004-07-24 23:59
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Jp Calderone (kuran)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: strftime() backwards incompatibility

Initial Comment:

  time.strftime() in 2.4a0 places more restrictions on
its inputs than does the version in 2.3.x.  Revision
2.140 seems to be where this was introduced.

    I believe it is a common use of strftime() to fill
out only some fields of the time tuple.  Requiring the
day of year and day of week is particularly burdensome.

    Here is an example that triggers the changed behavior:

    import time
    now = time.gmtime()
    now = now[:-3] + (0, 0, 0)
    print time.strftime("", now) 


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 18:58

Message:
Logged In: YES 
user_id=764593

For me, Day-of-week and day-of-year are typically there 
because the format was decided externally; I don't track them 
in my application.

I've seen databases with timestamps that all end in "000".

I would be happy to have "None" replaced by a default value; 
it is just that the result should be consistent with what I did 
pass.  For example, I wouldn't want to pass year/month/day 
and discover that every single day is Monday, or to pass year/
day-of-year and discover that day 345 is still in January.

-jJ


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-27 18:41

Message:
Logged In: YES 
user_id=357491

I could live with the None option but not the short tuple option.  The 
former is explicitly not a number and nothing returns that for time tuples 
to my knowledge.  The latter, though, might mask bugs in code when you 
accidentally truncated your tuple too much.

And yes, other values can be computed from other fields (strptime has 
the code for some slots and I think datetime can do some as well).  But 
why waste the overhead?  While strptime has to care since you are 
getting a time tuple and thus it can't guess what fields you care about, 
strftime shouldn't need to care since it is assumed that you are passing 
in as much info as needed for the format directive to have what it needs.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-07-27 11:01

Message:
Logged In: YES 
user_id=764593

What about a python wrapper to the C function that accepted 
either short tuples or None in trailing (or any?) positions and 
automatically filled in a default value.

Some can be computed from other fields; if not, the same 
defaults used in strptime seem as reasonable as any.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-26 20:53

Message:
Logged In: YES 
user_id=357491

=)  No need to presume; I know better.

Writing strftime in Python would be rather difficult since there is no other 
consistent way to get at all of that locale info.  Yes, you could use the 
locale module, but even that is iffy at times on some platforms.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 11:30

Message:
Logged In: YES 
user_id=31435

Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste 
duplicate bug in email._parseaddr.parsedate_tz().  Assigning 
this report to Barry hoping he'll fix those, and boosted the 
priority:  Barry, 0 is an illegal value for tm_yday in a Python 
time tuple.  Python 2.4 cares about this.  You want 1 there 
instead.  I'd do it, but am not familiar with the test suites for 
those modules.

C99's strftime is a large and complicated function, so it would 
take a peculiar kind of masochism for someone to want to 
rewrite it in Python.  Brett did the Python strptime, but he's 
older now, and has presumably learned better <wink>.

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2004-07-26 01:25

Message:
Logged In: YES 
user_id=366566

The more I think about it the more I want to suggest that
strftime just be implemented in Python so that garbage
values that are never required can be accepted, safe in the
knowledge that they won't be used by the implementation. 
I'm not sure how feasible this is.  I know strptime is now
provided by Python and not the underlying library, so it
seems at least in the ballpark of plausibility.

On the other hand, looking more closely at what my
requirements really are, it seems that the input to
strftime() is actually coming from rfc822.parsedate_tz(),
which builds up a tuple containing all the interesting
values, and uses 0s for the nonsense ones.

Would a patch for parsedate_tz() (and similarly behaving
functions, I suppose, though I can't think of any off the
top of my head) to generate values acceptable to strftime()
be more acceptable?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-26 00:45

Message:
Logged In: YES 
user_id=31435

JP, can you define which nonsense values "are needed"?  We 
can't go back to allowing garbage everywhere, because doing 
so did cause crashes in platform C libraries.

The only thing it complains about in the specific example you 
gave is the middle 0.  I agree that one is irritating, and is due 
to Python inexplicably saying that tm_yday must be in 1 .. 
366 (instead of C's 0 .. 365) -- so Python subtracts one from 
the middle 0, giving a -1 that we can't afford to pass on to 
the C library.

If the only thing you really need is to allow a 0 for tm_yday, 
perhaps that could be allowed without whining.  0 is fine for 
tm_wday already, and for tm_isdst.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-07-25 22:39

Message:
Logged In: YES 
user_id=357491

This was brought up on python-dev in the thread http://mail.python.org/
pipermail/python-dev/2004-July/046418.html .  This was all originally 
discussed back in Feb 2004: http://mail.python.org/pipermail/python-
dev/2004-February/042675.html .

The current solution was discussed on python-dev and agreed upon.  
Because using values that are outside of basic boundaries can lead to 
core dumps (mostly thanks to strftime() implementations that do not 
check boundary values when indexing into arrays) a check to make sure 
all values are within sane values, but *without* checking whether they 
are valid values when compared to each other, was added.

The docs do say that "ValueError raised if a field in [tuple] t is out of 
range".

Personally I say close this as won't fix.  python-dev came to the 
conclusion collectively that breaking possible code that played loosely 
with the passed-in values was better than allowing possible core dumps.  
A very compelling reason that got multiple support from othe developers 
would be needed, in my opinion, to overturn this change.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 03:17:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 03:17:07 2004
Subject: [ python-Bugs-993601 ] optparse needs reference documentation
Message-ID: <E1Bpd41-00029Y-00@sc8-sf-web1.sourceforge.net>

Bugs item #993601, was opened at 2004-07-19 02:30
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Greg Ward (gward)
>Summary: optparse needs reference documentation

Initial Comment:
The optparse libref documentation, while extensive, 
doesn't actually include an API reference. There's no way 
of knowing the valid parameter set of 
OptionParser.add_option() without going through the 
source. 
 
Please consider adding an API reference page for each of 
OptionParser (including OptionContainer), Values, Option 
(aka make_option) and OptionGroup. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=993601&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 16:00:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 16:00:16 2004
Subject: [ python-Bugs-999444 ] compiler module doesn't support unicode
	characters in laiter
Message-ID: <E1Bpoya-00049x-00@sc8-sf-web1.sourceforge.net>

Bugs item #999444, was opened at 2004-07-28 14:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module doesn't support unicode characters in laiter

Initial Comment:
I'm not positive that this is a bug.  The buit-in
compile function acepts unicode with non-ascii text in
literals:

>>> text = u"print u'''\u0442\u0435\u0441\u0442'''"
>>> exec compile(text, 's', 'exec')
?&#130;?????&#130;
>>> import compiler
>>> exec compiler.compile(text, 's', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 64, in compile
    gen.compile()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 111, in compile
    tree = self._get_tree()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 77, in _get_tree
    tree = parse(self.source, self.mode)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 10-13: ordinal not in range(128)
>>> 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 16:01:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 16:01:10 2004
Subject: [ python-Bugs-999042 ] Compiler module doesn't handle global
	statement correctly
Message-ID: <E1BpozT-0004C4-00@sc8-sf-web1.sourceforge.net>

Bugs item #999042, was opened at 2004-07-27 22:15
Message generated for change (Comment added) made by dcjim
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler module doesn't handle global statement correctly

Initial Comment:
If we don't use the compiler module:

>>> code = 'global x\nx=1'
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}, 'x': 1}, {})

with the compiler module:

>>> code = compiler.compile('global x\nx=1', 'd', 'exec') 
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}}, {'x': 1})

global is ignored

----------------------------------------------------------------------

>Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 14:01

Message:
Logged In: YES 
user_id=73023

Also in 2.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 16:01:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 16:01:36 2004
Subject: [ python-Bugs-999042 ] Compiler module doesn't handle global
	statement correctly
Message-ID: <E1Bpozt-0004DM-00@sc8-sf-web1.sourceforge.net>

Bugs item #999042, was opened at 2004-07-27 22:15
Message generated for change (Settings changed) made by dcjim
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler module doesn't handle global statement correctly

Initial Comment:
If we don't use the compiler module:

>>> code = 'global x\nx=1'
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}, 'x': 1}, {})

with the compiler module:

>>> code = compiler.compile('global x\nx=1', 'd', 'exec') 
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}}, {'x': 1})

global is ignored

----------------------------------------------------------------------

Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 14:01

Message:
Logged In: YES 
user_id=73023

Also in 2.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 16:02:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 16:02:06 2004
Subject: [ python-Bugs-999444 ] compiler module doesn't support unicode
	characters in laiter
Message-ID: <E1Bpp0L-0004F9-00@sc8-sf-web1.sourceforge.net>

Bugs item #999444, was opened at 2004-07-28 14:00
Message generated for change (Comment added) made by dcjim
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module doesn't support unicode characters in laiter

Initial Comment:
I'm not positive that this is a bug.  The buit-in
compile function acepts unicode with non-ascii text in
literals:

>>> text = u"print u'''\u0442\u0435\u0441\u0442'''"
>>> exec compile(text, 's', 'exec')
?&#130;?????&#130;
>>> import compiler
>>> exec compiler.compile(text, 's', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 64, in compile
    gen.compile()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 111, in compile
    tree = self._get_tree()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 77, in _get_tree
    tree = parse(self.source, self.mode)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 10-13: ordinal not in range(128)
>>> 

----------------------------------------------------------------------

>Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 14:02

Message:
Logged In: YES 
user_id=73023

Also in 2.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 17:14:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 17:14:34 2004
Subject: [ python-Bugs-882332 ] boolobject.h documentation missing from
	Python/C API
Message-ID: <E1Bpq8V-0007o2-00@sc8-sf-web3.sourceforge.net>

Bugs item #882332, was opened at 2004-01-22 14:13
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882332&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: boolobject.h documentation missing from Python/C API

Initial Comment:
The items in boolobject.h do not appear to be 
documented in the current documentation.  I just 
checked the index of the online docs and  
PyBool_FromLong, Py_True, and Py_False are all 
missing.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-28 11:14

Message:
Logged In: YES 
user_id=3066

Skip added much of the missing documentation in
Doc/api/concrete.tex revision 1.49.  Py_True and Py_False
still need to be added.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882332&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 17:20:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 17:21:00 2004
Subject: [ python-Bugs-962442 ] Konqueror can't render docs because of
	malformed HTML
Message-ID: <E1BpqEi-0003rj-00@sc8-sf-web2.sourceforge.net>

Bugs item #962442, was opened at 2004-05-28 22:39
Message generated for change (Comment added) made by felixwiemann
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=962442&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Klaus-J Wolf (yanestra)
Assigned to: Nobody/Anonymous (nobody)
Summary: Konqueror can't render docs because of malformed HTML

Initial Comment:
At least on page Python-Docs-2.3.3/lib/re-syntax.html 
Konqueror doesn't render the <DL> definition part 
correctly (the <DT> part is not being displayed). 
 
The reason appears to be malformed HTML, as to cite 
Stephan Kulow of KDE Project: 
 
"No, this is not correct HTML and you might want to 
report it to the python maintainers.  
  
I wonder why they use <dl compact> (which is correct 
HTML) when they put a <P> in there (which is not 
correct).  
  
Send your snippet through tidy to see how it looks as 
correct HTML (and as such it's rendered correctly by 
konqueror)" 
 
You might want to visit KDE's bugzilla: 
http://bugs.kde.org/show_bug.cgi?id=82335 

----------------------------------------------------------------------

Comment By: Felix Wiemann (felixwiemann)
Date: 2004-07-28 17:20

Message:
Logged In: YES 
user_id=1014490

In fact, the HTML code is not valid. See, e.g.,
http://validator.w3.org/check?uri=http://www.python.org/dev/doc/devel/lib/boolean.html&charset=%28detect+automatically%29&doctype=Inline&ss=1&sp=1&outline=1&No200=1&verbose=1

And the link-tag which links to the next page appears twice.
E.g., there is
<LINK rel="next" href="comparisons.html">
twice on the page
http://www.python.org/dev/doc/devel/lib/boolean.html

This is very annoying when using the link toolbar for
Mozilla Firefox.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=962442&group_id=5470
From noreply at sourceforge.net  Wed Jul 28 20:07:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Jul 28 20:07:49 2004
Subject: [ python-Bugs-888594 ] cPickle doesn't like protocol keyword
	argument, pickle does
Message-ID: <E1Bpsq4-0006aS-00@sc8-sf-web1.sourceforge.net>

Bugs item #888594, was opened at 2004-02-01 17:29
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=888594&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't like protocol keyword argument, pickle does

Initial Comment:
The dump and dumps functions from the "cPickle" module
don't accept the protocol keyword argument. The
"pickle" module does. This is an irritating API
difference that requires me to write different code to
deal with either cPickle or pickle (if cPickle is not
available).

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-07-28 20:07

Message:
Logged In: YES 
user_id=21627

Fix with said patch.

----------------------------------------------------------------------

Comment By: Dima Dorfman (ddorfman)
Date: 2004-07-22 10:26

Message:
Logged In: YES 
user_id=908995

Patch #995766 should take care of this

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=888594&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 00:06:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 00:06:56 2004
Subject: [ python-Bugs-999767 ] Setup.local ignored by setup.py
Message-ID: <E1BpwZZ-0006Ku-00@sc8-sf-web3.sourceforge.net>

Bugs item #999767, was opened at 2004-07-28 15:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan A. Terre (sfiedler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Setup.local ignored by setup.py

Initial Comment:
This applies to Python 2.2.x, 2.3.x, and 2.4a1.

Platforms seem to be all Unix flavors.

I have zlib, readline, and Tk in an unusual location.
There are also often older versions in the usual
locations (/usr/local/lib, etc.). I put -L and -I flags
pointing to the desired location of these libraries in
entries for the appropriate extension modules in
Setup.local, per the README. I specify all three
extension modules as *shared* .

When I build, the extension modules I specify in
Setup.local get built twice: once directly from the
Makefile, with the flags I request in Setup.local, then
again from setup.py's build_ext phase, with the default
flags. The second build is what's installed, so I end
up using the wrong version of libz, libreadline, and
libtk .

The problem appears to be around line 152 of setup.py
(CVS revision 1.190). There is code to ignore modules
defined in Modules/Setup, but not modules defined in
Modules/Setup.local .

I'm not familiar with the text_file.TextFile class, so
there may be a better way to do this, but one the fix
is to loop over ['Modules/Setup',
'Modules/Setup.local'] rather than only reading
Modules/Setup.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999767&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 00:25:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 00:25:15 2004
Subject: [ python-Bugs-999776 ] zlib home page wrong in three files
Message-ID: <E1BpwrE-00031f-00@sc8-sf-web2.sourceforge.net>

Bugs item #999776, was opened at 2004-07-28 15:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999776&group_id=5470

Category: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan A. Terre (sfiedler)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib home page wrong in three files

Initial Comment:
I found this in Python 2.4a1. I believe it is present
in all previous 2.x releases as well.

The canonical URL for the zlib home page has changed.

There was another similar report back in 2001, but it
was closed after fixing just the documentation for the
zlib module. That bug ID is 457541. I wasn't sure
whether to comment on that bug, since it's already
closed, or open a new one; I apologize if I made the
wrong choice.

The old page is still referenced by

Lib/test/test_gzip.py
Misc/BeOS-setup.py
Modules/Setup.dist

The old URL

  http://www.cdrom.com/pub/infozip/zlib/

should be replaced with 

  http://www.gzip.org/zlib/

in all three files.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999776&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 00:26:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 00:26:09 2004
Subject: [ python-Bugs-457541 ] zlib homepage has changed
Message-ID: <E1Bpws9-0007aL-00@sc8-sf-web1.sourceforge.net>

Bugs item #457541, was opened at 2001-09-01 06:53
Message generated for change (Comment added) made by sfiedler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=457541&group_id=5470

Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: zlib homepage has changed

Initial Comment:
The &quot;canonical&quot; URL for zlib is: 
http://www.gzip.org/zlib/

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-07-28 15:26

Message:
Logged In: YES 
user_id=246063

I've submitted bug 999776 with three more files that still
have the old zlib home page.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-09-01 08:36

Message:
Logged In: YES 
user_id=3066

This has already been fixed in the documentation for the
&quot;zlib&quot; module.  If you found another reference to an older
zlib site, please explain the bug report where you found the
reference.

This report is closed as &quot;already fixed&quot;.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=457541&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 04:19:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 04:19:33 2004
Subject: [ python-Bugs-882332 ] boolobject.h documentation missing from
	Python/C API
Message-ID: <E1Bq0W3-0004Ce-00@sc8-sf-web3.sourceforge.net>

Bugs item #882332, was opened at 2004-01-22 13:13
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882332&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: boolobject.h documentation missing from Python/C API

Initial Comment:
The items in boolobject.h do not appear to be 
documented in the current documentation.  I just 
checked the index of the online docs and  
PyBool_FromLong, Py_True, and Py_False are all 
missing.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-07-28 21:19

Message:
Logged In: YES 
user_id=44345

I just added Py_True/Py_False (concrete.tex v1.50).  Leaving for 
Fred to review and close.  I will backport the relevant bits to
the 2.3 branch as well.



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-28 10:14

Message:
Logged In: YES 
user_id=3066

Skip added much of the missing documentation in
Doc/api/concrete.tex revision 1.49.  Py_True and Py_False
still need to be added.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882332&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 05:49:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 05:49:45 2004
Subject: [ python-Bugs-998170 ] Typo in
	http://docs.python.org/lib/module-locale.html
Message-ID: <E1Bq1vH-0006KO-00@sc8-sf-web3.sourceforge.net>

Bugs item #998170, was opened at 2004-07-26 13:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998170&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Laura Creighton (lcreighton)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Typo in http://docs.python.org/lib/module-locale.html

Initial Comment:
localeconv( ) table spells negative with 2 'nn's in
'meaning'

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-28 23:49

Message:
Logged In: YES 
user_id=33168

Thanks!  Checked in as: Doc/lib/liblocale.tex 1.38

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998170&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 05:57:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 05:57:25 2004
Subject: [ python-Bugs-999776 ] zlib home page wrong in three files
Message-ID: <E1Bq22j-0000jb-00@sc8-sf-web4.sourceforge.net>

Bugs item #999776, was opened at 2004-07-28 18:25
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999776&group_id=5470

Category: None
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Stephan A. Terre (sfiedler)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: zlib home page wrong in three files

Initial Comment:
I found this in Python 2.4a1. I believe it is present
in all previous 2.x releases as well.

The canonical URL for the zlib home page has changed.

There was another similar report back in 2001, but it
was closed after fixing just the documentation for the
zlib module. That bug ID is 457541. I wasn't sure
whether to comment on that bug, since it's already
closed, or open a new one; I apologize if I made the
wrong choice.

The old page is still referenced by

Lib/test/test_gzip.py
Misc/BeOS-setup.py
Modules/Setup.dist

The old URL

  http://www.cdrom.com/pub/infozip/zlib/

should be replaced with 

  http://www.gzip.org/zlib/

in all three files.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-28 23:57

Message:
Logged In: YES 
user_id=33168

Thanks!  

Checked in as:
 * ./Misc/BeOS-setup.py; 1.7
 * ./Modules/Setup.dist; 1.47
 * ./Lib/test/test_gzip.py; 1.13

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999776&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 08:06:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 08:06:53 2004
Subject: [ python-Bugs-997533 ] "disjunct" should be "disjoint"
Message-ID: <E1Bq440-0002Ki-00@sc8-sf-web1.sourceforge.net>

Bugs item #997533, was opened at 2004-07-25 08:56
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997533&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Freeman (timfreeman)
Assigned to: Nobody/Anonymous (nobody)
Summary: "disjunct" should be "disjoint"

Initial Comment:
At http://www.python.org/doc/2.3.4/lib/built-in-funcs.html,
the first occurrence of "disjunct" should be "disjoint".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997533&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 13:19:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 13:19:55 2004
Subject: [ python-Bugs-999444 ] compiler module doesn't support unicode
	characters in laiter
Message-ID: <E1Bq8ww-0000tf-00@sc8-sf-web2.sourceforge.net>

Bugs item #999444, was opened at 2004-07-28 15:00
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module doesn't support unicode characters in laiter

Initial Comment:
I'm not positive that this is a bug.  The buit-in
compile function acepts unicode with non-ascii text in
literals:

>>> text = u"print u'''\u0442\u0435\u0441\u0442'''"
>>> exec compile(text, 's', 'exec')
?&#130;?????&#130;
>>> import compiler
>>> exec compiler.compile(text, 's', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 64, in compile
    gen.compile()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 111, in compile
    tree = self._get_tree()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 77, in _get_tree
    tree = parse(self.source, self.mode)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 10-13: ordinal not in range(128)
>>> 

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-29 12:19

Message:
Logged In: YES 
user_id=6656

the immediate problem is that the parser module does support 
unicode:

>>> import parser
>>> parser.suite(u"print u'''\u0442\u0435\u0441\u0442'''")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode characters in 
position 10-13: ordinal not in range(128)

there may well be more bugs lurking in Lib/compiler wrt this 
issue, but this is the first... I don't know how easy this will be to 
fix (looking at what the builtin compile() function does with 
unicode might be a good start).

----------------------------------------------------------------------

Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 15:02

Message:
Logged In: YES 
user_id=73023

Also in 2.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 13:30:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 13:30:17 2004
Subject: [ python-Bugs-999444 ] compiler module doesn't support unicode
	characters in laiter
Message-ID: <E1Bq96u-0003qC-00@sc8-sf-web3.sourceforge.net>

Bugs item #999444, was opened at 2004-07-28 15:00
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module doesn't support unicode characters in laiter

Initial Comment:
I'm not positive that this is a bug.  The buit-in
compile function acepts unicode with non-ascii text in
literals:

>>> text = u"print u'''\u0442\u0435\u0441\u0442'''"
>>> exec compile(text, 's', 'exec')
?&#130;?????&#130;
>>> import compiler
>>> exec compiler.compile(text, 's', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 64, in compile
    gen.compile()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 111, in compile
    tree = self._get_tree()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 77, in _get_tree
    tree = parse(self.source, self.mode)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 10-13: ordinal not in range(128)
>>> 

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-07-29 12:30

Message:
Logged In: YES 
user_id=6656

thinking about this a little harder, doing a proper job probably 
invloves mucking around in the depths of python to support 
source-as-unicode throughout.  the vile solution is this sort of 
thing:

>>> parser.suite('# coding: utf-8\n' + u"print 
u'''\u0442\u0435\u0441\u0442'''".encode('utf-8'))
<parser.st object at 0x107770>


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-29 12:19

Message:
Logged In: YES 
user_id=6656

the immediate problem is that the parser module does support 
unicode:

>>> import parser
>>> parser.suite(u"print u'''\u0442\u0435\u0441\u0442'''")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode characters in 
position 10-13: ordinal not in range(128)

there may well be more bugs lurking in Lib/compiler wrt this 
issue, but this is the first... I don't know how easy this will be to 
fix (looking at what the builtin compile() function does with 
unicode might be a good start).

----------------------------------------------------------------------

Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 15:02

Message:
Logged In: YES 
user_id=73023

Also in 2.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 13:38:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 13:38:17 2004
Subject: [ python-Bugs-999444 ] compiler module doesn't support unicode
	characters in laiter
Message-ID: <E1Bq9Ei-0001Yf-00@sc8-sf-web2.sourceforge.net>

Bugs item #999444, was opened at 2004-07-28 16:00
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
Assigned to: Nobody/Anonymous (nobody)
Summary: compiler module doesn't support unicode characters in laiter

Initial Comment:
I'm not positive that this is a bug.  The buit-in
compile function acepts unicode with non-ascii text in
literals:

>>> text = u"print u'''\u0442\u0435\u0441\u0442'''"
>>> exec compile(text, 's', 'exec')
?&#130;?????&#130;
>>> import compiler
>>> exec compiler.compile(text, 's', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 64, in compile
    gen.compile()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 111, in compile
    tree = self._get_tree()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 77, in _get_tree
    tree = parse(self.source, self.mode)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 50, in parse
    return Transformer().parsesuite(buf)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 120, in parsesuite
    return self.transform(parser.suite(text))
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 10-13: ordinal not in range(128)
>>> 

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-29 13:38

Message:
Logged In: YES 
user_id=38388

Note that the tokenizer converts the input string into UTF-8
(transcoding it as necessary if a source code encoding shebang
is found) and the compiler will assume this encoding when
creating
Unicode literals.

I'm not sure whether the compiler package is up-to-date w/r to
these internal changes in the C-based compiler.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-29 13:30

Message:
Logged In: YES 
user_id=6656

thinking about this a little harder, doing a proper job probably 
invloves mucking around in the depths of python to support 
source-as-unicode throughout.  the vile solution is this sort of 
thing:

>>> parser.suite('# coding: utf-8\n' + u"print 
u'''\u0442\u0435\u0441\u0442'''".encode('utf-8'))
<parser.st object at 0x107770>


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-07-29 13:19

Message:
Logged In: YES 
user_id=6656

the immediate problem is that the parser module does support 
unicode:

>>> import parser
>>> parser.suite(u"print u'''\u0442\u0435\u0441\u0442'''")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode characters in 
position 10-13: ordinal not in range(128)

there may well be more bugs lurking in Lib/compiler wrt this 
issue, but this is the first... I don't know how easy this will be to 
fix (looking at what the builtin compile() function does with 
unicode might be a good start).

----------------------------------------------------------------------

Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 16:02

Message:
Logged In: YES 
user_id=73023

Also in 2.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 21:28:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 21:28:43 2004
Subject: [ python-Bugs-991735 ] os.access reports true for read-only
	directories
Message-ID: <E1BqGZz-0003aX-00@sc8-sf-web2.sourceforge.net>

Bugs item #991735, was opened at 2004-07-15 12:08
Message generated for change (Comment added) made by mkc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Moales (mmoales)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2004-07-29 14:28

Message:
Logged In: YES 
user_id=555

The submitter seems to want os.access to agree with the
subsequent behavior of I/O operation, but this is not
possible for all cases.  The NFS spec, for example, allows
NFS servers to deny operations in a capricious manner, over
and above any denial that might be due to permissions bits
and/or a volume "read only" flag.  I don't know if there is
an SMB/CIFS server spec, but one could imagine the same
thing happening there.

It might be possible to add ACL checking to the Windows
version of os.access, if a Windows person thinks it's
worthwhile.  It probably would be valuable to add a
clarification to the os.access doc.  For example:

Note that I/O operations may fail even when the access
function indicates that they would succeed, particularly for
operations on network filesystems, which may have
permissions semantics beyond the usual POSIX permission-bit
model.

(Also, if someone does this, please update the doc to note
that access returns True and False, not 1 and 0.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 15:59

Message:
Logged In: YES 
user_id=31435

Heh -- I didn't know it either, Thomas.  But I've also noticed 
how many new Windows bugs get assigned to you, and got 
curious enough to dig into it.

----------------------------------------------------------------------

Comment By: Mark Moales (mmoales)
Date: 2004-07-15 14:25

Message:
Logged In: YES 
user_id=565165

This may not be a bug afterall.  I think it has to do with 
Window's ACLs.  I believe os.access is just looking at access 
bits.  For example, I can create a directory and leave it as 
writable, but prevent access to it via an ACL.  In this case, 
os.access reports true, but any operation you try to perform 
on the dictionary get's a permission error.  It might just need 
to be mentioned in the os.access doc.

Thomas: no problem

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 14:20

Message:
Logged In: YES 
user_id=11105

Tim: I didn't know that.  Thanks for disabling it.

Mark: Sorry, it wasn't your fault.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 13:56

Message:
Logged In: YES 
user_id=31435

The tracker was set to auto-assign Windows reports to you, 
Thomas.  I disabled that (and Windows reports will be 
assigned to None by default now).

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-15 13:41

Message:
Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470
From noreply at sourceforge.net  Thu Jul 29 22:19:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Jul 29 22:19:08 2004
Subject: [ python-Bugs-870382 ] Mingw needs to use the same MSVC runtime as
	Python
Message-ID: <E1BqHMi-0005Hc-00@sc8-sf-web2.sourceforge.net>

Bugs item #870382, was opened at 2004-01-04 14:55
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470

Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. L?wis (loewis)
Summary: Mingw needs to use the same MSVC runtime as Python

Initial Comment:
Python 2.4 is now built with MSVC 7.1, which uses a 
new MSVC runtime library.

Extension DLLs should be built to use the same runtime 
DLL as Python itself (although it has not been possible 
to find a real-world example where not doing so causes 
a problem...)

The attached patch adds the appropriate -l flag to the 
link, based on the MSVC version reported in sys.version. 
(This has only been tested with a Python built with 
MSVC 7.1, the version number used for MSVC 7.0 is 
based on verbal reports only).

----------------------------------------------------------------------

>Comment By: Paul Moore (pmoore)
Date: 2004-07-29 21:19

Message:
Logged In: YES 
user_id=113328

Can someone suggest what I need to do to get this patch, or
something similar, accepted? As things stand, the official
Python 2.4 build *does not support* building compatible
extensions with mingw, where 2.3 did.

I have no means of extending this patch to work with
user-built versions of Python - I don't currently have any
way of building Python for myself, to test any such change.
I don't object to someone making such an extension, but I
have seen no-one step forward.

I'm getting a little frustrated here. The arguments against
applying the patch seem largely theoretical (and outside my
expertise). I'd like to invoke "practicality beats purity"
here...

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-07-16 12:19

Message:
Logged In: YES 
user_id=11105

In principle, it would be possible to examine the import
table of pythonxy.dll, to find out to which msvcrXX.dll it
is linked to.


----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-07-15 05:40

Message:
Logged In: YES 
user_id=552329

FWIW, this patch works for me, and I'd definitely like to
see it in 2.4a2.  If the MSVC version isn't 1300 or 1310
(the theoretical 1400, for example), then it doesn't do
anything different to what 2.4a1 does, so it's hard to see
why that would be a problem (and with the patch applied,
there's a clear fix, just adding in the appropriate elif and
link - it's not like new versions come along all the time).

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-07-09 12:17

Message:
Logged In: YES 
user_id=113328

This is still an issue with 2.4a1. I'm not sure what the 
autodetection buys given that currently it's not possible to 
build extensions with 2.4a1 using mingw which are compatible 
with the stock python.org binary.

Can I suggest that this patch be applied, and issues around 
autodetection be deferred until there is a demonstrated need?

I've uploaded a revised patch for 2.4a1 (tested against the 
python.org supplied MSI).

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-05 21:30

Message:
Logged In: YES 
user_id=21627

I'm primarily concerned about future
(unreleased-as-of-today) MSC versions; they likely have
version numbers like "1400"; linking msvcr71 to binaries
built with that compiler is likely wrong.

Not adding anything for gcc-built python versions is fine.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-04 23:01

Message:
Logged In: YES 
user_id=113328

What about Python built with mingw? I don't think that's 
possible right now, but I'd expect people to work on it. And 
I've no idea what sys.version for that would be.

The only real cases are likely to be MSVC 7.1 (Python 2.4, 
binary dist), MSVC 6 (Python <= 2.3, binary dist) and hand-
built Python versions. The patch does the right thing for all 
the binary distributions, which are the ones where the user 
can't be assumed to know how to hack things to make them 
work.

For hand-built versions, the user can do "python setup.py 
build_ext --compiler=mingw32 -l msvcr71" (or whatever) to 
manually specify the runtime to use. Leaving the default as 
msvcrt (the CRT that comes with the OS, and is default for 
mingw) seems right - and better than aborting (particularly as 
I'm not sure how to check whether there's an -l option for 
the CRT specified by the user).

The best I could do is effectively to force build_ext to fail 
unless Python was built with MSVC, which seems unhelpful...

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-01-04 15:03

Message:
Logged In: YES 
user_id=21627

Could you add some kind of assertion to detect the case that
an entirely different compiler version is used? It would be
best if it gets the case of using MSVC6 right, and gives up
if some other compiler version is detected (I can't
determine os.version for the VC6 case right now, but Python
2.3 is built with it).

Apart from that, the patch looks good.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 01:14:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 01:14:48 2004
Subject: [ python-Bugs-995458 ] Does not build selected SGI specific modules
Message-ID: <E1BqK6i-0000K5-00@sc8-sf-web4.sourceforge.net>

Bugs item #995458, was opened at 2004-07-21 14:55
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce D. Ray (brucedray)
Assigned to: Nobody/Anonymous (nobody)
Summary: Does not build selected SGI specific modules

Initial Comment:
System is SGI R10K running Irix 6.5.15
Compiler is MIPSpro 7.3

Default configuration build sequence works and installs
a python
2.3.4 that does not support GL, audio, etc. because the
SGI specific
modules for those are not built in the default
configuration.  To
quote the README:

     On SGI IRIX, there are modules that interface to
many SGI
     specific system libraries, e.g. the GL library and
the audio
     hardware.  These modules will not be built by the
setup.py
     script.

Therefore, after the default configuration build and
install, I
uncommented the lines in Modules/Setup that read:

     gl glmodule.c cgensupport.c -I$(srcdir) $(GLHACK)
-lgl -lX11
     fm fmmodule.c $(GLHACK) -lfm -lgl
     sgi sgimodule.c
     al almodule.c -laudio
     cd cdmodule.c -lcdaudio -lds -lmediad
     cl clmodule.c -lcl -lawareaudio
     fpectl fpectlmodule.c -lfpe
     fpetest fpetestmodule.c

I then did a  make clean   followed by   make

Errors returned were:

         cc   -o python                         Modules/python.o                         libpython2.3.a -ldl  -lpthread
-lmpc   -lm  
ld32: WARNING 84 : /usr/lib32/libdl.so is not used for
resolving any symbol.
ld32: WARNING 84 : /usr/lib32/mips4/libmpc.a is not
used for resolving any symbol.
ld32: ERROR   33 : Unresolved text symbol "initgl" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initfm" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initsgi" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "inital" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initcd" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initcl" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.
ld32: ERROR   33 : Unresolved text symbol "initfpectl"
-- 1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.   
ld32: ERROR   33 : Unresolved text symbol "initfpetest"
-- 1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.    
ld32: INFO    152: Output file removed because of error.
*** Error code 2 (bu21)


A previous message on the build said that I would have
to rerun
make   Therefore, I again did a  make clean   followed
by make
and got the error message:

     don't know how to make glmodule.c


How is this build to be done?



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-07-29 19:14

Message:
Logged In: YES 
user_id=593130

The appropriate place for how-to questions is 
comp.lang.python and the corresponding mailing list.  Please 
consider closing this until you are fairly sure you have found a 
bug in the distribution itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 01:29:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 01:29:09 2004
Subject: [ python-Bugs-928297 ] platform.libc_ver() fails on Cygwin
Message-ID: <E1BqKKa-0007KH-00@sc8-sf-web3.sourceforge.net>

Bugs item #928297, was opened at 2004-04-02 23:55
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: M.-A. Lemburg (lemburg)
Summary: platform.libc_ver() fails on Cygwin

Initial Comment:
>>> import platform
>>> platform.libc_ver()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/platform.py", line 134, in libc_ver
    f = open(executable,'rb')
IOError: [Errno 2] No such file or 
directory: '/usr/bin/python'

The problem is that on Cygwin sys.executable 
returns /path/to/python, but since Cygwin is running on 
Windows, sys.executable is a symbolic link 
to /path/to/python.exe.

>>> import os, sys
>>> os.path.exists(sys.executable)
True
>>> os.path.isfile(sys.executable)
True
>>> file(sys.executable)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or 
directory: '/usr/bin/python'
>>> os.path.islink(sys.executable)
True
>>> os.path.realpath(sys.executable)
'/usr/bin/python2.3.exe'
>>> file(sys.executable + '.exe')
<open file '/usr/bin/python.exe', mode 'r' at 0xa100ca0>

Following is the info about the machine I tested:

>>> from platform import *
>>> platform()
'CYGWIN_NT-5.0-1.5.7-0.109-3-2-i686-32bit'
>>> python_compiler()
'GCC 3.3.1 (cygming special)'
>>> python_build()
(1, 'Dec 30 2003 08:29:25')
>>> python_version()
'2.3.3'
>>> uname()
('CYGWIN_NT-5.0', 'my_user_name', '1.5.7
(0.109/3/2)', '2004-01-30 19:32', 'i686', '')


----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2004-07-30 08:29

Message:
Logged In: YES 
user_id=671362

Sorry for my late response, Marc.

> Would applying os.path.realpath() to sys.executable before
> trying to open that file fix the problem on Cygwin ?

That change fixes the IO problem. After this, it doesn't raise 
IOError. The result of platform.libc_ver() is as follows:

>>> import platform
>>> platform.libc_ver()
('', '')

> Another question: does using libc_ver() even make sense on
> cygwin ?

As far as I have checked, it doesn't look like so. According to 
the Cygwin FAQ[*], Cygwin doesn't use glibc, although it 
says that there's a counterpart(called ``newlib'') in Cygwin. C 
runtime embedded into cygwin1.dll uses newlib.

Experienced C & Cygwin programmers might anser this 
question more precisely.

[*] Where is glibc? :  
http://rustam.uwp.edu/support/faq.html#SEC88
   

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-23 19:34

Message:
Logged In: YES 
user_id=38388

Would applying os.path.realpath() to sys.executable before
trying to open that file fix the problem on Cygwin ?

Another question: does using libc_ver() even make sense on
cygwin ?

libc_ver() was never intended to be used on non-*nix
platforms. I don't even know whether it works on other
platforms than Linux.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2004-04-03 13:20

Message:
Logged In: YES 
user_id=671362

First, I need to correct my previous post. 'symbolic' was 
unrelated.
Python on Cygwin does't like exe files that doesn't end 
with '.exe'.
I think changing fileobject.c to support I/O exe files on 
Cygwin whether it ends with '.exe' or not is the way to go.

Is there anyone who can do that? It's beyoond my skill level.

$ ls -l /usr/bin/python*
lrwxrwxrwx  1 abel  Users    24 Jan  1 01:34 /usr/bin/python -
> python2.3.exe
lrwxrwxrwx  1 abel  Users    24 Jan  1 
01:34 /usr/bin/python.exe -> python2.3.exe
-rwxrwxrwx  1 abel  Users  4608 Dec 30 
22:32 /usr/bin/python2.3.exe

>>> file('/usr/bin/python')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: '/usr/bin/python'
>>> file('/usr/bin/python.exe')
<open file '/usr/bin/python.exe', mode 'r' at 0xa069320>
>>> file('/usr/bin/python2.3')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or 
directory: '/usr/bin/python2.3'
>>> file('/usr/bin/python2.3.exe')
<open file '/usr/bin/python2.3.exe', mode 'r' at 0xa0c8de0>

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-04-03 00:59

Message:
Logged In: YES 
user_id=38388

Patches are welcome :-)

I don't have cygwin installed, so there's nothing much
I can do about this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 01:38:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 01:38:07 2004
Subject: [ python-Bugs-995956 ] TclError with intel's hypertheading
Message-ID: <E1BqKTJ-00038I-00@sc8-sf-web2.sourceforge.net>

Bugs item #995956, was opened at 2004-07-22 10:49
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995956&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Haar (thaar)
Assigned to: Martin v. L?wis (loewis)
Summary: TclError with intel's hypertheading

Initial Comment:
If i use the "intel hyperthreading technologie", my
python application make a coredump with the output:

  File "C:\PROGRA~2\PYTHON~2\lib\lib-tk\Tkinter.py",
line 472, in after
    return self.tk.call('after', ms, name)
TclError: expected integer but got "9118984callit"

The test runs at the following system.
Microsoft windows 2000 5.00.2195 Service Pack 4
Intel Pentium 4 CPU 2.5 Ghz
522.988 KB RAM.


The error never occur, if i turn the hyperthreading in
the bios off.
I made the self test at 2 other pc with the same
hardware and configurations.  The result was the same.

I made another test with a linux pc, a laptop with xp
and a laptop with win2000. All without hyperthreading.
The error has not occured.

I add the log file and the test as attachment.



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-07-29 19:38

Message:
Logged In: YES 
user_id=593130

I believe TclError means that the error came from the 
embedded Tcl interpreter.  If so, and if the Pytyhon call 
ultimately feeds appropriate data to Tcl, the problem comes 
not from Python but one of Tcl, Win2000, or the chip, or the 
relationship between them.  If you are running current Python 
with current Tcl, the best we could do is add a warning to 
turn off Hyperthreading if strange errors occur, but I am not 
sure where.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995956&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 01:55:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 01:59:03 2004
Subject: [ python-Bugs-996259 ] readline function pointer with not tty's
Message-ID: <E1BqKkW-00081z-00@sc8-sf-web3.sourceforge.net>

Bugs item #996259, was opened at 2004-07-22 19:44
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996259&group_id=5470

Category: Parser/Compiler
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Lisandro Dalcin (dalcinl)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline function pointer with not tty's

Initial Comment:
In Python 2.3.x C/C++ API,  the souce file Parser/myreadline.c in 
function PyOS_Readline() says:
        
        /* This is needed to handle the unlikely case that the
         * interpreter is in interactive mode *and* stdin/out are not
         * a tty.  This can happen, for example if python is run like
         * this: python -i < test1.py
         */
        if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout)))
                rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt);
          else */
                rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout,
                                                     prompt);

When sys_stdin or sys_stdout are not a tty, there is not way of calling 
the readline function pointer.

I am working in a parallelized version of the Python interpreter, and I 
used the pointer to implement a specialized version of the readline 
function: it reads input in 'root' process (using the original readline 
function) and broadcasts string data to slaves. 

Some MPI implementations (i.e. MPICH) don seems to have stdin and 
stdout connected to a tty in processes other than the 'master' or 'root' 
one, being impossible to me to override the input mechanism.

My workaround was patching the sources, eliminating the if/else lines..

There is another way of handling the cases like
$ python -i < test1.py ????

Am I forgetting something?

Thanks in advance....

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-07-29 19:55

Message:
Logged In: YES 
user_id=593130

Are you reporting a bug you think the developers should fix, a 
patch you think they should apply, or merely asking for info?  
If the latter, please close this and ask elsewhere, such as 
comp.lang.python or maybe even the developer list.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996259&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 02:09:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 02:09:33 2004
Subject: [ python-Bugs-996259 ] readline function pointer with not tty's
Message-ID: <E1BqKxk-0001Zq-00@sc8-sf-web4.sourceforge.net>

Bugs item #996259, was opened at 2004-07-22 23:44
Message generated for change (Settings changed) made by dalcinl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996259&group_id=5470

Category: Parser/Compiler
Group: Feature Request
Status: Open
Resolution: None
>Priority: 1
Submitted By: Lisandro Dalcin (dalcinl)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline function pointer with not tty's

Initial Comment:
In Python 2.3.x C/C++ API,  the souce file Parser/myreadline.c in 
function PyOS_Readline() says:
        
        /* This is needed to handle the unlikely case that the
         * interpreter is in interactive mode *and* stdin/out are not
         * a tty.  This can happen, for example if python is run like
         * this: python -i < test1.py
         */
        if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout)))
                rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt);
          else */
                rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout,
                                                     prompt);

When sys_stdin or sys_stdout are not a tty, there is not way of calling 
the readline function pointer.

I am working in a parallelized version of the Python interpreter, and I 
used the pointer to implement a specialized version of the readline 
function: it reads input in 'root' process (using the original readline 
function) and broadcasts string data to slaves. 

Some MPI implementations (i.e. MPICH) don seems to have stdin and 
stdout connected to a tty in processes other than the 'master' or 'root' 
one, being impossible to me to override the input mechanism.

My workaround was patching the sources, eliminating the if/else lines..

There is another way of handling the cases like
$ python -i < test1.py ????

Am I forgetting something?

Thanks in advance....

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-07-29 23:55

Message:
Logged In: YES 
user_id=593130

Are you reporting a bug you think the developers should fix, a 
patch you think they should apply, or merely asking for info?  
If the latter, please close this and ask elsewhere, such as 
comp.lang.python or maybe even the developer list.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996259&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 02:39:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 02:39:13 2004
Subject: [ python-Bugs-998066 ] typo in os.popen4 documentation
Message-ID: <E1BqLQS-0000bF-00@sc8-sf-web3.sourceforge.net>

Bugs item #998066, was opened at 2004-07-26 10:04
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998066&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Chen (chen23)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in os.popen4 documentation

Initial Comment:
on the page:

http://www.python.org/doc/2.3.4/lib/module-popen2.html

it lists os.popen4 return as:

Returns the file objects (child_stdout_and_stderr, child_stdin)

in practice it would appear to be (Solaris):

Returns the file objects (child_stdin,child_stdout_and_stderr)



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-07-29 20:39

Message:
Logged In: YES 
user_id=593130

You (understandably) confused two nearly identical but 
different functions with two different return conventions 
(reversed from each other). 

>>> from os import popen4
>>> popen4
<built-in function popen4>
>>> popen2.popen4
<function popen4 at 0x00898768>

Module-popen2.html talks about popen2.popen4 and not 
os.popen4.

 Module popen2 has 3 functions popen2/3/4 which 
consistently return the read and write pipes in that order 
(well, popen3 is more complicated, but never mind).

  The os module also has functions of the same name but 
with reversed return order -- in/out -- as documented:
"This functionality is also available in the popen2 module using 
functions of the same names, but the return values of those 
functions have a different order."

Why ther reversal?  No idea.

The same hint/warning currently does NOT appear in the 
popen2 doc nor in its doc string (as accessed via help()) and 
I agree it should be.

Suggestion to doc fixer: in Lib Ref 6.8 popen2, end of 4th 
paragraph, ending in " or the equivalent functions in the os 
module." --
Add "(with reversed return tuples)" before the period.  
Without this caveat, they are not really equivalent, as Chen 
tripped over.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998066&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 03:05:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 03:05:10 2004
Subject: [ python-Bugs-1000439 ] optparse error method doesn't print option
	info
Message-ID: <E1BqLpb-0001L5-00@sc8-sf-web3.sourceforge.net>

Bugs item #1000439, was opened at 2004-07-29 21:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000439&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Nestlerode (nestler)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse error method doesn't print option info

Initial Comment:
When there is an error in optparse.OptionParser's
parse_args() method, (like if the user types an
argument to an option that doesn't take one), a terse
one-line error message is printed and the program exits.

I think it would be significantly more useful if the
option documentation were printed out too, but I have
no way to make this happen currently (since exit is
called).

Please expose a toggle to print out the option info
(that stuff that is printed with -h) when there is a
parsing error. It could probably be implemented as a
Boolean argument to the OptionParser constructor.

To illustrate what I'm talking about, consider a
program called mktoc that uses the optparse module for
its parsing. Here are two runs of it.

# This prints out the one-liner usage string and the
options details
$ mktoc -h
usage: mktoc [options] [showdirectoryname]

options:
  --version             show program's version number
and exit
  -h, --help            show this help message and exit
  -a, --auto            run automatically
  -bBAND, --band=BAND   specify the band manually
  -c, --cdrdao          output cdrdao TOC format (the
default)
  -d, --data            make a data disc instead of an
audio disc
  -k, --k3b             output K3B project format

# This only prints out the one-liner usage string which
is basically
# useless without the option details. This is what
comes out of the
# error() method of the parser object.
$ mktoc --cdrdao=foo
usage: mktoc [options] [showdirectoryname]

mktoc: error: --cdrdao option does not take a value

If it isn't clear, the reason I think the option info
should be printed is for usability (if the user is
confused enough to put arguments where they don't
belong or some such thing, they probably need the more
verbose message).

Thanks,
-Ivan



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000439&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 03:28:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 03:28:12 2004
Subject: [ python-Bugs-1000439 ] optparse error method doesn't print option
	info
Message-ID: <E1BqMBn-0003XF-00@sc8-sf-web4.sourceforge.net>

Bugs item #1000439, was opened at 2004-07-29 20:05
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000439&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Nestlerode (nestler)
>Assigned to: Greg Ward (gward)
Summary: optparse error method doesn't print option info

Initial Comment:
When there is an error in optparse.OptionParser's
parse_args() method, (like if the user types an
argument to an option that doesn't take one), a terse
one-line error message is printed and the program exits.

I think it would be significantly more useful if the
option documentation were printed out too, but I have
no way to make this happen currently (since exit is
called).

Please expose a toggle to print out the option info
(that stuff that is printed with -h) when there is a
parsing error. It could probably be implemented as a
Boolean argument to the OptionParser constructor.

To illustrate what I'm talking about, consider a
program called mktoc that uses the optparse module for
its parsing. Here are two runs of it.

# This prints out the one-liner usage string and the
options details
$ mktoc -h
usage: mktoc [options] [showdirectoryname]

options:
  --version             show program's version number
and exit
  -h, --help            show this help message and exit
  -a, --auto            run automatically
  -bBAND, --band=BAND   specify the band manually
  -c, --cdrdao          output cdrdao TOC format (the
default)
  -d, --data            make a data disc instead of an
audio disc
  -k, --k3b             output K3B project format

# This only prints out the one-liner usage string which
is basically
# useless without the option details. This is what
comes out of the
# error() method of the parser object.
$ mktoc --cdrdao=foo
usage: mktoc [options] [showdirectoryname]

mktoc: error: --cdrdao option does not take a value

If it isn't clear, the reason I think the option info
should be printed is for usability (if the user is
confused enough to put arguments where they don't
belong or some such thing, they probably need the more
verbose message).

Thanks,
-Ivan



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000439&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 16:00:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 16:00:16 2004
Subject: [ python-Bugs-995458 ] Does not build selected SGI specific modules
Message-ID: <E1BqXve-0003Fd-00@sc8-sf-web1.sourceforge.net>

Bugs item #995458, was opened at 2004-07-21 13:55
Message generated for change (Comment added) made by brucedray
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce D. Ray (brucedray)
Assigned to: Nobody/Anonymous (nobody)
Summary: Does not build selected SGI specific modules

Initial Comment:
System is SGI R10K running Irix 6.5.15
Compiler is MIPSpro 7.3

Default configuration build sequence works and installs
a python
2.3.4 that does not support GL, audio, etc. because the
SGI specific
modules for those are not built in the default
configuration.  To
quote the README:

     On SGI IRIX, there are modules that interface to
many SGI
     specific system libraries, e.g. the GL library and
the audio
     hardware.  These modules will not be built by the
setup.py
     script.

Therefore, after the default configuration build and
install, I
uncommented the lines in Modules/Setup that read:

     gl glmodule.c cgensupport.c -I$(srcdir) $(GLHACK)
-lgl -lX11
     fm fmmodule.c $(GLHACK) -lfm -lgl
     sgi sgimodule.c
     al almodule.c -laudio
     cd cdmodule.c -lcdaudio -lds -lmediad
     cl clmodule.c -lcl -lawareaudio
     fpectl fpectlmodule.c -lfpe
     fpetest fpetestmodule.c

I then did a  make clean   followed by   make

Errors returned were:

         cc   -o python                         Modules/python.o                         libpython2.3.a -ldl  -lpthread
-lmpc   -lm  
ld32: WARNING 84 : /usr/lib32/libdl.so is not used for
resolving any symbol.
ld32: WARNING 84 : /usr/lib32/mips4/libmpc.a is not
used for resolving any symbol.
ld32: ERROR   33 : Unresolved text symbol "initgl" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initfm" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initsgi" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "inital" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initcd" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.  
ld32: ERROR   33 : Unresolved text symbol "initcl" --
1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.
ld32: ERROR   33 : Unresolved text symbol "initfpectl"
-- 1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.   
ld32: ERROR   33 : Unresolved text symbol "initfpetest"
-- 1st referenced by libpython2.3.a(config.o).
        Use linker option -v to see when and which
objects, archives and dsos are loaded.    
ld32: INFO    152: Output file removed because of error.
*** Error code 2 (bu21)


A previous message on the build said that I would have
to rerun
make   Therefore, I again did a  make clean   followed
by make
and got the error message:

     don't know how to make glmodule.c


How is this build to be done?



----------------------------------------------------------------------

>Comment By: Bruce D. Ray (brucedray)
Date: 2004-07-30 09:00

Message:
Logged In: YES 
user_id=1063363

Would that be something like the message
(<http://groups.google.com/groups?q=author:Bruce+author:D.+author:Ray&hl=en&lr=&ie=UTF-8&scoring=r&as_drrb=b&as_mind=1&as_minm=7&as_miny=2004&as_maxd=30&as_maxm=7&as_maxy=2004&selm=spamtrap-1507041215070001%40physics.nmr.iupui.edu&rnum=1>)
I posted to comp.lang.python 15 Jul. 2004?

I posted that back before I managed to tease out of the various
convolutions of the build hints that there might be a
problem in the
construction of a Makefile that points the build to the
wrong directory.
As hinted at in that article, I had already done a search of
the publicly
available documentation on python (actually several searches
including
a download and grep of these).  I also did searches of
comp.lang.python for anything related to SGI, Silicon
Graphics, or
Irix; and of comp.sys.sgi.* for anything related to python
(if you wish
to reproduce this, you might want to exclude the strings
"dat" and
"tape" because of the many queries there on how to use a
Python brand
drive for archiving).

By 21 Jul. 2004, when I opened this, I was persuaded that I
have found
a bug in the build, or at least a deficiency in the
documentation for
build and install.

I believe that I have found a bug in the distribution with
respect to
building on SGI with MIPSpro 7.3 compilers a python with support
for available SGI functionality.  Thank-you kindly for your
reply, but
I really am reporting what appears to be a bug. 
Accordingly, I will
leave this open.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-07-29 18:14

Message:
Logged In: YES 
user_id=593130

The appropriate place for how-to questions is 
comp.lang.python and the corresponding mailing list.  Please 
consider closing this until you are fairly sure you have found a 
bug in the distribution itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 16:01:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 16:01:30 2004
Subject: [ python-Bugs-972724 ] Python 2.3.4, Solaris 7,
	socketmodule.c does not compile
Message-ID: <E1BqXwn-0003Ho-00@sc8-sf-web1.sourceforge.net>

Bugs item #972724, was opened at 2004-06-14 13:36
Message generated for change (Settings changed) made by brucedray
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=972724&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bruce D. Ray (brucedray)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3.4, Solaris 7, socketmodule.c does not compile

Initial Comment:
Build of Python 2.3.4 on Solaris 7 with SUN WorkshopPro
compilers
fails to compiile socketmodule.c with the following
error messages on the build:

"/export/home/bruce/python/Python-2.3.4/Modules/socketmodule.c",
line 2979: undefined symbol: AF_INET6
"/export/home/bruce/python/Python-2.3.4/Modules/socketmodule.c",
line 3023: undefined symbol: INET_ADDRSTRLEN
"/export/home/bruce/python/Python-2.3.4/Modules/socketmodule.c",
line 3023: integral constant expression expected
"/export/home/bruce/python/Python-2.3.4/Modules/socketmodule.c",
line 3053: warning: improper pointer/integer
combination: op "="
"/export/home/bruce/python/Python-2.3.4/Modules/socketmodule.c",
line 3062: warning: statement not reached
cc: acomp failed for
/export/home/bruce/python/Python-2.3.4/Modules/socketmodule.c


As a consequence of the above, make test gave errors
for every
test that attempted to import _socket



Other error messages in the build not related to the
socketmodule.c issue were:

"Objects/frameobject.c", line 301: warning:
non-constant initializer: op "--"
"Objects/frameobject.c", line 303: warning:
non-constant initializer: op "--"
"Objects/stringobject.c", line 1765: warning: statement
not reached
"Python/ceval.c", line 3427: warning: non-constant
initializer: op "--"
"Python/ceval.c", line 3550: warning: non-constant
initializer: op "--"
"Python/ceval.c", line 3551: warning: non-constant
initializer: op "--"
"/export/home/bruce/python/Python-2.3.4/Modules/pypcre.c",
line 995: warning: non-constant initializer: op "++"
"/export/home/bruce/python/Python-2.3.4/Modules/pypcre.c",
line 2574: warning: non-constant initializer: op "--"
"/export/home/bruce/python/Python-2.3.4/Modules/unicodedata.c",
line 313: warning: non-constant initializer: op "--"
"/export/home/bruce/python/Python-2.3.4/Modules/parsermodule.c",
line 2493: warning: non-constant initializer: op "++"

"/export/home/bruce/python/Python-2.3.4/Modules/expat/xmlparse.c",
line 3942: warning: non-constant initializer: op "<<="




Configuration output was:

checking MACHDEP... sunos5
checking EXTRAPLATDIR... 
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for c++... no
checking for g++... no
checking for gcc... no
checking for CC... CC
checking for C++ compiler default output... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for gcc... no
checking for cc... cc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc accepts -g... yes
checking for cc option to accept ANSI C... none needed
checking how to run the C preprocessor... cc -E
checking for egrep... egrep
checking for AIX... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... no
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking for --with-suffix... 
checking for case-insensitive build directory... no
checking LIBRARY... libpython$(VERSION).a
checking LINKCC... $(PURIFY) $(CC)
checking for --enable-shared... no
checking LDLIBRARY... libpython$(VERSION).a
checking for ranlib... ranlib
checking for ar... ar
checking for a BSD-compatible install... ./install-sh -c
checking for --with-pydebug... no
checking whether cc accepts -OPT:Olimit=0... no
checking whether cc accepts -Olimit 1500... no
checking whether pthreads are available without
options... no
checking whether cc accepts -Kpthread... no
checking whether cc accepts -Kthread... no
checking whether cc accepts -pthread... no
checking whether CC also accepts flags for thread
support... no
checking for ANSI C header files... (cached) yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking langinfo.h usability... yes
checking langinfo.h presence... yes
checking for langinfo.h... yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking ncurses.h usability... no
checking ncurses.h presence... no
checking for ncurses.h... no
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking stdarg.h usability... yes
checking stdarg.h presence... yes
checking for stdarg.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking stropts.h usability... yes
checking stropts.h presence... yes
checking for stropts.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking thread.h usability... yes
checking thread.h presence... yes
checking for thread.h... yes
checking for unistd.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking sys/audioio.h usability... yes
checking sys/audioio.h presence... yes
checking for sys/audioio.h... yes
checking sys/bsdtty.h usability... no
checking sys/bsdtty.h presence... no
checking for sys/bsdtty.h... no
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking sys/lock.h usability... yes
checking sys/lock.h presence... yes
checking for sys/lock.h... yes
checking sys/mkdev.h usability... yes
checking sys/mkdev.h presence... yes
checking for sys/mkdev.h... yes
checking sys/modem.h usability... no
checking sys/modem.h presence... no
checking for sys/modem.h... no
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking pty.h usability... no
checking pty.h presence... no
checking for pty.h... no
checking term.h usability... no
checking term.h presence... yes
configure: WARNING: term.h: present but cannot be compiled
configure: WARNING: term.h: check for missing
prerequisite headers?
configure: WARNING: term.h: proceeding with the
preprocessor's result
configure: WARNING:     ##
------------------------------------ ##
configure: WARNING:     ## Report this to
bug-autoconf@gnu.org. ##
configure: WARNING:     ##
------------------------------------ ##
checking for term.h... yes
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking netpacket/packet.h usability... no
checking netpacket/packet.h presence... no
checking for netpacket/packet.h... no
checking sysexits.h usability... yes
checking sysexits.h presence... yes
checking for sysexits.h... yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking whether sys/types.h defines makedev... no
checking for sys/mkdev.h... (cached) yes
checking for clock_t in time.h... yes
checking for makedev... no
checking Solaris LFS bug... no
checking for mode_t... yes
checking for off_t... yes
checking for pid_t... yes
checking return type of signal handlers... void
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 4
checking for void *... yes
checking size of void *... 4
checking for char... yes
checking size of char... 1
checking for short... yes
checking size of short... 2
checking for float... yes
checking size of float... 4
checking for double... yes
checking size of double... 8
checking for fpos_t... yes
checking size of fpos_t... 8
checking for long long support... yes
checking for long long... yes
checking size of long long... 8
checking for uintptr_t support... no
checking size of off_t... 8
checking whether to enable large file support... yes
checking size of time_t... 4
checking for pthread_t... yes
checking size of pthread_t... 4
checking for --enable-toolbox-glue... no
checking for --enable-framework... no
checking for dyld... no
checking SO... .so
checking LDSHARED... $(CC) -G
checking CCSHARED... 
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking SHLIBS... $(LIBS)
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for library containing sem_init... -lrt
checking for textdomain in -lintl... yes
checking for t_open in -lnsl... yes
checking for socket in -lsocket... yes
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking cthreads.h usability... no
checking cthreads.h presence... no
checking for cthreads.h... no
checking mach/cthreads.h usability... no
checking mach/cthreads.h presence... no
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking for usconfig in -lmpc... no
checking if PTHREAD_SCOPE_SYSTEM is supported... yes
checking for pthread_sigmask... yes
checking if --enable-ipv6 is specified... no
checking for --with-universal-newlines... yes
checking for --with-doc-strings... yes
checking for --with-pymalloc... yes
checking for --with-wctype-functions... no
checking for --with-sgi-dl... no
checking for --with-dl-dld... no
checking for dlopen... yes
checking DYNLOADFILE... dynload_shlib.o
checking MACHDEP_OBJS... MACHDEP_OBJS
checking for alarm... yes
checking for chown... yes
checking for clock... yes
checking for confstr... yes
checking for ctermid... yes
checking for execv... yes
checking for fork... yes
checking for fpathconf... yes
checking for ftime... yes
checking for ftruncate... yes
checking for gai_strerror... no
checking for getgroups... yes
checking for getlogin... yes
checking for getloadavg... yes
checking for getpeername... yes
checking for getpgid... yes
checking for getpid... yes
checking for getpriority... yes
checking for getpwent... yes
checking for getwd... yes
checking for kill... yes
checking for killpg... yes
checking for lchown... yes
checking for lstat... yes
checking for mkfifo... yes
checking for mknod... yes
checking for mktime... yes
checking for mremap... no
checking for nice... yes
checking for pathconf... yes
checking for pause... yes
checking for plock... yes
checking for poll... yes
checking for pthread_init... no
checking for putenv... yes
checking for readlink... yes
checking for realpath... yes
checking for select... yes
checking for setegid... yes
checking for seteuid... yes
checking for setgid... yes
checking for setlocale... yes
checking for setregid... yes
checking for setreuid... yes
checking for setsid... yes
checking for setpgid... yes
checking for setpgrp... yes
checking for setuid... yes
checking for setvbuf... yes
checking for snprintf... yes
checking for sigaction... yes
checking for siginterrupt... yes
checking for sigrelse... yes
checking for strftime... yes
checking for strptime... yes
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for tcsetpgrp... yes
checking for tempnam... yes
checking for timegm... no
checking for times... yes
checking for tmpfile... yes
checking for tmpnam... yes
checking for tmpnam_r... yes
checking for truncate... yes
checking for uname... yes
checking for unsetenv... no
checking for utimes... yes
checking for waitpid... yes
checking for wcscoll... yes
checking for _getpty... no
checking for chroot... yes
checking for link... yes
checking for symlink... yes
checking for fchdir... yes
checking for fsync... yes
checking for fdatasync... yes
checking for ctermid_r... no
checking for flock... no
checking for getpagesize... yes
checking for true... true
checking for inet_aton in -lc... no
checking for inet_aton in -lresolv... yes
checking for hstrerror... yes
checking for inet_aton... yes
checking for inet_pton... yes
checking for setgroups... yes
checking for openpty... no
checking for openpty in -lutil... no
checking for forkpty... no
checking for forkpty in -lutil... no
checking for fseek64... no
checking for fseeko... yes
checking for fstatvfs... yes
checking for ftell64... no
checking for ftello... yes
checking for statvfs... yes
checking for dup2... yes
checking for getcwd... yes
checking for strdup... yes
checking for strerror... yes
checking for memmove... yes
checking for getpgrp... yes
checking for setpgrp... (cached) yes
checking for gettimeofday... yes
checking for major... yes
checking for getaddrinfo... no
checking for getnameinfo... no
checking whether time.h and sys/time.h may both be
included... yes
checking whether struct tm is in sys/time.h or
time.h... time.h
checking for struct tm.tm_zone... no
checking for tzname... yes
checking for struct stat.st_rdev... yes
checking for struct stat.st_blksize... yes
checking for struct stat.st_blocks... yes
checking for time.h that defines altzone... no
checking whether sys/select.h and sys/time.h may both
be included... yes
checking for addrinfo... no
checking for sockaddr_storage... no
checking whether char is unsigned... no
checking for an ANSI C-conforming const... yes
checking for working volatile... yes
checking for working signed char... yes
checking for prototypes... yes
checking for variable length prototypes and stdarg.h... yes
checking for bad exec* prototypes... no
checking if sockaddr has sa_len member... no
checking whether va_list is an array... no
checking for gethostbyname_r... yes
checking gethostbyname_r with 6 args... no
checking gethostbyname_r with 5 args... yes
checking for __fpu_control... no
checking for __fpu_control in -lieee... no
checking for --with-fpectl... no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for hypot... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... 4
checking for UCS-4 tcl... no
checking what type to use for unicode... unsigned short
checking whether byte ordering is bigendian... yes
checking whether right shift extends the sign bit... yes
checking for getc_unlocked() and friends... yes
checking for rl_pre_input_hook in -lreadline... no
checking for rl_completion_matches in -lreadline... no
checking for broken nice()... no
checking for broken poll()... no
checking for working tzset()... no
checking for tv_nsec in struct stat... yes
checking whether mvwdelch is an expression... yes
checking whether WINDOW has _flags... yes
checking for /dev/ptmx... yes
checking for /dev/ptc... no
checking for socklen_t... yes
checking for build directories... done
configure: creating ./config.status
config.status: creating Makefile.pre
config.status: creating Modules/Setup.config
config.status: creating pyconfig.h
creating Setup
creating Setup.local
creating Makefile


----------------------------------------------------------------------

Comment By: Bruce D. Ray (brucedray)
Date: 2004-06-29 16:30

Message:
Logged In: YES 
user_id=1063363

I've checked further, and there is a problem in Sun's headers as
supplied with Solaris 7 Server 5/99 edition that the
standard set of
free patches apparently does not address.  For this edition
of Solaris 7,
sys/socket.h does not have either AF_INET6 or INET_ADDRSTRLEN
defined (seen on multiple systems).  socketmodule.c will compile
correctly with SunWorkshopPro 5.0 compilers and passes test
if the
following lines are added prior to the first function in
socketmodule.c:

#ifndef AF_INET6            /* not present in some Solaris 7
versions */
#define AF_INET6 26       /* use the Solaris 8 sys/socket.h
definition */
#endif

#ifndef INET_ADDRSTRLEN     /* not present in some Solaris 7
versions */
#define INET_ADDRSTRLEN 16   /* use the definition given for
SGI above */
#endif




----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-06-18 06:36

Message:
Logged In: YES 
user_id=29957

Hm. I don't get this on Solaris 7 using GCC. Can you try
with gcc, and see if the problem is in Sun's headers on your
system, or with the Sun compiler?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=972724&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 17:04:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 17:04:32 2004
Subject: [ python-Bugs-786970 ] re doesn't like (^$)*
Message-ID: <E1BqYvq-0007rn-00@sc8-sf-web2.sourceforge.net>

Bugs item #786970, was opened at 2003-08-11 15:21
Message generated for change (Comment added) made by mkc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786970&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Fredrik Lundh (effbot)
Summary: re doesn't like (^$)*

Initial Comment:
Nor, for that matter, does it like &quot;(^)*&quot;

% python
Python 2.3 (#1, Aug  3 2003, 02:47:49) 
[GCC 3.1 20020420 (prerelease)] on darwin
&gt;&gt;&gt; import re
&gt;&gt;&gt; re.compile(&quot;(^$)*&quot;).match(&quot;&quot;)
Segmentation fault
%

It's trying real hard to match 0 characters an infinite
number of time.  :)

The segfault is caused in part by the low stacksize limit
on my OS X machine,

% limit stacksize
stacksize       512 kbytes
% limit stacksize 2000kbytes
% limit stacksize
stacksize       2000 kbytes
% python
Python 2.3 (#1, Aug  3 2003, 02:47:49) 
[GCC 3.1 20020420 (prerelease)] on darwin
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more 
information.
&gt;&gt;&gt; import re
&gt;&gt;&gt; re.compile(&quot;(^$)*&quot;).match(&quot;&quot;)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
RuntimeError: maximum recursion limit exceeded
&gt;&gt;&gt; 

which suggests that the stack recursion limit
test for the re library is not the same as the one
used for the rest of Python.  (def f(): f() gives
me the expected recursion limit, and not a
segfault)

Seems like the bug could be in several places:
  - the compiler doesn't handle infinite loops of
      zero-character tests well (it could convert
      them to a finite-loop test)
  - the re matcher doesn't check that it's been
      in the same place several times without
      advancing any character positions
  - the re matcher doesn't use the same stack
     check used elsewhere in Python
  - the Mac stacksize default is too low for
     Python's 

BTW, checking pcre ...

&gt;&gt;&gt; import pre
/usr/local/lib/python2.3/pre.py:94: DeprecationWarning: 
Please use the 're' module, not the 'pre' module
  DeprecationWarning)
&gt;&gt;&gt; pre.compile(&quot;(^$)*&quot;).match(&quot;&quot;)
Traceback (most recent call last):
  File &quot;&lt;stdin&gt;&quot;, line 1, in ?
  File &quot;/usr/local/lib/python2.3/pre.py&quot;, line 251, in compile
    code=pcre_compile(pattern, flags, groupindex)
pcre.error: ('operand of unlimited repeat could match the 
empty string', 4)
&gt;&gt;&gt; 

which is true, but the pattern I used should (IMHO)
be allowed to match the empty string.


----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2004-07-30 10:04

Message:
Logged In: YES 
user_id=555

I was able to reproduce this under Linux (by setting the
stack limit to 512k) under Python 2.3.2.  The specific case
seems to be fixed in the current CVS head; I don't get
problems until I reduce the stack limit below 64k, at which
point the import of 're' fails.  So, to the degree that this
was caused by heavy use of the C stack, perhaps this has
been fixed.

As the submitter suggests, the limit being bumped into here
is not the Python recursion limit, but the underlying C
stack limit.  AFAIK, the Python recursion limit is not
checked within C modules (and I doubt it would be reasonable
to add this).

In principle it seems like it would be nice if Python could
throw a MemoryException when the C stack limit is exceeded,
but it's not clear how this could be done or whether it
would be worthwhile.  Guido is already on record (I think)
as being against longjmp, which seems like the only portable
way to implement it.  It might be possible to emit a short
diagnostic (e.g., 'stack limit exceeded') before aborting,
but this would entail adding some sigaltstack mechanism that
probably wouldn't be portable to non-POSIX and might well
make debugging real SIGSEGV's or runaway C recursion more
difficult.

My suggestion would be to close this bug, perhaps after
adding a bit of documentation regarding how Python handles
this case (i.e., it relies on the default behavior, like 99%
of other programs).  If there's a desire to add
functionality to handle the stack limit in a different way,
that could be proposed on python-dev or as an RFE.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786970&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 20:01:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 20:01:37 2004
Subject: [ python-Bugs-1000841 ] "make pdf" failure w/ 2.4 docs
Message-ID: <E1BqbhF-0006Zr-00@sc8-sf-web2.sourceforge.net>

Bugs item #1000841, was opened at 2004-07-30 11:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mat Martineau (martineau)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make pdf" failure w/ 2.4 docs

Initial Comment:
When attempting to build the pdf version of the 
documentation from CVS, I get the following 
error: 
 
(/.../python/dist/src/Doc/lib/libxmlrpclib.tex 
... 
! TeX capacity exceeded, sorry [input stack 
size=1500]. 
\font@name -> 
             \OT1/phv/m/n/10 
l.259 ...//www.xmlrpc.com/discuss/msgReader\208} 
                                                  , an 
approach 
!  ==> Fatal error occurred, the output PDF file 
is not finished! 
 
The '$' in line 259 of libxmlrpclib.tex seems to 
trip up pdflatex.  If '%24' is substituted for '$', 
the link still works, and lib.pdf will build. 
 
Info about my version of pdflatex & linux: 
$ pdflatex --version 
pdfTeX (Web2C 7.4.5) 3.14159-1.10b 
kpathsea version 3.4.5 
... 
$ cat /proc/version 
Linux version 2.6.5-7.95-default 
(geeko@buildhost) (gcc version 3.3.3 (SuSE 
Linux)) #1 Thu Jul 1 15:23:45 UTC 2004 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 22:18:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 22:18:08 2004
Subject: [ python-Bugs-1000914 ] Carbon.CF.CFMutableArray hangs interpreter
Message-ID: <E1BqdpL-0002Sg-00@sc8-sf-web2.sourceforge.net>

Bugs item #1000914, was opened at 2004-07-30 22:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470

Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.CF.CFMutableArray hangs interpreter

Initial Comment:
$ /opt/python2.4/bin/python
Python 2.4a1+ (#1, Jul 30 2004, 20:22:17) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> from Carbon.CF import *
>>> c = CFArrayCreateMutable(0)
>>> isinstance(c, CFMutableArrayRef)
True
>>> del c

The interpreter hangs after deleting c. This also happens when the 
call to isinstance is left out.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470
From noreply at sourceforge.net  Fri Jul 30 22:27:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Jul 30 22:27:33 2004
Subject: [ python-Bugs-1000914 ] Carbon.CF.CFMutableArray hangs interpreter
Message-ID: <E1BqdyN-0005oD-00@sc8-sf-web3.sourceforge.net>

Bugs item #1000914, was opened at 2004-07-30 22:18
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470

Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.CF.CFMutableArray hangs interpreter

Initial Comment:
$ /opt/python2.4/bin/python
Python 2.4a1+ (#1, Jul 30 2004, 20:22:17) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> from Carbon.CF import *
>>> c = CFArrayCreateMutable(0)
>>> isinstance(c, CFMutableArrayRef)
True
>>> del c

The interpreter hangs after deleting c. This also happens when the 
call to isinstance is left out.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-07-30 22:27

Message:
Logged In: YES 
user_id=580910

when I use gdb to check where the program hangs I always end up in 
CFArrayRefObj_dealloc. This also happens when I continue to program 
and break again later on.

It doesn't seem to be infinite recursion, the stack is 8 levels deep with 
the code mentioned earlier.

However:
(gdb) where
#0  0x00551f98 in CFArrayRefObj_dealloc (self=0x37f0e0) at /Volumes/
Data/Users/ronald/Software/python-HEAD/dist/src/Mac/Modules/cf/
_CFmodule.c:525
#1  0x0008879c in PyEval_EvalFrame (f=0x60d820) at Python/ceval.c:
1662
#2  0x0008a4bc in PyEval_EvalCodeEx (co=0x2, globals=0x59e54, 
locals=0x552308, args=0x16c, argcount=6312944, kws=0x874a0, 
kwcount=1, defs=0x60d96c, defcount=0, closure=0x0) at Python/
ceval.c:2697
#3  0x0008d648 in PyEval_EvalCode (co=0x37f0e0, globals=0x59e54, 
locals=0x55e1d4) at Python/ceval.c:448
#4  0x0000c9a0 in run_node (n=0x16c, filename=0x59e54 "\201^", 
globals=0x2, locals=0x60d96c, flags=0x0) at Python/pythonrun.c:1255
#5  0x0000c128 in PyRun_SimpleFileExFlags (fp=0xa0009818, 
filename=0xbffffc9e "t.py", closeit=6346784, flags=0x377a92) at Python/
pythonrun.c:850
#6  0x00006328 in Py_Main (argc=3533392, argv=0xbffffc9e) at 
Modules/main.c:413
#7  0x00001ee4 in _start (argc=3533392, argv=0xa0009818, 
envp=0xbffffc9e) at /SourceCache/Csu/Csu-46/crt.c:267
#8  0x00001d58 in start ()
(gdb) p self
$3 = (CFArrayRefObject *) 0x37f0e0
(gdb) p *self
$4 = {
  ob_refcnt = 0, 
  ob_type = 0x55e2e4, 
  ob_itself = 0x0, 
  ob_freeit = 0x90190b98 <CFRelease>
}
(gdb) p self->ob_type->tp_base
$5 = (struct _typeobject *) 0x55e1d4
(gdb) p self->ob_type->tp_base->tp_dealloc
$6 = 0x551f48 <CFArrayRefObj_dealloc>
(gdb) 

And CFArrayRefObj_dealloc is:

static void CFArrayRefObj_dealloc(CFArrayRefObject *self)
{
        if (self->ob_freeit && self->ob_itself)
        {
                self->ob_freeit((CFTypeRef)self->ob_itself);
                self->ob_itself = NULL;
        }
        self->ob_type->tp_base->tp_dealloc((PyObject *)self);
}

BTW: Python 2.4a1+ from anon-CVS as of today, running on OSX 10.3.4 
with Xcode 1.2 (gcc 3.3)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 02:08:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 02:08:18 2004
Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ])
	misbehaves
Message-ID: <E1BqhQ2-0003vL-00@sc8-sf-web3.sourceforge.net>

Bugs item #1001011, was opened at 2004-07-31 02:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Wouters (twouters)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.join([ str-subtype-instance ]) misbehaves

Initial Comment:
Joining a list of string subtype instances usually
results in a single string instance:

  >>> class mystr(str): pass
  >>> type("".join([mystr("a"), mystr("b")]))
  <type 'str'>

But if the list only contains one object that is a
string subtype instance, that instance is returned
unchanged:

  >>> type("".join([mystr("a")]))
  <class '__main__.mystr'>

This can have odd effects, for instance when the result
of "".join(lst) is used as the returnvalue of a __str__
hook. "".join should perhaps return the type of the
joining string, but definately vary its type based on
the *number* of items its joining.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 03:07:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 03:07:20 2004
Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary
	timeouts on connect err
Message-ID: <E1BqiLF-0007fl-00@sc8-sf-web1.sourceforge.net>

Bugs item #1001018, was opened at 2004-07-31 11:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: setdefaulttimeout causes unnecessary timeouts on connect err

Initial Comment:
This looks like a bug to me:

>>> import socket, httplib
>>> socket.setdefaulttimeout(10)
>>> httplib.HTTPConnection("www.python.org",
9999).connect()
[.... 10 second delay ....]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "e:\src\python-cvs\lib\httplib.py", line 548, in
connect
    raise socket.error, msg
socket.timeout: timed out
>>>

On Linux, there is no significant delay, and the
traceback reads:
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/httplib.py", line 548,
in connect
    raise socket.error, msg
socket.error: (111, 'Connection refused')

The linux result is what I expected on Windows. 
Sockets aren't my strong point, so I'd prefer someone
confirming it is a real bug before I burn too much time
on it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 05:17:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 05:17:40 2004
Subject: [ python-Bugs-1001053 ] wave.open() with unicode filename fails
Message-ID: <E1BqkNN-0007l6-00@sc8-sf-web4.sourceforge.net>

Bugs item #1001053, was opened at 2004-07-31 03:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001053&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Popplewell (johnnypops)
Assigned to: Nobody/Anonymous (nobody)
Summary: wave.open() with unicode filename fails

Initial Comment:
If you pass a unicode string to wave.open() it is treated as if it 
was an open file object and fails with an AttributeError. For 
example, the following code behaves correctly: 
 
import wave 
f = wave.open("sound.wav", "r") 
 
but this fails: 
 
import wave 
f = wave.open(u"sound.wav", "r") 
 
... 
AttributeError: 'unicode' object has no attribute 'read' 
 
The error occurs twice in the file 'wave.py' in the __init__ functions 
for Wave_read and Wave_write. 
 
I was playing with the unicode version of wxPython on Windows 
XP at the time, but the bug applies to other platforms as well.  
 
Hope the patch is of use, 
 
best regards, 
John. 
 
---8<--------------------------------------------------------------- 
158c158 
<         if type(f) == type(''): 
--- 
>         if isinstance(f, basestring): 
297c297 
<         if type(f) == type(''): 
--- 
>         if isinstance(f, basestring): 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001053&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 08:17:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 08:17:13 2004
Subject: [ python-Bugs-1001088 ] incorrect reference to macro named foo
Message-ID: <E1BqnB7-0005QG-00@sc8-sf-web1.sourceforge.net>

Bugs item #1001088, was opened at 2004-07-31 06:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001088&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Clinton Roy (clintonroy)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect reference to macro named foo

Initial Comment:
Hi guys,

In _Documenting Python_, section 4.1 Syntax, a
paragraph begins:

 For example, a macro named ``foo'' which takes a
single parameter would appear like this:

But the example macros use the name `name' instead of
`foo'. 

Since it's quite obvious what's going on, I suggest the
reference to foo is lost, so the leading sentence becomes:

For example, a macro wich takes a single parameter
would appear like this:

cheers,

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001088&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 08:45:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 08:48:29 2004
Subject: [ python-Bugs-1001088 ] incorrect reference to macro named foo
Message-ID: <E1Bqnc8-0000Ul-00@sc8-sf-web2.sourceforge.net>

Bugs item #1001088, was opened at 2004-07-31 15:17
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001088&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Clinton Roy (clintonroy)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect reference to macro named foo

Initial Comment:
Hi guys,

In _Documenting Python_, section 4.1 Syntax, a
paragraph begins:

 For example, a macro named ``foo'' which takes a
single parameter would appear like this:

But the example macros use the name `name' instead of
`foo'. 

Since it's quite obvious what's going on, I suggest the
reference to foo is lost, so the leading sentence becomes:

For example, a macro wich takes a single parameter
would appear like this:

cheers,

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2004-07-31 15:45

Message:
Logged In: YES 
user_id=671362

FYI, this is the address of the page Clinton is talking about.
http://www.python.org/doc/2.3.4/doc/latex-syntax.html
http://www.python.org/dev/doc/devel/doc/latex-syntax.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001088&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 12:50:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 12:50:42 2004
Subject: [ python-Bugs-1001150 ] hotspot profiler does not work correctly on
	P4 CPUs with HT
Message-ID: <E1BqrRn-0002qi-00@sc8-sf-web1.sourceforge.net>

Bugs item #1001150, was opened at 2004-07-31 12:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001150&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotspot profiler does not work correctly on P4 CPUs with HT

Initial Comment:
Using the hotspot module produces wrong timing data on
Intel P4 CPUs with HyperThreading (HT) support enabled.
For example:

Running tests...
..................................................
----------------------------------------------------------------------
Ran 50 tests in 1.782s

OK
Loading results...
Printing results...
         24087 function calls (23727 primitive calls)
in 5333.530 CPU seconds

The 50 tests run in 1.782 seconds, but the profiler
accumulates 5333.530 seconds.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001150&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 15:25:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 15:25:22 2004
Subject: [ python-Bugs-1001150 ] hotspot profiler does not work correctly on
	P4 CPUs with HT
Message-ID: <E1BqtrL-0006ou-00@sc8-sf-web1.sourceforge.net>

Bugs item #1001150, was opened at 2004-07-31 12:50
Message generated for change (Comment added) made by complex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001150&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotspot profiler does not work correctly on P4 CPUs with HT

Initial Comment:
Using the hotspot module produces wrong timing data on
Intel P4 CPUs with HyperThreading (HT) support enabled.
For example:

Running tests...
..................................................
----------------------------------------------------------------------
Ran 50 tests in 1.782s

OK
Loading results...
Printing results...
         24087 function calls (23727 primitive calls)
in 5333.530 CPU seconds

The 50 tests run in 1.782 seconds, but the profiler
accumulates 5333.530 seconds.

----------------------------------------------------------------------

>Comment By: Viktor Ferenczi (complex)
Date: 2004-07-31 15:25

Message:
Logged In: YES 
user_id=142612

OS: WinXP Prof ENG SP1
Python: 2.3.4 final, EXE installer (binary)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001150&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 16:56:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 16:56:22 2004
Subject: [ python-Bugs-1001150 ] hotspot profiler does not work correctly on
	P4 CPUs with HT
Message-ID: <E1BqvHP-0005cD-00@sc8-sf-web3.sourceforge.net>

Bugs item #1001150, was opened at 2004-07-31 06:50
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001150&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotspot profiler does not work correctly on P4 CPUs with HT

Initial Comment:
Using the hotspot module produces wrong timing data on
Intel P4 CPUs with HyperThreading (HT) support enabled.
For example:

Running tests...
..................................................
----------------------------------------------------------------------
Ran 50 tests in 1.782s

OK
Loading results...
Printing results...
         24087 function calls (23727 primitive calls)
in 5333.530 CPU seconds

The 50 tests run in 1.782 seconds, but the profiler
accumulates 5333.530 seconds.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-31 10:56

Message:
Logged In: YES 
user_id=33168

There have been a few changes to hotshot which could fix
this problem.  Can you test the current version in CVS?  I'm
not sure if 2.4a1 has the fixes or not, but you could also
try that version.

Also, what test are you using?  test_hotshot only has 3 tests.

----------------------------------------------------------------------

Comment By: Viktor Ferenczi (complex)
Date: 2004-07-31 09:25

Message:
Logged In: YES 
user_id=142612

OS: WinXP Prof ENG SP1
Python: 2.3.4 final, EXE installer (binary)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001150&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 17:02:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 17:02:10 2004
Subject: [ python-Bugs-1000841 ] "make pdf" failure w/ 2.4 docs
Message-ID: <E1BqvN3-0005k3-00@sc8-sf-web3.sourceforge.net>

Bugs item #1000841, was opened at 2004-07-30 13:01
Message generated for change (Comment added) made by aisaac0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mat Martineau (martineau)
Assigned to: Nobody/Anonymous (nobody)
Summary: "make pdf" failure w/ 2.4 docs

Initial Comment:
When attempting to build the pdf version of the 
documentation from CVS, I get the following 
error: 
 
(/.../python/dist/src/Doc/lib/libxmlrpclib.tex 
... 
! TeX capacity exceeded, sorry [input stack 
size=1500]. 
\font@name -> 
             \OT1/phv/m/n/10 
l.259 ...//www.xmlrpc.com/discuss/msgReader\208} 
                                                  , an 
approach 
!  ==> Fatal error occurred, the output PDF file 
is not finished! 
 
The '$' in line 259 of libxmlrpclib.tex seems to 
trip up pdflatex.  If '%24' is substituted for '$', 
the link still works, and lib.pdf will build. 
 
Info about my version of pdflatex & linux: 
$ pdflatex --version 
pdfTeX (Web2C 7.4.5) 3.14159-1.10b 
kpathsea version 3.4.5 
... 
$ cat /proc/version 
Linux version 2.6.5-7.95-default 
(geeko@buildhost) (gcc version 3.3.3 (SuSE 
Linux)) #1 Thu Jul 1 15:23:45 UTC 2004 

----------------------------------------------------------------------

Comment By: Alan (aisaac0)
Date: 2004-07-31 10:02

Message:
Logged In: YES 
user_id=1025672

Hopefully a bug from the 2.3 docs can be fixed at the same time.
The PDF production tries to set the vertical bar '|' in textmode
rather than math mode.  An example of this problem is the
documentation for set union, which looks like s--t instead
of s|t.

Should I submit this as a separate bug?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470
From noreply at sourceforge.net  Sat Jul 31 20:03:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Jul 31 20:03:26 2004
Subject: [ python-Bugs-1001150 ] hotspot profiler does not work correctly on
	P4 CPUs with HT
Message-ID: <E1BqyCT-0001vi-00@sc8-sf-web3.sourceforge.net>

Bugs item #1001150, was opened at 2004-07-31 06:50
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001150&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotspot profiler does not work correctly on P4 CPUs with HT

Initial Comment:
Using the hotspot module produces wrong timing data on
Intel P4 CPUs with HyperThreading (HT) support enabled.
For example:

Running tests...
..................................................
----------------------------------------------------------------------
Ran 50 tests in 1.782s

OK
Loading results...
Printing results...
         24087 function calls (23727 primitive calls)
in 5333.530 CPU seconds

The 50 tests run in 1.782 seconds, but the profiler
accumulates 5333.530 seconds.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-31 14:03

Message:
Logged In: YES 
user_id=33168

There have been a few changes to hotshot which could fix
this problem.  Can you test the current version in CVS?  I'm
not sure if 2.4a1 has the fixes or not, but you could also
try that version.

Also, what test are you using?  test_hotshot only has 3 tests.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-07-31 10:56

Message:
Logged In: YES 
user_id=33168

There have been a few changes to hotshot which could fix
this problem.  Can you test the current version in CVS?  I'm
not sure if 2.4a1 has the fixes or not, but you could also
try that version.

Also, what test are you using?  test_hotshot only has 3 tests.

----------------------------------------------------------------------

Comment By: Viktor Ferenczi (complex)
Date: 2004-07-31 09:25

Message:
Logged In: YES 
user_id=142612

OS: WinXP Prof ENG SP1
Python: 2.3.4 final, EXE installer (binary)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001150&group_id=5470